A Next.js application can pass its tests, work correctly in production, and still expose sensitive information because of how the framework handles caching, cookies, or HTTP responses.
On November 3, 2026, the Next.js team published a security release addressing seven vulnerabilities. The issues affect different parts of the framework, including Cache Components, image optimization, Edge runtime routes, and response handling in self-hosted applications.
The patched releases are Next.js 16.4.5 and 15.5.29. Applications running affected versions should be updated rather than relying only on deployment-level protections.
However, upgrading is only the first part of the work. Developers also need to understand which features their applications use, check their caching and routing configurations, and verify that sensitive data is not shared between users or tenants.
What Changed in the November Security Release?
The November release covers seven security issues. Most involve situations where information or responses can be reused in an unintended context.
The following table summarizes the areas developers should review.
Security issue | Affected area | Main concern |
|---|
Cross-tenant cache disclosure | Cache Components with unstable_cache and use cache | One tenant may receive another tenant's cached data |
Cross-root-parameter disclosure | Nested use cache functions | Cached content may cross tenant, site, or locale boundaries |
Binary argument cache poisoning | use cache | Different binary arguments can produce the same cache identity |
Shared shell cache poisoning | Self-hosted applications | Request-specific content can affect a shared page shell |
Cross-client response injection | Self-hosted HTTP response forwarding | Responses may be assigned to the wrong clients |
Internal cookie header exposure | Edge Route Handlers and Edge API routes | Sensitive cookie values may appear in an internal response header |
SVG rejection bypass | Image Optimization | An SVG may reach an image parser despite the configured rejection setting |
These issues do not all apply to every Next.js application. For example, the shared shell issue has specific requirements involving Cache Components, Partial Prefetching, and dynamic route parameters. The cookie issue concerns particular Edge runtime routes rather than every application that uses cookies.
Understanding these conditions helps teams prioritize the right checks instead of treating every advisory as an identical exposure.
Upgrade Next.js to a Patched Version
The first step is to identify the installed Next.js version.
Run the following command from the project directory:
npm list next
The November security release provides these patched versions:
For an npm project using Next.js 16:
npm install [email protected]
For a project using Next.js 15:
npm install [email protected]
If the project uses pnpm:
pnpm add [email protected]
For Yarn:
yarn add [email protected]
Use the corresponding patched version for the release line your project follows. Do not downgrade a newer supported release simply to match the examples above.
After installation, check the version again:
npm list next
Also inspect the package lockfile. It should reflect the updated dependency tree. Commit the package manifest and lockfile together so that local development, CI, and production builds use the same resolved dependencies.
A successful installation does not prove that the deployed application is running the patched release. The deployment must be rebuilt and restarted using the updated dependencies.
Review Cache Isolation in Multi-Tenant Applications
One of the more important issues in this release concerns applications that use Cache Components with both unstable_cache and use cache.
Consider a SaaS application where every customer has a separate tenant identifier. The application loads tenant-specific information from a database and caches the result to avoid repeated queries.
A simplified example might look like this:
import { unstable_cache } from "next/cache";
async function getTenantSettings(tenantId: string) {
return unstable_cache(
async () => {
return database.tenantSettings.findMany({
where: { tenantId }
});
},
["tenant-settings", tenantId]
)();
}
The example illustrates tenant-specific caching, not the exact vulnerable pattern.
The November advisory concerns a more specific situation: the same public use cache function is called directly and through unstable_cache, and it reads a root parameter such as a tenant identifier. During a concurrent cold cache fill, one request can receive a result associated with another root-parameter value.
The returned result can then be stored and served to later requests.
This is particularly important for applications that handle customer-specific settings, account information, or other private data.
After upgrading, inspect the following areas:
Identify functions that use both unstable_cache and use cache.
Check whether cached functions read tenant identifiers or other root parameters.
Review nested cache functions that return tenant-specific data.
Confirm that cache keys represent the data's security boundaries.
Test requests from different tenants against the same cached resources.
Do not assume that adding a tenant identifier to a cache key automatically resolves every caching problem. The framework's cache identity and root-parameter handling are part of the issue. Use the patched release and review the actual function relationships.
Check Nested use cache Functions
The release also addresses information disclosure involving nested use cache functions.
This issue can occur when an inner cached function reads a root parameter and returns an early value alongside a slower asynchronous result. If the outer function finishes before the inner function's root-parameter dependencies are recorded, the outer cache entry can be stored without the expected dependency information.
For example, a multi-tenant application may have nested cached functions that load a tenant's profile and related configuration.
The application might appear to work correctly during ordinary testing because the cache is already populated. The problem becomes more relevant during concurrent requests and cold cache fills.
Review nested cached functions that combine immediate values with slower asynchronous operations. Pay particular attention to functions that read route parameters identifying tenants, sites, or locales.
After upgrading, test requests using different parameter values. Confirm that a request for one tenant cannot receive content generated for another tenant.
Review Binary Arguments Passed to use cache
Another issue involves binary arguments used by cached functions.
Different binary inputs can produce the same cache identity. If an application uses those inputs to distinguish users, accounts, or other security-sensitive records, one caller may receive a result associated with another caller.
Consider a function that accepts a binary value representing an account-specific document or identifier. If the application relies on that argument to separate cached results, an incorrect cache identity can cause information to be reused across requests.
This is not a general cache disclosure affecting every use cache function. It concerns applications that pass security-significant binary arguments through the affected caching mechanism.
Review functions that accept binary values such as typed arrays and other binary data. Check whether those arguments determine access to user-specific or account-specific information.
For sensitive operations, authorization should also be checked independently of cache identity. A cache key should never become the only protection separating one user's data from another user's data.
Inspect Shared Page Shells in Self-Hosted Applications
The November release includes a cache-poisoning issue affecting certain self-hosted applications.
The affected configuration involves applications running with next start, Cache Components enabled, and Partial Prefetching disabled or unset.
The route structure must also meet specific conditions involving dynamic parameters, parameters that are not prerendered, and a blocking fallback shell.
An unauthenticated request with a specially crafted URL can cause request-specific values to be stored in a shared shell. Other requests may then receive incorrect server-rendered content or persistent 404 responses.
This is not a general vulnerability in every dynamic route.
Developers running self-hosted Next.js applications should inspect their route structure and Cache Components configuration. Pay particular attention to layouts that read dynamic parameters inside Suspense boundaries.
After upgrading, test routes using values that were not generated during the build. Check whether the correct page shell is returned for different parameter values.
Check Cookie Handling in Edge Runtime Routes
The release also addresses exposure of cookie values through an internal response header.
The affected scenarios involve App Router Edge Route Handlers and Pages Router Edge API routes that set cookies using NextResponse.cookies.set().
Under the affected conditions, the serialized cookie can appear in the internal x-middleware-set-cookie response header. Unlike the normal Set-Cookie response header, this internal header can be read by same-origin JavaScript.
That creates a concern for cookies marked HttpOnly because those values are normally protected from direct JavaScript access.
The issue requires a sensitive cookie to be set on an affected response and attacker-controlled JavaScript to run on the same origin. It is not an independent method for executing JavaScript.
The reported reproduction did not affect Node.js Route Handlers or routes that set cookies through cookies().set().
Developers should inspect Edge runtime routes that create authentication or session cookies. After upgrading, verify that sensitive values are not exposed through internal response headers and review how cookies are created and returned.
Review Image Optimization and SVG Handling
Next.js includes image optimization features that can process images from configured remote sources.
The November release addresses a bypass involving the SVG rejection setting.
An attacker-controlled image from an allowed source can be misclassified as AVIF. The image optimization backend may then identify and decode the original content as SVG, reaching a parser that the application intended to exclude.
The existing image-source allowlist still applies. This issue does not mean that arbitrary remote websites can automatically send images to every Next.js application.
Review the image configuration, especially applications using:
const nextConfig = {
images: {
dangerouslyAllowSVG: false
}
};
module.exports = nextConfig;
Keeping this setting disabled is still useful, but it should not be treated as a substitute for applying the security update.
Also review remote image source patterns. Allow only the domains and paths that the application actually needs.
The November advisory describes increased exposure to SVG parser resource exhaustion or decoder vulnerabilities. It does not establish that this issue itself provides cross-site scripting or remote code execution.
Check Response Forwarding in Self-Hosted Applications
Applications that fetch external resources and return the fetched Response unchanged should also be reviewed.
The November release identifies a problem involving compressed response framing. In affected self-hosted deployments, an application may forward decompressed response bytes while retaining headers that describe the original compressed response.
Under a particular HTTP/1.1 reverse-proxy configuration, where pipelined requests share a backend connection, this mismatch can cause responses to be associated with the wrong clients.
The issue does not affect every reverse-proxy setup.
If your application forwards responses from external services, review how it handles the response body and headers. Avoid assuming that a response can always be forwarded unchanged after its body has been processed.
Also test the deployment path through the actual reverse proxy and hosting configuration. A local development server may not reproduce the connection behavior of the production environment.
Verify the Update Before Deploying
Once the dependency is updated, run the application's normal validation process.
For an npm project, a typical sequence is:
npm install
npm run lint
npm run test
npm run build
The exact commands depend on the scripts defined in the project's package.json file.
A successful build confirms that the application can compile with the updated dependency. It does not prove that every security issue has been addressed in the application's own code or deployment configuration.
Before releasing the update, verify that:
The installed Next.js version is patched.
The lockfile contains the updated dependency.
The production build uses the same dependency version.
Tenant-specific cached data remains isolated.
Edge routes do not expose sensitive cookie values.
Image source restrictions remain appropriate.
Self-hosted response forwarding works correctly.
Relevant integration tests pass.
For multi-tenant applications, include tests that make requests using different tenant identifiers while the cache is cold. Testing only after the cache has been populated can miss problems that occur during concurrent cache fills.
Conclusion
The November 2026 Next.js security release addresses seven issues across caching, image optimization, Edge runtime routes, and self-hosted response handling. The fixes are available in Next.js 16.4.5 and 15.5.29.
Updating the framework should be the first action, but it should not be the only one. Applications that use tenant-specific caching, nested use cache functions, binary cache arguments, Edge route cookies, or custom response forwarding need additional review.
The most useful approach is to identify which affected features the application actually uses, upgrade to the appropriate patched release, and test those specific execution paths before deployment.
Security updates are most effective when dependency maintenance and application-level verification are handled together.
Join the conversation! Your thoughts help the community grow.