Next.js November 2026 security release: are you affected, and how to patch (16.4.5 and 15.5.29)

On 3 November 2026, the Next.js team released 16.4.5 and 15.5.29 to fix seven security issues. The most serious is a cache bug: in apps that use use cache, data cached for one tenant or locale can be served to another.

Four of the seven involve Cache Components and only affect Next.js 16. That used to be a small group. Since Next.js 16.4, every new project made with create-next-app has Cache Components on by default, so it's now worth checking rather than assuming. The other three also affect Next.js 15.

Short version: run npm ls next. If you're on 16.x below 16.4.5, or 15.x below 15.5.29, upgrade and redeploy. If your app uses use cache together with root parameters, also clear your caches after the upgrade, because wrong entries can outlive the fix.

Last checked: 15 November 2026, against the Next.js blog post and the seven GitHub advisories.

The seven issues at a glance

A note on severity. The Next.js blog post labels the first issue "High Severity" and the other six medium. On GitHub, all seven advisories are rated Moderate, with CVSS scores between 6.0 and 6.9. Either way, none is a remote code execution bug like the two in the October release.

What each one means in plain words

Cached data served to the wrong tenant or locale

A root parameter is a dynamic segment that sits before the root layout, for example the [tenant] in app/[tenant]/layout.tsx or the [lang] in app/[lang]/layout.tsx. Code reads it with next/root-params. Apps use it to decide whose data, or which language, a page shows.

Three of the cache bugs break that separation:

• unstable_cache plus use cache. Just after a server process starts, an unstable_cache call can pick up the result of another request's use cache call that is still in flight. It then stores that result under a key that ignores the root parameter. From then on, requests for other tenants or locales get the same entry until it's revalidated or evicted.
• Nested use cache functions. An outer cached function can be stored under a key that leaves out the root parameter its inner function read. The advisory adds that entries written this way can ignore tag invalidation and cache lifetimes.
• Binary arguments. Two different Uint8Array or Blob arguments can produce the same cache key, so one user can get another's cached result.

In all three, an attacker can't choose what leaks. Which data gets served depends on which request filled the cache first.

Shared shell poisoning (self-hosted)

On a self-hosted app, one unauthenticated request with a crafted URL can poison a page shell that a family of routes shares. Depending on the app, visitors then get either a 404 that sticks, including across server restarts, or server-rendered HTML showing the attacker's parameter value until the page hydrates. The advisory says no script injection is possible and no data is disclosed.

Response mix-up behind some reverse proxies (self-hosted)

If your app passes a fetched response straight through, Next.js could send a body that doesn't match the response's declared framing. Behind an HTTP/1.1 proxy that queues pipelined responses on a shared connection, responses can end up assigned to the wrong client. The team is explicit that this needs that specific proxy behaviour and doesn't apply to every setup.

HttpOnly cookies readable on Edge routes

Edge routes that set cookies through NextResponse repeat the cookie in an internal x-middleware-set-cookie response header. Unlike Set-Cookie, page JavaScript on the same origin can read that header, even when the cookie is marked HttpOnly. It isn't a way to run JavaScript by itself. It makes an existing XSS hole worse, because a session cookie that should be out of reach no longer is. In the reported tests, Node.js Route Handlers and cookies().set() were not affected.

SVG reaching a parser you switched off (self-hosted)

On self-hosted deployments, the image optimizer can be made to process an attacker-supplied SVG even with dangerouslyAllowSVG: false, which is the default. Your allowlist of image sources still applies. The finding doesn't by itself demonstrate script execution or code execution; it increases exposure to denial of service and to bugs in the SVG decoder.

Am I affected?

1. Check your version.

npm ls next 

Below 16.4.5 on the 16 line, or below 15.5.29 on the 15 line, means you haven't got the fixes.

2. Check whether Cache Components is on. Look in next.config.ts (or .js, .mjs):

