The patch is out. On Tuesday, November 3, 2026 Vercel shipped the scheduled Next.js security update as v16.4.5 on the Active LTS line and v15.5.29 on the Maintenance LTS line.[1] The release closes seven advisories - one high severity and six medium - and this time the full details are public: GHSA identifiers, affected versions, exploit conditions, and per-issue guidance.[1] There is nothing left to wait for. If you run Next.js on your own server, your part starts now.

If you are on Vercel, the patched version is already rolling through their infrastructure and there is likely nothing for you to do beyond not blocking deploys. If you self-host on a VPS, the patched code is whatever a freshly rebuilt .next/standalone folder ships - and nothing reaches your users until you update the dependency, rebuild the artifact, and restart the running process. That asymmetry is the whole reason this guide exists.

What the release contains

Two versions landed on November 3:[1]

  • v16.4.5 (Active LTS) - fixes all seven advisories in this batch.[1][2]
  • v15.5.29 (Maintenance LTS) - fixes three of the seven.[3] The four it does not cover are all in the Cache Components / use cache feature set that only exists on the 16.x line, so they are not present in 15.x at all.

The install commands Vercel publishes are literal and version-pinned:[1]

npm install next@16.4.5    # 16.x Active LTS line
npm install next@15.5.29   # 15.x Maintenance LTS line

Do not mistake this for last week’s situation. Before November 3 there were no CVE identifiers or affected-version ranges in the open, and anyone circulating a “CVE list” ahead of the release was guessing.[1] Now the advisories are live on GitHub, each with its own GHSA identifier, affected-version range, CVSS scoring, and exploitation detail.[4][5][6][7][8][9][10] Update against those, not against hearsay.

The seven advisories at a glance

All seven are fixed in v16.4.5; v15.5.29 covers the three marked with an asterisk.[1][2][3]

Severity GHSA Surface What the attacker does Affected config
High GHSA-mfr8-8qww-v76h Cache Components (unstable_cache combined with use cache) - cross-tenant disclosure During a cold cache fill, a concurrent call routed through unstable_cache receives another request’s result without a root-parameter check, then serves it to later callers of the same key Cache Components enabled; a public use cache function that reads a root parameter (e.g. tenant ID) and is also called through unstable_cache; affected >= 16.3.0[4]
Medium GHSA-vc7v-qv4w-wrv8 Cache Components - nested use cache functions (cross-root-parameter disclosure) Inner cache entry’s root-parameter dependencies are recorded late, so the outer entry is persisted under a key that omits the root param and is reused across tenant/site/locale values Nested public use cache functions where the inner function reads a root param and returns an early value alongside a slower async value; affected 16.2.0 - 16.4.2[5]
Medium GHSA-rhh4-g77r-r9qj Cache Components - use cache with binary arguments (cross-user disclosure / poisoning) Distinct binary arguments (e.g. Uint8Array, Blob) produce the same cache identity, so one user’s cached result can be served to another use cache functions that receive security-significant binary arguments and share entries across callers; affected 16.0.0 - 16.4.2[6]
Medium GHSA-vvgp-ww4w-46vf Self-hosted Cache Components - shared shell cache poisoning One unauthenticated crafted GET can plant request-supplied values into a fallback shell shared by a whole route family, yielding persistent 404s or incorrect server-rendered content Self-hosted next start with Cache Components enabled and Partial Prefetching unset/false; affected >= 16.4.0[7]
Medium * GHSA-pc58-hwjq-p385 Self-hosted response forwarding - stale compressed framing An attacker-controlled fetched Response is forwarded unchanged, leaking decompressed body bytes with the original compressed framing; behind an HTTP/1.1 proxy that queues pipelined requests, responses can land on the wrong client App returns an attacker-controlled fetched Response unchanged, behind an HTTP/1.1 reverse proxy sharing one backend connection; not every proxy layout is exposed[8]
Medium * GHSA-f3mh-rxg3-f5g2 Edge runtime routes - cookie exposure The serialized cookie set via NextResponse.cookies.set() leaks into the internal x-middleware-set-cookie header, which same-origin JavaScript can read even for HttpOnly cookies Edge Route Handlers / Edge API routes setting cookies with NextResponse.cookies.set(); Node runtime routes and cookies().set() are not affected[9]
Medium * GHSA-7qx7-33qx-rqx2 Image Optimization - SVG rejection bypass An image from a permitted source is misclassified as AVIF, bypassing images.dangerouslyAllowSVG: false, and the backend decodes the original bytes as SVG A native image backend able to decode SVG; the image-source allowlist still applies[10]

