Next.js 16.4.5: which of 7 fixes hit your app

The Next.js blog calls one of this month's bugs High severity. GitHub rates all seven advisories Medium, and so do the project's own release notes. That gap is a good reason to read the advisories before treating Next.js 16.4.5 as an emergency. Four of the seven only touch 16.x apps using use cache or Cache Components, three also reach 15.x, and three apply only to self-hosted apps. By the end of this post you will know which ones hit your app, which have a workaround, and whether you need to clear caches after upgrading.

The November 2026 security release shipped on 3 November in v16.4.5 (Active LTS) and v15.5.29 (Maintenance LTS). Vercel's 27 October pre-announcement promised "seven medium vulnerabilities", which we covered alongside the 15.x support dates, and seven mediums is what GitHub published. If your Dependabot PR is the reason you are here, the table below is the short version.

What is fixed in Next.js 16.4.5, advisory by advisory

Every advisory below was published on 3 November 2026 and carries a GitHub severity of Medium under CVSS v4. Affected ranges come from each GitHub advisory, not from the blog.

Advisory	What leaks or breaks	Affected versions	Only if
GHSA-mfr8-8qww-v76h (6.3)	Cached data across root params	16.3.0 to 16.4.4	Same use cache function also called through unstable_cache
GHSA-vc7v-qv4w-wrv8 (6.3)	Cached data across root params	16.2.0 to 16.4.4	Nested use cache, inner reads a root param
GHSA-rhh4-g77r-r9qj (6.3)	Cached data across users	16.0.0 to 16.4.4	Binary arguments to use cache
GHSA-vvgp-ww4w-46vf (6.3)	Poisoned shared fallback shell	16.4.0 to 16.4.4	Self-hosted next start, Cache Components
GHSA-pc58-hwjq-p385 (6.3)	Responses swapped between clients	up to 15.5.28; 16.0.0 to 16.4.4	Self-hosted, HTTP/1.1 pipelining proxy
GHSA-f3mh-rxg3-f5g2 (6.0)	HttpOnly cookie readable by JavaScript	15.0.0 to 15.5.28; 16.0.0 to 16.4.4	Edge routes using NextResponse cookies
GHSA-7qx7-33qx-rqx2 (6.9)	SVG reaches the image decoder	15.0.0 to 15.5.28; 16.0.0 to 16.4.4	Self-hosted /_next/image

The four Cache Components bugs: is your multi-tenant cache leaking?

Root params are the route parameters of your root layout, and the mfr8 advisory notes that apps commonly use them to scope data, for example per locale. If yours scope data per tenant, three of these bugs can hand one tenant's cached output to another. None of the four applies to 15.x.

The unstable_cache and use cache workaround

GHSA-mfr8 needs a use cache function that reads a root param and is called both directly and through unstable_cache(). During a cold process start, a deduplication race lets the unstable_cache() call take a concurrent call's result and store it under a key without root params. The useful detail is in the advisory: outside that race, the pattern already throws 'use cache' inside unstable_cache() is unsupported, and avoiding the nesting is "a complete workaround". Search your logs and code for that error. If it never appears, you are probably not exposed.

Nested use cache and binary arguments

GHSA-vc7v hits an outer use cache function whose inner call reads a root param and returns an object mixing ready data with pending promises. The outer entry can be stored under a key that omits the root param, and the advisory adds that such entries "can also ignore tag invalidation and cache lifetimes". An attacker cannot choose what leaks; whichever request wrote the entry first wins.

GHSA-rhh4 is narrower. Distinct binary arguments, such as Uint8Array or Blob values, can produce the same cache key. It only matters if those bytes distinguish users or accounts.

Fallback shell poisoning and partialPrefetching

GHSA-vvgp needs five preconditions at once: cacheComponents: true with partialPrefetching unset or false, self-hosted next start, a generateStaticParams route requested with a value not built ahead of time, two never-prerendered params below it, and a blocking fallback shell. One unauthenticated GET can then store a 404 that the advisory says is served to every URL under the shell key "across server restarts". The documented workaround is partialPrefetching: true in next.config.

The three advisories that reach Next.js 15.5.29

