Next.js November 2026 security release: what to patch
On November 3, 2026, the Next.js team shipped its November security release: seven vulnerabilities fixed in Next.js 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS). None of them is a one-request remote code execution like some earlier 2026 Next.js bugs, but several can leak one user's or one tenant's data to another — exactly the kind of bug that turns into a privacy incident.
Here is what each advisory means in practice, which apps are actually affected, and how to upgrade.
The short version
- Fixed in:
next@16.4.5andnext@15.5.29. - Severity: one High, six Medium.
- Main theme: caching. Five of the seven issues involve
use cache,unstable_cacheand Cache Components serving content generated for one user, tenant or locale to another. - Most urgent if: you run a multi-tenant app on Cache Components, self-host with
next start, or use Edge routes that set sensitive cookies. - Action: upgrade and redeploy. On Netlify, also update the OpenNext adapter to v5.16.6.
npm install next@16.4.5 # 16.x
npm install next@15.5.29 # 15.5.x
The seven advisories
1. Cross-tenant cache disclosure with unstable_cache and use cache — High
GHSA-mfr8-8qww-v76h. If Cache Components are enabled and the same public use cache function is called both directly and from inside unstable_cache, and that function reads a root parameter such as a tenant ID, a concurrent call during a cold cache fill can receive another request's result. That result is then stored and served to later callers until it is revalidated or evicted. In a multi-tenant app, that means one customer can see another customer's data.
2. Cross-root-parameter disclosure in nested use cache — Medium
GHSA-vc7v-qv4w-wrv8. With nested public use cache functions, if an inner function reads a root parameter and returns an early value alongside a slower async value, and the outer function finishes without awaiting it, the outer entry can be stored before its root-parameter dependencies are recorded. Content for one tenant, site or locale can then be served to another.
3. Cache disclosure and poisoning via binary use cache arguments — Medium
GHSA-rhh4-g77r-r9qj. Different binary arguments (for example buffers or typed arrays) passed to a use cache function could produce the same cache key. If those arguments identify users or accounts, a caller can receive another user's cached result, or plant their own result for someone else.
4. Shared shell cache poisoning in self-hosted apps — Medium
Self-hosted apps on next start with Cache Components enabled and Partial Prefetching disabled or unset can have a shared page shell poisoned by an unauthenticated crafted URL. The result is wrong server-rendered content or persistent 404s for other URLs. It needs a specific route shape (a dynamic parameter requested with a value not generated at build time, two deeper never-prerendered parameters, and a blocking fallback shell), but if you match it, any visitor can trigger it.
5. Cross-client response injection through compressed response framing — Medium
GHSA-pc58-hwjq-p385. Self-hosted apps that return an attacker-controlled fetch() Response unchanged could forward decompressed body bytes with the original compressed framing headers. Behind an HTTP/1.1 reverse proxy that pipelines requests over a shared backend connection, responses can be assigned to the wrong clients. It requires that specific proxy behaviour.
6. Cookie values exposed through an internal header in Edge routes — Medium
GHSA-f3mh-rxg3-f5g2. Edge Route Handlers (App Router) and Edge API routes (Pages Router) that set cookies with NextResponse.cookies.set() could also expose the cookie in the internal x-middleware-set-cookie response header — which, unlike Set-Cookie, same-origin JavaScript can read, even for HttpOnly cookies. It only matters if an attacker can already run JavaScript on your origin, but it defeats the point of HttpOnly. Node.js route handlers and cookies().set() were not affected in the reproduction.
7. SVG rejection bypass in Image Optimization — Medium
GHSA-7qx7-33qx-rqx2. An attacker-controlled image from an allowed remote source could be misidentified as AVIF and get past images.dangerouslyAllowSVG: false, reaching the SVG parser you meant to exclude. Your remote image allowlist still applies, and the advisory does not show XSS or RCE from this alone, but it increases exposure to SVG decoder bugs — relevant given that a critical image-decoding bug reachable through sharp (CVE-2026-96889) was patched only weeks earlier in the October 14 update.
Am I affected?
Check your installed version:
npm ls next
Then work through this list:
- Using Cache Components /
use cache? Issues 1–4 are your priority, especially in multi-tenant apps where root parameters separate customers. - Self-hosting with
next start? Issues 4 and 5 apply only to self-hosted setups. - Edge routes that set session or auth cookies? Issue 6.
- Remote images with
next/image? Issue 7.
Pantheon notes that 15.5.29 includes fixes for issues 5, 6 and 7, while 16.4.5 includes all seven. Either way, upgrade to the latest release of your line.
How to upgrade
-
Update the dependency and lockfile:
npm install next@16.4.5 # or next@15.5.29 # pnpm add next@16.4.5 / yarn add next@16.4.5 -
Redeploy. A patched
package.jsondoes nothing until the new build is live. -
Purge caches after deploying if you use Cache Components in a multi-tenant app, so entries that may have been stored incorrectly before the fix are not served again.
-
Netlify users: update the OpenNext adapter to v5.16.6 as well; Netlify says upgrading Next.js alone does not fix the Middleware case on its platform.
-
If you are on an older major version (14.x or earlier), you are outside the supported LTS lines — plan the upgrade to 15.5 or 16.x.
What I would do this week
- Upgrade every Next.js app to 16.4.5 or 15.5.29 and redeploy, starting with multi-tenant and logged-in apps.
- Review how your app keys cached data: never rely on a cache entry being per-user unless the user or tenant ID is an explicit part of the cache key.
- Audit Edge routes that set cookies, and keep sensitive session cookies on Node.js routes where possible.
- Keep
images.dangerouslyAllowSVGoff, keep your remote image allowlist tight, and make sure sharp is on 0.35.5 or later. - Subscribe to the Next.js security advisories — 2026 has seen a security release almost every month.
If you need help auditing or upgrading a Next.js or WordPress deployment, book a free consultation.