(*) Also fixed in v15.5.29.[3]

Severity labels follow the release announcement.[1] Note one quirk worth knowing if you cross-check the GitHub advisory pages: the GitHub advisory records rate GHSA-mfr8-8qww-v76h as moderate on the CVSS v4 scale, while Vercel’s release post classifies it as high severity.[1][4] Both are primary sources; we reproduce the release post’s labeling here, and the practical conclusion is identical either way - if you run Cache Components on 16.x, prioritize this update.

The self-hosted deep dive

Four of the seven advisories matter most to anyone reading a VPS hosting site, because they describe the specific shape of a self-hosted deployment rather than a Vercel-specific behavior. Three are explicitly tagged self-hosted in their titles, and the high-severity Cache Components disclosure applies to any self-hosted app using the feature.[4][7][8][9]

Shared shell cache poisoning (next start + Cache Components). GHSA-vvgp-ww4w-46vf is the one most directly aimed at self-hosters, and its trigger conditions read exactly like a production app: next start, Cache Components on, Partial Prefetching unset or off.[7] A crafted URL can store request-supplied route-param values into a fallback shell that a whole family of routes shares. The practical blast radius is either a persistent 404 served to every URL under the poisoned shell key, or server-rendered HTML that substitutes the attacker’s param value for the visitor’s own (a JS client corrects it on hydration; no markup or script injection, no data disclosure).[7] The immediate workaround, if you cannot upgrade right away, is to set partialPrefetching: true in next.config.[7] The permanent fix is the version bump.

Cross-client response injection behind an HTTP/1.1 proxy. GHSA-pc58-hwjq-p385 sits at the exact boundary of the stack this site is built around - your app returns an attacker-controlled fetched Response unchanged, and nginx in front of it terminates TLS and proxies over a shared backend connection.[8] If that proxy queues pipelined requests on the same connection, the compressed-response framing mismatch can assign a response to the wrong client, letting an attacker who can arrange requests on that connection inject a response for another client or read another client’s response.[8] Importantly, this is a conditional issue: it requires the app to forward an attacker-controlled response and requires the proxy to queue pipelined requests - it does not apply to every reverse-proxy layout.[8] Audit whether your app route handlers return fetched responses verbatim, and note that a clean fix in v16.4.5 or v15.5.29 removes the class of bug regardless of your proxy behavior.

Edge-route cookie leak. GHSA-f3mh-rxg3-f5g2 affects App Router Edge Route Handlers and Pages Router Edge API routes that set cookies through NextResponse.cookies.set().[9] Those set a cookie into an internal x-middleware-set-cookie response header, and unlike Set-Cookie, that header is readable by same-origin JavaScript - so even a cookie marked HttpOnly can be read.[9] Impact requires a sensitive cookie set on an affected response plus attacker-controlled JS on the same origin, and it does not apply to Node.js route handlers or to cookies().set().[9] If you run any Edge runtime routes on an app with authentication, check that they are not the cookie-setting path, then update.

Cross-tenant cache disclosure. GHSA-mfr8-8qww-v76h is the high-severity finding, and it is directly relevant to any self-hosted app with Cache Components that segments data by a root parameter - typically a tenant ID in a multi-tenant deployment.[1][4] In a cold-fill race, a call routed through unstable_cache can grab a concurrent direct call’s result without the root-parameter check, cache it under a key with no tenant scoping, and serve it to later callers.[4] A tenant identifier is exactly the kind of value this pattern is meant to protect, so a multi-tenant 16.x app with Cache Components is the highest-priority upgrade of this batch.

