Does the Next.js November security release affect your app?
Seven advisories, fixed in Next.js 16.4.5 and 15.5.29. Patch today if you use use cache, Edge cookies or self-host. npm audit showed zero.
Senior Full-Stack Engineer- Published
- 10 minReading time
- EngineeringCategory
Listen to this post· AI-narrated
0:00 / 11:36On 4 November I ran npm audit on a small Next.js 16.4.4 app and got found 0 vulnerabilities. Minutes earlier, that same version had answered my test requests for /fr and /de with the page it cached for /pt. The bug is one of seven advisories in the Next.js November security release, which shipped on 3 November in 16.4.5 and 15.5.29. Everyone should patch, and how fast depends on what's in your code: use cache, Edge routes that set cookies, self-hosting, and your major version. I reproduced two of the seven on a throwaway app, so the checks below come with real output.
TL;DR: The Next.js November security release only bites if you use use cache, set cookies on Edge routes, or self-host. If you do, patch to 16.4.5 or 15.5.29 today; if you don't, this week. Don't wait for npm audit: on 4 November it reported zero on a version I watched leak.
Which versions does the Next.js November security release patch?
Next.js 16.4.5 and 15.5.29 carry the fixes, published on 3 November 2026 (Next.js (opens in a new tab)). 16.4.4 came out the day before and has none of them, so a team that upgraded on Monday is still exposed. All seven advisories touch the 16 line. The 15 line gets three, because the four use cache bugs are 16 only (15.5.29 release notes (opens in a new tab)).
If you're below 16.4.1 or 15.5.28, the same upgrade also picks up October's fixes, and those can't wait. The 14 October update (opens in a new tab) fixed two critical unauthenticated remote code execution bugs, one in use cache functions returning typed arrays and one in the image optimizer. Next 14 has no patched release: the advisories list it as affected by that image bug and by one of November's, and the newest 14.x on npm is still 14.2.35 from December 2025. Move to 15.5.29.
Don't rank these by severity label. The Next.js post calls the unstable_cache leak High. The 27 October notice (opens in a new tab) promised "seven medium vulnerabilities", the 16.4.5 release notes (opens in a new tab) list all seven as Moderate, and the advisory itself (opens in a new tab) says medium, CVSS 6.3. Go by which features you have.
How do you check if your Next.js app has the affected features?
Read your config and run a few git grep calls at the repo root:
npm ls next
grep -nE "cacheComponents|partialPrefetching|dangerouslyAllowSVG" next.config.*
git grep -l "next/root-params" -- '*.ts' '*.tsx'
git grep -l "unstable_cache" -- '*.ts' '*.tsx'
git grep -lE "runtime['\"]? *[:=] *['\"](experimental-)?edge" -- '*.ts' '*.tsx' '*.js'
git grep -lE "['\"]use cache" -- '*.ts' '*.tsx' | xargs grep -lE "Uint8Array|ArrayBuffer|Blob"
A root param is a param of your root layout, such as [lang] or [tenant], read through next/root-params. Match your hits against this table. The first four rows use use cache, which belongs to the Cache Components model behind the cacheComponents flag:
| Your app has | Advisory | Lines | What can happen |
|---|---|---|---|
Nested use cache where the inner function reads a root param and returns a pending promise | GHSA-vc7v (opens in a new tab) | 16.2 and up | One tenant's or locale's content served to another |
A use cache function reading a root param, called directly and through unstable_cache | GHSA-mfr8 (opens in a new tab) | 16.3 and up | The same leak, if requests race on the first fill after a process start |
Binary arguments such as Uint8Array or Blob passed to use cache | GHSA-rhh4 (opens in a new tab) | 16 | One user gets or poisons another's cached result |
next start, cacheComponents: true, Partial Prefetching off, and the route shape the advisory describes | GHSA-vvgp (opens in a new tab) | 16.4 and up | One request stores a lasting 404 or a wrong param value |
An Edge route that sets a cookie through NextResponse | GHSA-f3mh (opens in a new tab) | 15, 16 | Same-origin JavaScript can read HttpOnly cookies |
Self-hosted /_next/image | GHSA-7qx7 (opens in a new tab) | 15, 16 | An SVG reaches a parser you turned off |
Self-hosted route returning a fetched Response unchanged, behind an HTTP/1.1 proxy that queues pipelined requests | GHSA-pc58 (opens in a new tab) | Below 16, and 16 | Responses reach the wrong client |
Check the config line even if you never chose Cache Components: since 16.4, create-next-app turns it on for new apps (Next.js 16.4 (opens in a new tab)). Existing apps stay off until someone sets the flag.
I ran these on Vercel's public App Router playground (opens in a new tab), which is on 16.4.0-canary.12 with both Cache Components and Partial Prefetching on. It has 34 TypeScript files with use cache and no hits for root params, unstable_cache, Edge routes or binary types, so plenty of use cache alone doesn't put an app in the first two rows. The binary grep only sees types written in the same file, so read the signature of any cached function that takes bytes.
Can the Next.js cache serve one locale's page to another?
Yes. I reproduced GHSA-vc7v with this pattern, in a production build under next start on Node 26.13.0 and macOS. lang comes from next/root-params, and the app has a [lang] root layout:
async function getInner() {
"use cache"
const value = await lang()
return { ready: value, slow: new Promise<string>((resolve) => setTimeout(() => resolve(value), 300)) }
}
async function getOuter() {
"use cache"
const inner = await getInner()
return `content-for-${inner.ready}`
}
The inner function hands back a ready value next to a slow promise, and the outer one finishes before the root param dependency gets recorded. Same requests, same order:
| Request | 16.4.4 | 16.4.5 |
|---|---|---|
/pt | content-for-pt | content-for-pt |
/fr | content-for-pt | content-for-fr |
/de | content-for-pt | content-for-de |
16.4.2 and 16.4.3 behaved like 16.4.4. The trigger is narrow: on 16.4.4 the leak went away when I dropped the slow promise, when the outer function awaited it, and when I passed lang as an argument. No grep finds that shape, so read the cached functions in your root param hits for objects holding unresolved promises. The advisory says an attacker can't choose what leaks, because whichever request writes the entry first decides. With a tenant slug as the root param, what leaks is still another customer's page. Tenancy read from a header or a deeper route param falls outside the two root param rows.
Restarting and rebuilding don't clear it when the cache lives outside the process. With a small disk-backed cacheHandlers entry, the wrong entries survived a restart and a rebuild on 16.4.4, with both the default build ID and one pinned through generateBuildId. Upgrading to 16.4.5 and rebuilding stopped them being served, though the old files were still on disk. I tested that on this one advisory, so purge a shared store anyway.
Why does npm audit say Next.js 16.4.4 is clean?
npm audit had no data for these advisories yet. On 4 November at 20:06 UTC, about 25 hours after they went public, npm's advisory endpoint returned nothing for next 16.4.2 through 16.4.5. npm audit printed found 0 vulnerabilities and bun audit printed No vulnerabilities found. The advisories are live on the Next.js repository, while the GitHub Advisory Database page (opens in a new tab) for the nested leak returned a 404.
The version data on the advisories runs early too, which is why the table above only gives the lines each one starts on. GHSA-vc7v lists 16.4.2 as its first patched version, and it leaked on 16.4.2, 16.4.3 and 16.4.4 in my test. The cookie bug's range ends at 16.4.2, and 16.4.4 still sent the header below. The release notes for 16.4.3 and 16.4.4 list no security fixes. Until the feed catches up, a clean audit says nothing about this release, so compare npm ls next to 16.4.5 or 15.5.29 by hand.
Does the Next.js Edge bug expose HttpOnly cookies?
Next.js Edge routes on affected versions send the cookie twice, and the copy isn't protected by HttpOnly. I set one cookie with NextResponse on an Edge route and on a Node.js route, then read the headers with curl -i:
| Route | Cookie headers in the response |
|---|---|
| 16.4.4 Edge | set-cookie: session=test-value; Path=/; HttpOnly and x-middleware-set-cookie: session=test-value; Path=/; HttpOnly |
| 16.4.4 Node.js | set-cookie: session=test-value; Path=/; HttpOnly |
| 16.4.5 Edge | set-cookie: session=test-value; Path=/; HttpOnly |
A Pages Router Edge API route showed the same extra header on 16.4.4. A cookie set in proxy.ts under next start did not. An attacker still needs JavaScript running on your origin, so this doesn't open a hole by itself. It means an XSS bug elsewhere on the site can read a session token you marked HttpOnly.
The App Router keeps this bug and the cache bugs apart. My first build failed with Route segment config "runtime" is not compatible with nextConfig.cacheComponents, and one developer on r/nextjs said adopting Cache Components was "mostly migrating an edge route back to node" (opens in a new tab). So with the flag on, start at the use cache rows, plus any Pages Router Edge API routes. With App Router Edge routes, start here.
Which Next.js advisories depend on where you host?
The image bypass and the response mix-up are self-hosted problems in their advisories, and Netlify agrees for its platform. Shell poisoning is written for next start, but Netlify says (opens in a new tab) its apps with that route shape are affected too, so don't assume a host covers you. Netlify also rules out the unstable_cache race and keeps the nested leak, the binary arguments bug and the cookie bug on its list. Its Middleware cookie case needs adapter 5.16.6, and old deploy previews can stay vulnerable until they're deleted. Vercel's security bulletins (opens in a new tab) had no entry for this release when I checked on 4 November, so on Vercel, go by the table.
If you self-host with Cache Components, shell poisoning is the one I'd patch for today. I didn't reproduce it, and its preconditions are narrow. When they line up, the advisory says one unauthenticated GET can store a 404 served to every URL under that shell, across restarts, with no error logged. partialPrefetching: true is its workaround if you can't upgrade right away.
What to do today
Run npm ls next first. Below 16.4.1 or 15.5.28, you're also missing October's critical fixes, so stop and upgrade now. Everyone else, install next@16.4.5 or next@15.5.29, rebuild and redeploy, then delete old previews that can reach real data. Run the greps. If a root param separates customers and a cached function returns pending promises, treat it as a possible data exposure: review what those functions return per tenant and purge any shared cache store. Run the audit again next week, once the feed has these advisories.
I write about upgrades, stacks and building with agents on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.