const nextConfig: NextConfig = { cacheComponents: true, // if this line is here, the four cache issues can apply }; 

Also search for the older experimental names, dynamicIO and useCache, which cacheComponents replaced.

3. Search for the risky patterns.

grep -rn "next/root-params" app src grep -rn "use cache" app src grep -rn "unstable_cache" app src grep -rn "cookies.set" app src pages 

No next/root-params anywhere means the first two issues don't apply to you. If you're on 15.x, only the last three rows of the table can apply, since the cache issues are all 16-only.

How to patch

npm install next@16.4.5 # if you're on 16 npm install next@15.5.29 # if you're on 15.5 

Then run your build and tests, and redeploy.

Then deal with the cache

Upgrading stops new wrong entries. It doesn't remove ones already stored. What to clear depends on which pattern you matched:

• use cache entries. By default these live in memory and belong to one deployment, so a fresh deployment starts clean. If you use use cache: remote or a custom cache handler backed by Redis or similar, purge it. Don't rely on tag invalidation alone here, given what the nested-cache advisory says.
• unstable_cache entries. These persist across deployments, so the wrong entry from the first issue survives a redeploy. Revalidate the tags on the affected unstable_cache calls, or purge the data cache at your host.
• Poisoned shells (self-hosted). The advisory says the stuck 404 survives server restarts, so a restart alone isn't enough. Rebuild and deploy the patched version. I haven't tested exactly which files hold the entry, so if stale shells remain after that, clear your cache handler's storage too.

If you run a multi-tenant app and matched one of the root-parameter patterns, work out which routes could have served another tenant's data and for how long. Whether that counts as a reportable incident depends on what the data was; that's a question for whoever handles compliance for you.

Fixed versions were published for the 16.4 line (Active LTS) and the 15.5 line (Maintenance LTS). If you're on 14 or older, check the Next.js support policy and plan an upgrade.

If you can't upgrade today

Only the upgrade fixes all seven. These reduce exposure in the meantime:

• Don't call a use cache function from inside unstable_cache. The advisory describes that nesting as unsupported and says avoiding it is a complete workaround for the first issue.
• Self-hosting with Cache Components? Set partialPrefetching: true. The shell-poisoning advisory lists this as its workaround.
• Don't pass binary values to a use cache function. Pass a string ID.
• On Edge routes, don't set sensitive cookies through NextResponse. In the reported tests, Node.js Route Handlers and cookies().set() didn't leak.
• Only allow image sources you fully control in images.remotePatterns.

The last three are my reading of the conditions in each advisory, not official workarounds.

FAQ

I'm on a managed host. Do I still need to upgrade?

Yes. Three of the seven are described as affecting self-hosted apps (shell poisoning, the response mix-up and the SVG bypass). The three cache-key issues and the Edge cookie issue are not limited to self-hosting.

I don't use Cache Components. Can I skip this?

No. The response mix-up, Edge cookie and SVG issues don't depend on it, and they affect 15.x as well. It's a patch release, so the upgrade should be low risk.

My app is single-tenant. Do the cache issues matter?

They can. Root parameters are commonly used for locales. The worst case for you may be the wrong language's content rather than another customer's data, but it's the same bug.

I created my app before 16.4. Is Cache Components on?

Only if you enabled it. The default changed for new projects from create-next-app in 16.4. Existing apps keep whatever is in their config.

Wasn't there a Next.js security release last month too?

Yes, on 14 October 2026, fixing two critical remote code execution bugs and a denial-of-service issue in 16.4.1 and 15.5.28. Version 16.4.5 includes those fixes as well. I covered them at the end of my PHP2Shell post.

Sources

• Next.js: November 2026 Security Release
• GitHub advisories for vercel/next.js
• Next.js: Security Update for Upstream Vulnerabilities, 14 October 2026
• Next.js docs: next/root-params
• Next.js docs: Migrating to Cache Components

Need a hand upgrading, or want someone to check whether your caching could have mixed up tenants? Get in touch. For the wider picture, see my Server Actions security checklist.

Originally published on vishalsolanki.online.