Am I affected?

If you run any 16.x version older than v16.4.5 and use any of these features - Cache Components, use cache, Edge runtime routes that set cookies, or image optimization on a native-capable backend - treat yourself as in scope and update.[1][2][4][5][6][7] The specific affected-version ranges the advisories publish upstream (for example >= 16.3.0 for the high finding, 16.0.0 - 16.4.2 for the binary-argument one) are worth reading on the individual advisory pages, because some branches were already fixed in 16.4.2.[4][5][6] On the 15.x line, v15.5.29 fixes the three applicable advisories, and 15.x does not carry the Cache Components code at all, so the other four do not apply there.[1][3]

The honest way to find out what you run is on the server, against the deployed artifact, not from memory:

npm ls next
node -e "console.log(require('./.next/standalone/node_modules/next/package.json').version)"

npm ls next shows what the dependency graph resolves to; the second command shows what actually made it into the standalone bundle you shipped. If the two disagree, your deploy is behind your intent - and the security release is the moment to fix that.

The verified update procedure for a standalone build

The sequence below assumes the standard self-hosted stack we cover in our VPS deploy guide: a standalone build, a Node runtime, the process supervised under PM2 (or an equivalent), and nginx in front as a reverse proxy. Security updates are the same loop as any deploy, just with the version pinned to the advisory.

Step 1 - Confirm the affected version

Read the relevant advisory and note both the exact patched version and whether your running version is in the affected range.[2] If your line is 16.x, target v16.4.5; if it is 15.x, target v15.5.29.[1]

Step 2 - Update the pinned dependency

On the build machine:

npm install next@16.4.5    # or next@15.5.29 on the 15.x line
git add package.json package-lock.json
git commit -m "chore(deps): update next.js to 16.4.5 (November 2026 security release)"

Pin it and let the lockfile carry the change so review sees exactly what moved. If you evaluated whether a transitive dependency (like sharp, which the October batch flagged) matters for your image pipeline, verify it resolved as expected:

npm ls sharp

Step 3 - Rebuild the standalone artifact

Run your normal production build with output: 'standalone' set, which regenerates .next/standalone with the patched code - and any patched native dependency - baked in:[11]

npm run build

A build on its own does nothing to a running server. It only prepares the artifact you are about to ship.

Step 4 - Deploy the artifact and restart the running process

Copy the new .next/standalone (and your static assets) to the server, then restart the framework process so the running Node runtime loads the patched code. The restart is non-optional: a process holds the old code in memory until you restart it. If you run several instances, restart them all.

pm2 restart <app>          # or: sudo systemctl restart next-app

Step 5 - Smoke-test through nginx, not around it

Because your nginx config terminates TLS and proxies to the app, test the path your users actually take:

curl -I https://your-domain/            # expect 200, served through nginx
curl -I https://your-domain/some-page

Hit a dynamic route and an API route, and if your app uses Cache Components, exercise a page or route that touches it - that is where most of this batch lives. Confirm pm2 status (or your supervisor) shows the process healthy and that nginx logs show no 5xx burst.

Step 6 - Record the before/after version

Note the pre- and post-upgrade versions in your runbook. Two fixed lines now exist - 16.4.5 and 15.5.29 - and knowing which line you are on next time makes the next advisory a near no-op. A lightweight monthly npm outdated next per project catches drift before the next scheduled release.

The short version