The 15.x line gets three fixes in 15.5.29, and two of them only matter if you self-host. GitHub lists the pc58 range as everything up to 15.5.28 with no lower bound, and the only patched releases are 15.5.29 and 16.4.5. If you are still on 14.x, there is no patch for you to take.

Edge cookie leak. App Router Edge route handlers and Pages Router Edge API routes that set cookies with NextResponse copy the cookie into an internal x-middleware-set-cookie header that same-origin JavaScript can read, HttpOnly or not. The blog says impact needs attacker-controlled script already running on your origin, and that the reproduced leak did not affect Node.js route handlers or cookies().set().

Response desync behind a proxy. A self-hosted app that returns a fetched upstream Response unchanged can send decompressed bytes with the original compressed framing. Behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared backend connection, responses can land with the wrong clients. The blog stresses this "does not apply to every reverse-proxy configuration".

SVG through next/image. An attacker-controlled image from a source you already allow can be misclassified as AVIF and bypass dangerouslyAllowSVG: false, the default. The advisory scopes this to self-hosted deployments. The blog adds that your image-source allowlist still applies, that it needs a native image backend able to decode SVG, and that the finding does not itself show XSS or remote code execution.

Where the blog, GitHub and other coverage disagree

The blog labels the unstable_cache leak High. Its advisory scores it 6.3 Medium, and the v16.4.5 release notes list all seven under Moderate. Even Vercel's own 27 October notice promised seven mediums. Use GitHub's rating in your risk register.

Three smaller things. The blog gives no GHSA link for the fallback-shell issue; it is GHSA-vvgp-ww4w-46vf, linked from the release notes. Its install snippet comments next@16.4.5 as "for 16.5", which is a typo, since 16.5 is still a canary. And a Japanese explainer presents sharp ^0.35.5 as a 16.4.5 requirement. On the npm registry, that optional dependency is the same in 16.4.4, so moving from 16.4.4 changes nothing there.

Your bot may also offer 16.4.6, released on 9 November. Its notes list backported bug fixes and no advisories. It includes the November fixes, but 16.4.5 is the smaller change if you want a security-only release this week.

Are Vercel-hosted Next.js apps affected?

Neither the blog nor the seven advisories say whether hosting on Vercel changes exposure. Three advisories (vvgp, pc58 and 7qx7) describe self-hosted deployments in their own text. The other four describe application code paths: cache keys and Edge cookie headers. Nothing in the primary sources says a platform protects you from those, so treat them as applying wherever you deploy. If you are weighing self-hosting Next.js against Vercel, note that on the advisories' own wording, self-hosting widens this month's list from four to seven.

A ten-minute triage before the Next.js 16.4.5 upgrade

1. Check your version with npm ls next. On 16.4.4 or 15.5.28 you are one patch away; on anything before 16.4.1 you also missed the October 16.4.1 release.
2. Search for cacheComponents and 'use cache'. If neither appears, the four cache advisories do not apply.
3. If it is on, grep for unstable_cache, nested use cache calls, imports from next/root-params and binary arguments to cached functions.
4. Grep for export const runtime = 'edge' in route handlers that set cookies through NextResponse.
5. If you self-host, check whether your proxy pipelines HTTP/1.1 to the backend and whether images.remotePatterns allows sources you do not control.

The strongest argument against triage is that this is a patch release and upgrading takes less time than reading the advisories. For most teams that is true, and you should upgrade either way. Triage still matters, because the upgrade does not obviously clean up after itself. The mfr8 advisory says a leaked entry is served "until it is revalidated or evicted", and vvgp's poisoned 404 is stored with "revalidate": false. Neither advisory says the patch purges existing entries. If steps 2 and 3 hit, we would clear the cache handler's store when deploying 16.4.5, not just restart.

Do you need an out-of-cycle release this week?

Ship this week if you are multi-tenant with Cache Components and root params, or self-hosted with the proxy or image setup above. If none of the triage steps hit, roll Next.js 16.4.5 or 15.5.29 into your next normal release. If you want a second pair of eyes on a multi-tenant Next.js cache design, or help untangling a self-hosted setup from the proxy up, our web app development team builds in Next.js and TypeScript and can review the exposure with you before you schedule the release.