Site icon NexGismo

Next.js Security Release: 7 Fixes and Interview Questions

Ashutosh Tiwari
Next.js Security Release: 7 Fixes and Interview Questions
TL;DR

The Next.js security release published on Nov 3, 2026 patches seven vulnerabilities. Four relate to cache identity and tenant isolation, one to HTTP response framing, one to cookie exposure and one to SVG filtering. Upgrade to 16.4.5 or 15.5.29, then review any shared use cache code.

— Ashutosh Tiwari, NexGismo

Cache-key collision happens when two different requests produce the same cache identity, so one caller receives a result generated for another. In a multi-tenant app, that means one tenant can read another tenant’s data. Most of this week’s Next.js fixes are variations of that one idea.

What changed in the Next.js security release and who is affected?

For this Next.js security release, the team posted an advance notice on Oct 27, 2026, then published the full Next.js November 2026 security release on Nov 3. It lists seven issues and says patches are available in 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS).

One discrepancy is worth knowing. The release post labels the first issue High severity. Its GitHub advisory page shows a CVSS v4.0 score of 6.3 (Moderate). I’d treat it as high business risk in multi-tenant apps, because the data exposed is another tenant’s.

Issues in the Nov 3, 2026 Next.js release (severity as labelled in the release post; CVSS v4.0 from each advisory)
Issue Advisory Severity / CVSS
Cross-tenant disclosure via unstable_cache + use cache CVE-2026-119790 High (post) / 6.3
Nested use cache root-parameter leak CVE-2026-119351 Medium / 6.3
Binary arguments share one cache identity CVE-2026-119349 Medium / 6.3
Shared shell cache poisoning (self-hosted) No advisory link in the post Medium
Stale compressed-response framing CVE-2026-119348 Medium / 6.3
Cookie exposed in x-middleware-set-cookie (Edge) CVE-2026-119346 Medium / 6.0
SVG rejection bypass in Image Optimization CVE-2026-119347 Medium / 6.9

Affected ranges differ per advisory. CVE-2026-119790 lists Next.js 16.3.0 and later, and CVE-2026-119351 lists 16.2.0 and later. CVE-2026-119346 and CVE-2026-119347 cover 16.0.0 through 16.4.2 and 15.0.0 through 15.5.28. The simplest rule: if you run any 15.x or 16.x release below the patched versions, upgrade.

How does the Next.js security release fix these bugs?

The use cache docs explain the foundation. A use cache entry key is built from the build ID, a function ID, serializable arguments, and any captured outer-scope variables. When a cached function reads root parameters, only the ones it reads join the key.

If a value that separates users or tenants is missing from that key, entries get shared. The advisories describe three ways this can happen:

  1. A cold cache fill runs through unstable_cache and use cache at once, and a concurrent caller receives another request’s result without a root-parameter check (CVE-2026-119790).
  2. A nested outer entry is stored before the inner function’s root-parameter dependencies are recorded (CVE-2026-119351).
  3. Distinct binary arguments produce the same cache identity (CVE-2026-119349).

The remaining four are different bugs. Per the Next.js November 2026 security release, a crafted URL can poison a shared page shell on self-hosted next start. A decompressed body can be forwarded with the original compressed framing headers, which matters behind certain HTTP/1.1 proxies (CVE-2026-119348). Edge routes can leak a serialized cookie through an internal header readable by same-origin JavaScript (CVE-2026-119346). A file can be misclassified as AVIF and bypass dangerouslyAllowSVG: false (CVE-2026-119347).

The release post is careful about limits. The cache bugs do not give arbitrary access to unrelated entries, and the cookie leak is not an independent way to run JavaScript. I won’t go further than the advisories do.

A safe illustration of the design rule, adapted from the use cache docs: make the tenant explicit in the arguments.

async function getOrders(accountId: string) {
  'use cache'
  // accountId is part of the cache key, so each account gets its own entry
  return db.orders.findMany({ where: { accountId } })
}

What should developers do after the Next.js security release?

  1. Detect: run npm ls next and note every app below 16.4.5 or 15.5.29.
  2. Patch: run npm install next@16.4.5 or npm install next@15.5.29, as the Next.js November 2026 security release shows.
  3. Verify: rebuild, then confirm the installed version in your lockfile and deployed image.
  4. Mitigate the cache bug: CVE-2026-119790 says avoiding a use cache function call through unstable_cache() is a complete workaround.
  5. Review: list every cached function that reads a tenant, locale or user value, and confirm that value is in its key.
  6. Edge cookies: if you call NextResponse.cookies.set() in Edge routes, treat sensitive cookie values as potentially exposed until you upgrade, and consider rotating them.

