Next.js Security Release November 2026: Upgrade to 16.4.5

Next.js shipped its November 2026 security release on 3 November: seven vulnerabilities, all rated medium in their GitHub advisories, fixed in Next.js 16.4.5 and 15.5.29. If you run a Next.js app, the short answer is to upgrade today. The longer answer depends on what your app uses. Four of the seven issues sit in use cache and Cache Components, and three only matter for self-hosted apps. I went through every advisory, checked the release notes and the npm packages, and wrote a small script that tells you whether your installed version is patched. Here's what each Next.js vulnerability does, how to tell if you're affected, and how to upgrade.

What the Next.js November 2026 security release fixes

Vercel announced the release a week early, on 27 October, as a scheduled security release covering "seven medium vulnerabilities". The advisories and packages went out on 3 November (just after midnight on 4 November in Sri Lanka):

• 16.4.5 (Active LTS) fixes all seven.
• 15.5.29 (Maintenance LTS) fixes the three that reach the 15.x line.
• There is no new 14.x release. The next-14 tag on npm is still 14.2.35.

This follows the October 14 out-of-band update, which fixed two critical remote code execution bugs and a high-severity denial of service in 16.4.1 and 15.5.28. If you skipped that one, this upgrade covers it too, and you have more reason to hurry.

The "Affected" column copies the advisory metadata, and it's messy. Several ranges stop at 16.4.2, the advisories' "patched versions" fields are empty (one says 16.4.2), and the 16.4.5 release notes list all seven as fixed in that release. I compared the npm tarballs of 16.4.4 and 16.4.5: the code that strips x-middleware-set-cookie is only in 16.4.5, and the image content-type detection and use cache wrapper files also changed in that release. So treat anything below 16.4.5 or 15.5.29 as affected, including 16.4.3 and 16.4.4.

All seven are scored between 6.0 and 6.9 on CVSS v4. The Next.js blog post labels the unstable_cache() issue (GHSA-mfr8) "High Severity", while the advisory itself says moderate. If you use root params to separate tenants, I'd treat it as high anyway, because the leaked data is another tenant's.

Am I affected? Check your features

Upgrade either way. The features below tell you what to review once you've upgraded.

1. Do you use `use cache` or Cache Components? This is a 16.x feature, and four advisories target it. Look for binary arguments (GHSA-rhh4), nested cached functions that read root params from next/root-params (GHSA-vc7v), and any use cache function also wrapped in unstable_cache() (GHSA-mfr8). Multi-tenant and multi-locale apps that key data by root params have the most to lose.
2. Do you self-host with `next start`? If you also have cacheComponents: true without partialPrefetching, the shell poisoning issue (GHSA-vvgp) may apply. Its preconditions are narrow (a generateStaticParams param plus at least two deeper params that are never prerendered, and a blocking fallback shell), but one unauthenticated request is enough.
3. Do any Edge runtime routes set cookies? The cookie leak (GHSA-f3mh) needs a sensitive cookie set with NextResponse on an Edge route, plus attacker JavaScript already running on your origin. The blog post says the reproduced leak did not affect Node.js route handlers or cookies().set(). It makes an XSS bug worse rather than creating one.
4. Do you self-host image optimization? GHSA-7qx7 lets an image from an allowed source reach the SVG decoder you had switched off. Your image source allowlist still applies, and the blog post says the finding doesn't by itself show XSS or remote code execution. Still, the October critical bug was in SVG handling in the same optimizer.
5. Do you proxy upstream responses? GHSA-pc58 needs a self-hosted route handler (or the fetch cache) that returns an attacker-controlled fetch() response unchanged, behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared backend connection.

Is a Vercel-hosted app protected? Neither the blog post nor the advisories say so. Three of them (GHSA-7qx7, GHSA-pc58 and GHSA-vvgp) are written for self-hosted apps only. The four cache and cookie issues come from how your application code behaves, so I would not assume the platform handles them.

How to upgrade to Next.js 16.4.5 or 15.5.29

First see what you actually have installed. The version range in package.json isn't enough, because the lockfile decides:

npm ls next          # every copy in the tree, including monorepo workspaces
npx next --version   # prints e.g. "Next.js v16.4.5"
pnpm why next        # pnpm projects

Then install the patched version for your line. Installing with an exact version also updates the lockfile:

# 16.x (Active LTS)
npm install next@16.4.5
pnpm add next@16.4.5
yarn add next@16.4.5

# 15.x (Maintenance LTS)
npm install next@15.5.29
pnpm add next@15.5.29
yarn add next@15.5.29

