Home/Insights/Web & performance/Next.js November 2026 security release — the cache bugs that can leak one tenant's data to another
Web & performance · 2026-11-05 · 7 min read

Next.js November 2026 security release — the cache bugs that can leak one tenant's data to another

Next.js 16.4.5 and 15.5.29 fix seven issues, most in Cache Components. Who is exposed, how SaaS and multi-tenant apps can leak data, and a 1-hour patch plan.

By Suzu Technology engineering · #nextjs · #next.js 16 · #cache components · #use cache · #multi-tenant · #saas · #web security · #self-hosting · #patching · #india

Key takeaways

  • On 3 November 2026 the Next.js team published its November 2026 security release: v16.4.5 (Active LTS) and v15.5.29 (Maintenance LTS). It fixes seven issues — one High and six Medium.
  • This is a different kind of release from October's. The 14 October update fixed remote code execution. This one is mostly about data leaking between users, tenants or locales through caching — quieter, but worse for a SaaS business because nothing crashes and nobody notices.
  • Four of the seven issues involve Cache Components and use cache. If your app does not enable Cache Components, your exposure is much smaller — but still patch, because the Edge cookie and Image Optimization fixes apply more broadly.
  • None of the seven has a CVE ID — only GitHub advisory (GHSA) IDs. As with October, npm audit and scanners that key on CVEs may stay quiet. Check your installed version by hand.
  • The post lists no workarounds, says nothing about Next.js 14 or older, and does not report exploitation in the wild. Upgrading is the only fix offered.
  • For most teams this is under an hour of work: bump one package, rebuild, and spot-check pages that differ per tenant, user or language.

1. What was fixed, in one table

All details below are from the official release post, summarised in plain terms.

Advisory Severity What can go wrong Who is exposed
GHSA-mfr8-8qww-v76h High During a cold cache fill, one tenant's cached result can be returned to another tenant's request Cache Components on; the same use cache function is called both directly and inside unstable_cache, and it reads a root parameter such as a tenant ID
GHSA-vc7v-qv4w-wrv8 Medium Tenant-, site- or locale-specific content served across the routing boundary Nested use cache functions where the inner one reads a root parameter and returns a fast value plus a slower async value
GHSA-rhh4-g77r-r9qj Medium Different binary arguments map to the same cache entry → cross-user disclosure or poisoning Apps that pass security-relevant binary data (buffers, typed arrays) into use cache and share entries across callers
No ID given Medium Shared shell cache poisoning Self-hosted next start, Cache Components on, Partial Prefetching off or unset, plus a specific nested dynamic-route shape
GHSA-pc58-hwjq-p385 Medium One client's response framing bleeds into another's Self-hosted apps that return an attacker-controlled fetched Response unchanged, behind an HTTP/1.1 proxy that pipelines requests on a shared backend connection
GHSA-f3mh-rxg3-f5g2 Medium Cookie values exposed via the internal x-middleware-set-cookie header Edge Route Handlers / Edge API routes using NextResponse.cookies.set(); needs attacker JavaScript on the same origin
GHSA-7qx7-33qx-rqx2 Medium An SVG disguised as AVIF slips past dangerouslyAllowSVG: false Image Optimization with a native backend that can decode SVG; the image-source allowlist still applies

The release post itself says the SVG issue does not, on its own, demonstrate cross-site scripting or remote code execution, and that the proxy issue does not apply to every reverse-proxy setup. Those caveats matter when you explain the risk to a client — do not overstate it.

2. Why "cache leaks" are the scary part for SaaS

A crash gets noticed. A cache leak usually does not. If a school ERP, clinic booking system or B2B dashboard serves Tenant A's invoice list to Tenant B for a few seconds after a deploy, the most likely outcome is that nobody reports it — or one customer screenshots it and posts it publicly.