For more on cache hardening in general, see our guide to cache stampede prevention and our notes on Next.js 16 auth mistakes.

Interview questions this update prepares you for

1. How would you design cache keys for a multi-tenant application?

Every input that changes the output must be part of the key: tenant, user or role, locale, and any feature flag that alters the result. Missing one creates cross-tenant leaks, while adding unneeded ones lowers the hit rate. I’d derive the key from explicit arguments instead of ambient state, and add a test that requests the same resource as two tenants and asserts different results. Private data should often skip shared caches entirely.

Follow-up they may ask: How do you test for a missing key component?

2. What is the difference between cache poisoning and cache deception?

Poisoning stores attacker-influenced or wrong content so other users receive it. Deception tricks a cache into storing a victim’s private response so the attacker can read it. Both come from a gap between what the cache treats as the same request and what the application treats as different. The fix is aligning cache identity with application semantics and marking private responses non-shareable.

Follow-up they may ask: Which headers control whether a shared cache may store a response?

3. Why can an HttpOnly cookie still leak?

HttpOnly only stops JavaScript from reading the cookie through document.cookie. It does not stop the value appearing in another readable place, such as a response header, a log line, or a JSON body. Any channel that exposes the value to script defeats the flag. Secure handling means keeping secrets out of every readable surface, not just setting flags.

Follow-up they may ask: What do Secure and SameSite protect against?

4. What goes wrong when a proxy and backend disagree about response framing?

HTTP/1.1 relies on headers such as Content-Length, Transfer-Encoding and Content-Encoding to mark where a message body ends and how it is encoded. If a backend sends a decompressed body with headers describing the compressed one, a proxy sharing one backend connection can split the stream in the wrong place. Later responses then attach to the wrong clients. Normalising headers when you rewrite a body prevents it.

Follow-up they may ask: How does HTTP/2 reduce this class of problem?

5. Why is file-type detection by content safer than by extension, and where does it still fail?

Extensions and declared MIME types are attacker-controlled. Sniffing the bytes is stronger, but two components can classify the same bytes differently, which is how a filter and a decoder end up disagreeing. Defence in depth means validating once, then decoding with a parser restricted to the allowed formats.

Follow-up they may ask: Why is SVG riskier than a raster format?

6. How do you choose between key-based and tag-based cache invalidation?

Time-based expiry is simple but serves stale data until it lapses. Tag-based invalidation lets a mutation expire every related entry at once, as the use cache docs describe with cacheTag and revalidateTag. The trade-off is bookkeeping: forgotten tags leave stale entries. Most production systems combine both.

Follow-up they may ask: What happens to in-flight requests when you invalidate during a cold fill?

The NexGismo verdict: My opinion is that the cache issues matter more than their scores suggest. They are quiet failures that return wrong data with a 200 status, so nothing alerts you. Patch first, then audit your cached functions for tenant or user inputs missing from their keys.

Frequently Asked Questions

Which Next.js version fixes the November 2026 security issues?

The release post says the fixes ship in Next.js 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS). Upgrade with npm install next@16.4.5 or npm install next@15.5.29, then rebuild and redeploy.

Are Next.js apps without Cache Components affected?

The four cache-related issues described apply to apps using Cache Components and use cache. The cookie, response-framing and SVG issues have their own conditions, so upgrading is still the safe course for every 15.x or 16.x app.

Is there a workaround for the unstable_cache and use cache leak?

Yes. The advisory for CVE-2026-119790 says avoiding a use cache function call through unstable_cache() is a complete workaround. It also notes this nesting already throws an unsupported error.

Can HttpOnly cookies leak in Next.js Edge routes?

According to the advisory, Edge routes setting cookies with NextResponse.cookies.set() can expose the value in the x-middleware-set-cookie header, which same-origin JavaScript can read. Node.js route handlers were not affected in the reproduced case.

Conclusion

This Next.js security release is a good reminder that caching bugs are security bugs when identity is wrong. Upgrade, audit your cache keys, and practise explaining the concepts above out loud. If you also compare frameworks, see Next.js vs TanStack Start. Subscribe to NexGismo for more updates with interview prep built in.

Sources

Exit mobile version