Next.js patched v16.4.5 (Active LTS) and v15.5.29 (Maintenance LTS) on November 3, 2026, closing seven advisories - one high and six medium.[1] The high-severity finding (GHSA-mfr8-8qww-v76h) discloses cached data across tenants when Cache Components and unstable_cache are combined, and three medium advisories are explicitly self-hosted: shared-shell cache poisoning on next start, cross-client response injection behind an HTTP/1.1 reverse proxy, and HttpOnly cookie exposure on Edge routes.[4][7][8][9] v15.5.29 fixes three of the seven; 15.x does not carry the Cache Components code the other four live in.[3] Install next@16.4.5 (or next@15.5.29), rebuild the standalone artifact, restart the process, and smoke-test through nginx. On Vercel the platform patches itself; on your VPS, you are the patch - and with the standalone + Node + nginx stack from our deploy guide, this is a twenty-minute, verifiable upgrade.

Sources

  1. Next.js - “November 2026 Security Release” (2026-11-03): releases v16.4.5 (Active LTS) and v15.5.29 (Maintenance LTS); seven advisories, one high and six medium severity; install commands npm install next@16.4.5 / npm install next@15.5.29; grading of GHSA-mfr8-8qww-v76h as high severity. https://nextjs.org/blog/november-2026-security-release - checked 2026-11-04
  2. GitHub - vercel/next.js release v16.4.5 (2026-11-03): fixes all seven advisories in this batch. https://github.com/vercel/next.js/releases/tag/v16.4.5 - checked 2026-11-04
  3. GitHub - vercel/next.js release v15.5.29 (2026-11-03): fixes GHSA-pc58-hwjq-p385, GHSA-7qx7-33qx-rqx2, and GHSA-f3mh-rxg3-f5g2 (3 of 7). https://github.com/vercel/next.js/releases/tag/v15.5.29 - checked 2026-11-04
  4. GitHub Security Advisory GHSA-mfr8-8qww-v76h - information disclosure across root params when a use cache function is called through unstable_cache(); affected >= 16.3.0. https://github.com/vercel/next.js/security/advisories/GHSA-mfr8-8qww-v76h - checked 2026-11-04
  5. GitHub Security Advisory GHSA-vc7v-qv4w-wrv8 - cache leak across root param values in nested use cache functions via delayed inner stream metadata; affected 16.2.0 - 16.4.2. https://github.com/vercel/next.js/security/advisories/GHSA-vc7v-qv4w-wrv8 - checked 2026-11-04
  6. GitHub Security Advisory GHSA-rhh4-g77r-r9qj - cross-user cache disclosure and poisoning in use cache with binary arguments; affected 16.0.0 - 16.4.2. https://github.com/vercel/next.js/security/advisories/GHSA-rhh4-g77r-r9qj - checked 2026-11-04
  7. GitHub Security Advisory GHSA-vvgp-ww4w-46vf - cache poisoning of shared fallback shells in Cache Components via request-supplied placeholder route params (next start, Partial Prefetching unset/false; workaround partialPrefetching: true); affected >= 16.4.0. https://github.com/vercel/next.js/security/advisories/GHSA-vvgp-ww4w-46vf - checked 2026-11-04
  8. GitHub Security Advisory GHSA-pc58-hwjq-p385 - cross-client response injection and disclosure through stale compressed response framing behind an HTTP/1.1 reverse proxy. https://github.com/vercel/next.js/security/advisories/GHSA-pc58-hwjq-p385 - checked 2026-11-04
  9. GitHub Security Advisory GHSA-f3mh-rxg3-f5g2 - HttpOnly cookie exposure through the internal x-middleware-set-cookie header on Edge runtime routes; Node runtime routes and cookies().set() not affected. https://github.com/vercel/next.js/security/advisories/GHSA-f3mh-rxg3-f5g2 - checked 2026-11-04
  10. GitHub Security Advisory GHSA-7qx7-33qx-rqx2 - SVG rejection bypass in Image Optimization (AVIF misclassification); image-source allowlist still applies. https://github.com/vercel/next.js/security/advisories/GHSA-7qx7-33qx-rqx2 - checked 2026-11-04
  11. Next.js - output config reference (with output: 'standalone', next build creates .next/standalone, a self-contained folder deployable without installing node_modules; built via output file tracing). https://nextjs.org/docs/app/api-reference/config/next-config-js/output - checked 2026-11-04