Next.js Security Update: What the November 2026 Fixes Mean

Next.js 16.4.5 and 15.5.29, released on November 3, 2026, fix seven vulnerabilities, and the Next.js team recommends every project on those lines upgrade. Five of the seven only bite if you use Cache Components ('use cache') or self-host with next start, so many apps are not directly exposed, but the upgrade is a patch-level bump and the safest move is to take it today.

This guide covers what each flaw does in plain terms, how to tell whether your app matches the risky setups, the exact upgrade commands, and what to check after you deploy.

What the November 2026 Next.js security release fixes

Vercel announced the release a week early, on October 27, and published the patches and advisories on November 3. The table below lists the seven issues with the severity the Next.js blog gives each one and the setup that has to be present for it to matter.

Issue	Severity (Next.js blog)	You are exposed if
Cross-tenant cache disclosure (unstable_cache + use cache)	High	Cache Components is on and the same 'use cache' function that reads a root param is also called through unstable_cache()
Cross-root-param disclosure in nested use cache	Medium	Nested public 'use cache' functions where the inner one reads a root param and returns a slow async value
Cache disclosure and poisoning via binary arguments	Medium	You pass binary arguments that identify users or accounts into a 'use cache' function
Shared shell cache poisoning	Medium	Self-hosted next start with Cache Components on and Partial Prefetching off or unset, plus a specific nested dynamic route shape
Response injection through compressed response framing	Medium	Self-hosted, you return a fetched Response unchanged, and an HTTP/1.1 reverse proxy pipelines requests on a shared backend connection
Cookie values exposed in x-middleware-set-cookie	Medium	Edge runtime route handlers or Pages Router Edge API routes set cookies with NextResponse.cookies.set()
SVG rejection bypass in Image Optimization	Medium	You allow remote images and rely on images.dangerouslyAllowSVG: false, with an image backend that can decode SVG

One detail to know before you read the GitHub advisories: GitHub lists the cross-tenant cache flaw (GHSA-mfr8-8qww-v76h, CVE-2026-119790) as Moderate with a CVSS 4.0 score of 6.3, while the Next.js blog calls it High. When we checked on November 3, the advisory pages also still showed “Patched versions: None”, even though the blog and npm show 16.4.5 and 15.5.29 as the fixed releases.

Which of these matter for a typical app

If you run a standard App Router site on Vercel or another host and have never turned on cacheComponents in next.config, the four cache-related issues do not apply to you. Two flaws reach more apps:

• The Edge cookie leak (GHSA-f3mh-rxg3-f5g2, CVE-2026-119346). Affected versions are 15.0.0 through 15.5.28 and 16.0.0 through 16.4.2. If an Edge route sets a session cookie through NextResponse, the value is copied into an internal header that same-origin JavaScript can read, even when the cookie is marked HttpOnly. An attacker still needs their own script running on your origin, so this turns an existing XSS bug into session theft rather than creating one.
• The SVG bypass. A permitted remote image source can serve an SVG disguised as AVIF and reach the SVG decoder you turned off. The blog says this does not by itself show cross-site scripting or code execution, but it widens what an untrusted image host can feed your server.

The response-framing flaw needs a specific HTTP/1.1 proxy setup, and the shell-poisoning flaw needs a specific nested route shape. Both are self-hosting issues; read the advisory if you run next start behind Nginx, HAProxy or a similar proxy.

Check which Next.js version you run

Run one of these in your project folder:

npm ls next
pnpm why next
yarn why next

You need 16.4.5 or later on the 16.x line, or 15.5.29 or later on 15.5. The Next.js post names only these two release lines. If you are on 15.4 or older, or on 14.x, the post does not list a backport, so moving to 15.5.29 or 16.4.5 is the supported path. Check the individual advisories for whether your older version is in the affected range.

How to apply the Next.js security update

1. Create a branch and commit your current lockfile so you can roll back.
2. Install the patched version for your line: npm install next@16.4.5 or npm install next@15.5.29. With pnpm, use pnpm add next@16.4.5; with Yarn, yarn add next@16.4.5.
3. If you pin eslint-config-next or @next/* packages, bump them to the same version so they match.
4. Delete the .next folder, then run npm run build and your test suite.
5. Run npm ls next again and confirm only the patched version appears. A monorepo can hold a second copy in another workspace.
6. Deploy, then load a few pages that use caching, image optimization and sign-in to confirm they still behave.

If you cannot upgrade today

These are stopgaps from the advisories, not replacements for the patch:

• Stop calling 'use cache' functions through unstable_cache(). The advisory for GHSA-mfr8-8qww-v76h says that nesting is already unsupported and avoiding it fully works around the issue.
• On Edge routes, set sensitive cookies with cookies().set() instead of NextResponse.cookies.set(), or move those routes to the Node.js runtime. The blog says Node.js route handlers and cookies().set() were not affected in the reproduced leak.
• Narrow images.remotePatterns to hosts you control.
• If you self-host behind a proxy, turn off HTTP/1.1 request pipelining to the backend if your proxy allows it.

After you patch

Rotate any session secrets only if you have reason to think the Edge cookie leak was combined with an XSS bug on your site; the advisories do not report exploitation in the wild. If you use Cache Components with root params to separate tenants or locales, revalidate or purge those cache entries after deploying, because poisoned entries can persist until they are revalidated or evicted.

For a wider audit, our guide to checking the third-party scripts on your website helps cut the XSS risk that the cookie flaw depends on. If your deploys run through GitHub Actions, the changes covered in GitHub blocking pull_request_target are worth reviewing in the same session.

FAQ

Is my site on Vercel already protected?

The Next.js post does not say Vercel applied platform-level mitigations for these issues. Several flaws depend on your code and config rather than the host, so upgrade the next package regardless of where you deploy.

Are these flaws being exploited?

Neither the Next.js post nor the GitHub advisories we read on November 3, 2026 mention active exploitation. Treat that as “not reported yet” rather than “safe”: the advisories describe the flaws in enough detail to build test cases.

Do I need to upgrade React too?

No. The November 3 fixes are in the next package. Upgrade React only if your Next.js version requires it.

I use the Pages Router only. Am I safe?

Not entirely. The cookie leak also covers Pages Router Edge API routes that set cookies with NextResponse, and the SVG bypass applies to Image Optimization in either router.

Next step

Run npm ls next in each project now. If the version is below 16.4.5 or 15.5.29, patch it, then check whether any Edge route sets a session cookie through NextResponse. If the app also uses Better Auth, the Better Auth 1.7.16 security update came out the same day.

If your app uses Better Auth for sign-in, upgrade to Better Auth 1.7.16, which bundles 12 security fixes.

Sources

Facts checked on November 3, 2026 against the Next.js blog, the GitHub advisories listed below and the npm registry (latest: 16.4.5, backport: 15.5.29). Affected ranges for the five advisories not linked here were not independently verified.

• Next.js: November 2026 Security Release (Nov 3, 2026)
• Next.js: Upcoming Next.js November Security Release (Oct 27, 2026)
• GitHub advisory GHSA-mfr8-8qww-v76h
• GitHub advisory GHSA-f3mh-rxg3-f5g2