If eslint-config-next or @next/* packages are pinned to the old version, bump them in the same commit so versions stay matched. Commit the lockfile, run your build and tests, and deploy. On 14.x or older there's nothing to install for this release. GHSA-pc58 covers every version below 16.0.0, and the October fixes never reached 14.x either, so plan the move to 15.5.29 or 16.4.5.

Workarounds if you can't upgrade today

Only two advisories give a workaround, and Vercel still says to upgrade:

• GHSA-vvgp (shell poisoning): set partialPrefetching: true in next.config.
• GHSA-mfr8 (`unstable_cache()` race): don't call a use cache function through unstable_cache(). Outside the race, Next.js already throws 'use cache' inside unstable_cache() is unsupported, and the advisory calls avoiding it a complete workaround.

The other five have no stated workaround. For the October image bug, the stopgap was making sure Next.js uses sharp 0.35.5 or later, and the script below checks that too.

A version check script for local and CI

I wanted a check that doesn't depend on the audit database, so I wrote a small Node script with no dependencies. It reads the installed next version (falling back to package-lock.json when there's no node_modules), compares it with 16.4.5 or 15.5.29, flags 14.x and older, and checks sharp. It exits with 1 when something needs upgrading.

#!/usr/bin/env node
// check-next-version.mjs: is the installed Next.js patched for the 3 Nov 2026 security release?
// Usage: node check-next-version.mjs [projectDir]   (exit code 1 = upgrade needed)
import { createRequire } from "node:module";
import { readFileSync, existsSync } from "node:fs";
import { join, resolve } from "node:path";

const dir = resolve(process.argv[2] ?? ".");
const FIXED = { 16: "16.4.5", 15: "15.5.29" }; // November 2026 security release
const SHARP_MIN = "0.35.5"; // October 2026 workaround for GHSA-2464-fhr4-w9xw

function installedVersion(pkg) {
  try {
    const req = createRequire(join(dir, "package.json"));
    return JSON.parse(readFileSync(req.resolve(`${pkg}/package.json`), "utf8")).version;
  } catch {
    const lock = join(dir, "package-lock.json"); // fallback: npm lockfile without node_modules
    if (!existsSync(lock)) return null;
    return JSON.parse(readFileSync(lock, "utf8")).packages?.[`node_modules/${pkg}`]?.version ?? null;
  }
}

function parse(v) {
  const m = /^(\d+)\.(\d+)\.(\d+)(-.+)?$/.exec(v);
  if (!m) throw new Error(`cannot parse version "${v}"`);
  return { nums: m.slice(1, 4).map(Number), pre: m[4] ?? "" };
}
function lessThan(a, b) {
  const x = parse(a).nums, y = parse(b).nums;
  for (let i = 0; i < 3; i++) if (x[i] !== y[i]) return x[i] < y[i];
  return false;
}

const next = installedVersion("next");
if (!next) {
  console.error(`No installed "next" found in ${dir}. Run npm install (or check the path).`);
  process.exit(2);
}
const { nums, pre } = parse(next);
const major = nums[0];
let ok = true;

if (pre) {
  console.log(`next ${next} is a prerelease. This script only checks stable lines; move to ${FIXED[16]} or check the canary changelog.`);
  ok = false;
} else if (FIXED[major]) {
  if (lessThan(next, FIXED[major])) {
    console.log(`next ${next}: NOT patched. Upgrade to ${FIXED[major]} or later on the ${major}.x line.`);
    ok = false;
  } else {
    console.log(`next ${next}: patched for the November 2026 release (needs >= ${FIXED[major]}).`);
  }
} else if (major < 15) {
  console.log(`next ${next}: no patched ${major}.x release exists. Plan a move to ${FIXED[15]} or ${FIXED[16]}.`);
  ok = false;
} else {
  console.log(`next ${next}: newer major than this script knows about. Check the current advisories.`);
}

const sharp = installedVersion("sharp");
if (sharp && lessThan(sharp, SHARP_MIN)) {
  console.log(`sharp ${sharp}: below ${SHARP_MIN} (October 2026 image optimizer advisory). Upgrading next pulls a fixed sharp.`);
  ok = false;
} else if (sharp) {
  console.log(`sharp ${sharp}: OK (>= ${SHARP_MIN}).`);
}
process.exit(ok ? 0 : 1);

Here is what it printed on my test box, before and after the upgrade:

$ npm install next@16.4.4 && node check-next-version.mjs
next 16.4.4: NOT patched. Upgrade to 16.4.5 or later on the 16.x line.
sharp 0.35.5: OK (>= 0.35.5).

$ npm install next@16.4.5 && node check-next-version.mjs
next 16.4.5: patched for the November 2026 release (needs >= 16.4.5).
sharp 0.35.5: OK (>= 0.35.5).

I also ran it against fake projects for 15.3.5, 15.5.28, 15.5.29, 16.3.6, 16.5.0, 14.2.35, a canary, an old sharp and a lockfile-only checkout, and all 12 cases gave the expected exit code. To make it a gate, add one step after npm ci in your workflow. I explain the rest of my pipeline in GitHub Actions CI/CD for a solo SaaS.

      - run: npm ci
      - name: Next.js security floor
        run: node scripts/check-next-version.mjs

When the next release comes out, update the two numbers in FIXED. Next.js now ships scheduled security releases about once a month, so expect to repeat this.

My checklist for client apps

• Run npm ls next in every app and workspace, not just the main one.
• Upgrade to 16.4.5 or 15.5.29 and commit the lockfile.
• Search the code for use cache, unstable_cache, next/root-params, runtime = 'edge' and dangerouslyAllowSVG.
• If you self-host, check cacheComponents and partialPrefetching in next.config, and check whether your proxy pipelines HTTP/1.1 requests to the app.
• Clear cache stores after deploying if you use Cache Components.
• Plan the move off 14.x or older for anything still running it.
• Add the version check to CI so a stale lockfile can't slip back in.

My own site runs on Next.js (I wrote about how the portfolio is built), so I'm upgrading it the same way. If you look after Python services too, the FastMCP Prefab UI CVE was another recent case where the usual audit tool missed a real advisory.