Next.js Security Patches Target Cache and Response Leaks

The Next.js security update released on November 3, 2026 is available in 16.4.5 for Active LTS and 15.5.29 for Maintenance LTS. It fixes cache disclosures, self-hosted response handling problems, Edge cookie exposure, and an image validation bypass. I'd patch the application's existing release line first. Then I'd test the boundaries I care about: which tenant owns cached content, which client receives a response, and which headers expose cookies. The patch is available now; this isn't an upcoming release I need to plan around.

The November security release covers several distinct failure modes, and I wouldn't file the whole thing under “cache bug.” That would hide too much. The prerequisites differ enough that I'd start the rollout by checking what the application actually has enabled and how it runs.

Which Next.js versions contain the fixes?

The patched releases are 15.5.29 and 16.4.5. If the application is on the Maintenance LTS line, I'd use this installation command:

npm install next@15.5.29

For an application on the Active LTS line, the corresponding command is:

npm install next@16.4.5

I'd stay on the matching release line rather than fold a broader framework migration into this security change. I want a small dependency change that I can review on its own, followed by deployment checks aimed at the affected features. I'd check the resulting dependency changes into that same review, too. There should be no ambiguity about which version the change is intended to install.

I'd separate two jobs here: applying the patch and assessing exposure. They don't have to wait for each other. I'd patch while investigating which paths are reachable, then use the exposure review to decide where tests need attention and whether a deeper investigation is warranted. An incomplete inventory wouldn't be my reason to put the update off.

The cache bugs cross different ownership boundaries

Mixing unstable_cache with public use cache

The high-severity issue affects applications with Cache Components enabled when the same public use cache function is called both directly and from inside unstable_cache. There's another condition: the cached function must read a root parameter, such as a tenant identifier.

During a cold cache fill, a concurrent call through unstable_cache can receive another request's result without checking its root parameters. The problem needn't end with that request. The result can be cached for later callers with the same arguments until revalidation or eviction. If the root parameter is what separates tenants, that reused result can contain another tenant's data.

I'd look beyond route files and find the shared cached helpers. Then I'd trace both ways into each helper: its direct callers and the wrappers around it. In my full-stack work, I'd want this particular boundary visible in a call graph before I was comfortable calling the cache safely scoped. Looking at the helper alone wouldn't answer the question I'd be asking.

Nested cached functions can record dependencies too late

A separate medium-severity issue affects nested public use cache functions with Cache Components. Here, the inner function reads a root parameter and returns an early value alongside a slower asynchronous value. Timing matters. If the outer function finishes without waiting for that slower value, its cache entry can be stored before the inner function's root-parameter dependencies have been recorded.

That result can cross tenant, site, or locale boundaries. What gets reused incorrectly is application-generated content, not arbitrary response content injected by an attacker. I'd test with a recognizable value from each routing context instead of stopping at an assertion that the page rendered successfully. The page can look right and still contain the wrong site's content. That's exactly the case I'd want the test to reject.

Binary arguments can collide in cache identity

Distinct binary arguments passed to a use cache function can produce the same cache identity. If those arguments distinguish users or accounts, and the remaining identity inputs match, one caller can receive another user's result. The reverse matters just as much: that caller's own result can be served to another user.

This requires security-significant binary arguments and shared entries across callers; it doesn't grant arbitrary access to unrelated cache entries. I'd inventory what the binary values mean before changing how they're represented. My priority would be proving that distinct account inputs stay distinct after patching. I wouldn't bundle a hurried serialization change into the fix just because the collision involves binary arguments.

Self-hosted deployments need route and proxy checks

The shared-shell issue affects self-hosted applications running next start with Cache Components enabled and Partial Prefetching disabled or unset. An unauthenticated crafted request can poison a shared page shell with request-specific values. The visible result can be incorrect server-rendered content or persistent 404 responses. I'd keep both outcomes in view when checking an affected route.

The route shape is specific. It needs a prerenderable dynamic parameter requested with a value not generated at build time, at least two deeper parameters that are never prerendered, and a blocking fallback shell. A layout must read the shallower of those deeper parameters inside a Suspense boundary. In the reported tests, build-generated values were unaffected, as were configurations with Partial Prefetching enabled.

I'd inspect the actual route structure before deciding that any particular dynamic route is exposed. I also wouldn't stretch that test result into a blanket promise about every configuration. For an editorial application, my first check would be concrete: can an unusual URL leave ordinary story requests receiving the wrong shell or a persistent missing-page response? That's the behavior I'd want to rule out.

The response-framing issue needs a different setup. A self-hosted application returns an attacker-controlled fetched Response unchanged, forwarding decompressed body bytes with the original compressed response's framing headers. Put that behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared backend connection, and the mismatch can assign responses to the wrong clients.

An attacker who can arrange requests on that connection can inject a response for another client or receive another client's response. Not every reverse-proxy configuration is affected. I'd ask whoever owns the proxy to establish whether it has that connection behavior. The mere fact that a proxy is present wouldn't tell me enough to make an exposure call either way.

Edge cookies and image validation have narrower prerequisites