The common thread in the top three advisories is the cache key. Next.js decides whether two requests can share a cached result by building an identity from the function and its inputs. These bugs are cases where that identity did not include everything it should have — the root parameter (tenant, site, locale), or the full content of binary arguments. The upgrade fixes the framework side. It does not fix your own design choices, so also check:

  • Every use cache function that returns tenant- or user-specific data takes the tenant or user ID as an explicit argument, rather than reading it from somewhere implicit.
  • You are not mixing old unstable_cache wrappers with new use cache functions for the same data. Pick one during migration.
  • Personalised pages (dashboards, carts, profile pages) are not cached at the shared layer at all unless you are sure the key is per-user.

3. Are you exposed? A five-minute check

Run in the project root:

npm ls next                       # installed version
grep -rn "cacheComponents" next.config.*      # Cache Components on?
grep -rln "use cache" app/ src/ 2>/dev/null | wc -l
grep -rln "unstable_cache" app/ src/ 2>/dev/null | wc -l
grep -rn "runtime = 'edge'\|runtime: 'edge'" app/ pages/ src/ 2>/dev/null
Result What it means
Version below 16.4.5 (16.x) or 15.5.29 (15.x) Upgrade
Cache Components on and both use cache and unstable_cache present Highest priority — this is the High-severity path
Edge routes that set cookies Patch; also review any third-party scripts on that origin
Self-hosted behind Nginx/HAProxy/an older load balancer Patch; confirm whether the proxy pipelines HTTP/1.1 to the backend
Next.js 14 or older Not mentioned in the post. Treat it as unsupported and plan a move to 15.5 LTS

4. The fix

npm install next@16.4.5      # if you are on 16.x
npm install next@15.5.29     # if you are on 15.5.x
npm run build && npm run start   # or your CI pipeline

(The release post's comment next to the 16.x command says "for 16.5", but the version it gives is 16.4.5. Install the exact version number above.)

After deploying, purge or invalidate your data cache once, so no entry created under the old behaviour survives. Then log in as two different test tenants in two browsers and walk the pages that differ per tenant — dashboard, invoices, settings. Repeat for each language if you serve Hindi and English routes.

5. Vercel vs self-hosted vs static export

Setup Exposure Notes
Vercel Cache issues (1–3) and Edge cookie issue apply if you use those features The post does not say Vercel-hosted apps are auto-protected — upgrade anyway
Self-hosted on VPS / Docker (common with Indian hosts and cloud VMs) All seven can apply, including the two self-hosted-only issues Also check your reverse proxy's keep-alive and pipelining settings
Static export (output: 'export') Very low — no server, no runtime cache Upgrade at your next routine dependency bump

Many Indian agencies and startups run Next.js on a ₹500–₹2,000 per month VPS behind Nginx rather than on Vercel. That is the group with the widest exposure here, because two of the seven issues are specific to self-hosting.

6. The India angle: why this one is worth an hour

India's SaaS sector sells heavily to SMBs, schools and clinics, often from a single multi-tenant codebase. Under the Digital Personal Data Protection Act, 2023, a business that processes personal data is expected to take reasonable security safeguards and report personal data breaches. A cross-tenant leak of customer records is exactly the kind of incident you do not want to explain to a client, let alone a regulator.

Compare the costs. Patching is roughly one developer-hour — at typical Indian agency rates, a few thousand rupees. Investigating a reported leak, notifying affected customers and handling the follow-up takes days, and the reputational cost with a B2B client is harder to recover than any invoice.

7. Checklist

  1. Run the five-minute check on every Next.js app you maintain, including client projects.
  2. Upgrade to 16.4.5 or 15.5.29; rebuild; purge the data cache.
  3. Test two tenants and two locales side by side.
  4. Make tenant and user IDs explicit arguments in every use cache function.
  5. Note that none of these have CVEs — add the Next.js blog and GitHub advisories page to your weekly watch list rather than relying on npm audit.

Running Next.js on your own servers and not sure what your proxy and headers are doing? Check any URL with our HTTP headers checker, or talk to us about managed IT and patching for your web stack.