On November 3, 2026, the Next.js team released versions 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS) with fixes for seven vulnerabilities. One is rated high and six medium. Four of them make the cache serve one person content generated for someone else: another tenant, another locale or another user. The advance notice, published on October 27, mentioned seven medium issues; the high rating only appeared in the final release.
Four cache bugs and three elsewhere
The high-severity issue (GHSA-mfr8-8qww-v76h) affects applications with Cache Components enabled when the same use cache function is called both directly and from inside unstable_cache, and that function reads a root route parameter such as a tenant identifier. While the cache is being filled, a concurrent call can receive another request's result without checking that parameter. The result is stored and keeps being served until the entry is revalidated or evicted. Where the parameter separates customers in a multi-tenant application (several customers on the same system), the result can contain another customer's data.
The other three cache issues are medium:
- nested
use cachefunctions can serve content generated for one root parameter value (tenant, site or locale) to requests for another (GHSA-vc7v-qv4w-wrv8); - different binary arguments passed to a
use cachefunction can produce the same cache identity, which lets a caller receive another user's result or have their own result served to someone else (GHSA-rhh4-g77r-r9qj); - in self-hosted applications running
next startwith Cache Components enabled and Partial Prefetching disabled or unset, an unauthenticated request can poison the shared page shell and cause wrong content or persistent 404s on other URLs. This one depends on a specific route shape, described in the announcement.
Outside the cache, the release fixes:
- in self-hosted applications, a
fetchresponse returned unchanged can reach the wrong client when an HTTP/1.1 reverse proxy queues requests on a shared backend connection (GHSA-pc58-hwjq-p385); - Edge routes that set cookies with
NextResponse.cookies.set()expose the cookie value in an internal header that same-origin JavaScript can read, even withHttpOnly. Exploiting it requires attacker JavaScript already running on the site (GHSA-f3mh-rxg3-f5g2); - an image from an allowed source can pass as AVIF and bypass
images.dangerouslyAllowSVG: false, reaching an SVG decoder the application meant to exclude (GHSA-7qx7-33qx-rqx2).
Who should look first
According to the announcement, the cache issues only apply to applications using Cache Components and the use cache directive. The concrete risk shows up where the cache separates data by tenant, locale or user: SaaS products serving several customers from one application, multilingual or multi-brand sites served by the same project, and logged-in areas that cache responses per user.
Two issues explicitly mention self-hosted applications, meaning those running next start on their own server or container. Teams with their own reverse proxy in front of Next.js are in that group. The announcement does not say whether applications hosted on Vercel or other platforms get any provider-side protection.
Teams still on Next.js 14 or earlier are not on the list of patched versions. Next.js 14 reached end of support on October 26, 2025, according to endoflife.date.
What to do and by when
Upgrade to 16.4.5 if you are on 16 and to 15.5.29 if you are on 15. There is no formal deadline, but the details have been public since November 3. If your cache separates data by tenant or user, the upgrade should not wait for the next maintenance window.
After upgrading, cache entries written before the fix are still there. The high-severity issue describes results that stay stored until revalidation or eviction. My reading is that, where the cache separates tenants, it is worth invalidating those entries after the deploy so you do not keep serving a response that was already stored wrong.
For teams on 15, the Next.js support policy extended security fixes for that version until January 31, 2027. The original date was October 21, 2026. That leaves less than three months to plan the move to 16. As I discussed in A supported version still calls for a migration decision, the end-of-support date is the limit; the work of finding out what breaks has to start before it.
For teams on 14 or earlier, this release has no patch. The way out is to migrate.
What is still unclear
The announcement does not list affected version ranges per issue; that information lives in the individual GitHub advisories. It also does not say whether any of the issues were exploited before the fix. And the shared shell poisoning issue appears in the announcement without a GHSA identifier, so there is no separate advisory to check yet.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