App Router Edge Route Handlers and Pages Router Edge API routes that set cookies through NextResponse.cookies.set() can expose the serialized cookie through the internal x-middleware-set-cookie response header. Unlike Set-Cookie, that internal header is readable by same-origin JavaScript. That includes cases where the cookie is marked HttpOnly, which is the distinction I'd pay attention to in a review.

For impact, the affected response needs to carry a sensitive cookie, and attacker-controlled JavaScript must already be running on the same origin. This isn't an independent path to JavaScript execution. The reproduced leak did not affect Node.js Route Handlers or routes using cookies().set(). I'd keep those limits attached to the finding rather than treat every cookie-setting route alike.

I'd make the runtime that sets the cookie part of the review, not just search for cookie names and stop there. For the regression check, I'd examine the response carrying the sensitive cookie itself. The check I'd want is direct: confirm that the cookie's value isn't also exposed through the internal header on that response.

The Image Optimization issue lets an attacker-controlled image from a permitted source be misclassified as AVIF and bypass images.dangerouslyAllowSVG: false. A native backend capable of decoding SVG can then recognize the original bytes as SVG. That reaches a parser the application intended to exclude, despite the validation setting.

The image-source allowlist still applies. This finding increases exposure to SVG parser resource exhaustion or decoder vulnerabilities; it doesn't itself demonstrate cross-site scripting or remote code execution. I'd review the permitted image sources and the actual backend together. I wouldn't call it a universal exploit, but I wouldn't dismiss it as a harmless validation quirk either.

Rolling the patches through an existing Next.js deployment

I'd keep the rollout focused on ownership boundaries I can actually observe. These are the checks I'd put into the deployment review. I'd select the relevant ones from the application's configuration, though, rather than copy the whole list into every review and treat each item as equally applicable.

• Record the affected surfaces. I'd identify Cache Components usage, public cached functions, Edge cookie-setting routes, unchanged fetched responses, and Image Optimization. For a self-hosted application, I'd also record the start command, the Partial Prefetching setting, and the proxy behavior. I want the configuration in front of me before choosing the checks.
• Patch the existing release line. I'd review the installed dependency change, build the application, and deploy through the normal release process. I'd leave unrelated cache refactoring out of that change. The patch review is where I want to see the dependency update, not a second set of cache changes to untangle.
• Exercise cold-cache concurrency. For the mixed-cache path, I'd arrange overlapping requests from distinct tenant contexts against an initially empty test cache. I wouldn't stop with those first responses. I'd inspect later requests too, because the faulty result can persist in a cached entry and be reused after the initial overlap.
• Vary routing context and completion timing. For nested caches, I'd keep ordinary arguments comparable while changing tenant, site, or locale context. I'd deliberately delay the inner asynchronous value, then verify that each response belongs to the context that requested it. Merely getting a response back isn't the assertion I'm after.
• Test binary identity independently. Where binary arguments carry account identity, I'd use distinct controlled values and verify both the initial response and subsequent reuse. I'd write explicit ownership assertions instead of relying on snapshots of otherwise similar content. I want the test to say whose result it expects, not just what the result looks like.
• Validate infrastructure-dependent paths in context. I'd test response forwarding through a representative proxy setup and inspect Edge headers at the deployed boundary. A local page-render check wouldn't satisfy my review of those prerequisites. I'd want the checks to cover the proxy behavior and response headers that make these paths relevant.

I'd also keep the test content unmistakably synthetic. For a newsroom CMS, that means clearly labeled site or tenant fixtures, not real editorial material. My acceptance criterion is straightforward, even if the setup takes some care: each caller receives only the content and headers intended for that caller. That's what I'd make the assertions express.

After deployment, I'd repeat the targeted checks against the patched environment. A successful build is a release prerequisite for me, not evidence that tenant isolation or response ownership has been verified. I'd still need those checks to pass against the environment where the patch has actually been deployed.

A patched dependency is not a retrospective clearance

I wouldn't conclude that an application was exploited just because it used an affected version. These issues have concrete prerequisites, and I'd check them. But a passing basic smoke test wouldn't convince me that no disclosure occurred, either. My exposure assessment would document which prerequisites were present and be explicit about which evidence remains unavailable.

I also wouldn't assume that upgrading establishes the state of every previously populated cache. The mixed-cache failure can leave an incorrect result available until revalidation or eviction. I'd establish how the deployed application's relevant entries are refreshed, then decide whether explicit cache cleanup belongs in the rollout. That decision depends on the deployment; I wouldn't invent a universal purge command for all hosting arrangements.

For me, this is production engineering work: install the fix, identify the boundary, and verify the behavior that matters. If an application doesn't use a particular affected feature, I'd skip that feature's elaborate reproduction exercise. I'd still take the matching patch. A narrow finding of non-exposure isn't something I'd turn into an indefinite exception to applying it.

I'd patch first and investigate precisely, then keep the useful isolation checks after the rollout. I don't want a larger security checklist for its own sake. My next step would be to retain a test that fails when one tenant's content, one client's response, or one sensitive cookie reaches the wrong reader—and run it against the patched deployment.