← All posts
October 19, 2026 · Sécurité

Critical Next.js Vulnerabilities, October 2026: Are You Affected and How to Fix Them

On October 14, 2026, Vercel shipped an out-of-band fix for two critical unauthenticated remote code execution flaws and a denial-of-service bug in Next.js. Here is how to tell whether your app is exposed and how to patch it properly.

What happened

On October 14, 2026, the Next.js team released an out-of-band security update: Next.js 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS). It fixes three vulnerabilities, two of them critical, allowing unauthenticated remote code execution (RCE).

Two of these fixes had been held back from the September release while waiting for upstream patches (React and sharp). No active exploitation was reported at publication time, but an unauthenticated RCE in such a widely used framework is the kind of bug that gets exploited fast.

| Identifier | Severity | What is affected | |---|---|---| | GHSA-673q-mjm6-r5xr (+ React GHSA-xqc2-xf4c-x3h3) | Critical | App Router with Cache Components, a use cache function returning multiple typed arrays | | CVE-2026-96889 / GHSA-2464-fhr4-w9xw | Critical | Image Optimization API with SVG, Next.js on glibc-based Linux (via sharp) | | GHSA-p3m5-59mp-jv5r (+ React GHSA-h3gv-c5rc-p453) | High | App Router with at least one Server Action: CPU-exhaustion denial of service |

1. Understanding the three flaws

RCE in use cache functions

An app using the App Router with Cache Components can be compromised without authentication when a use cache function returns multiple typed arrays (Uint8Array, Float32Array…). The issue lies in React's serialization.

Key point: there is no workaround. Vercel recommends upgrading even if you think you have no such function.

RCE in Image Optimization (SVG)

The Image Optimization API (/_next/image) relies on the sharp library. A memory bug in the upstream decoder allows code execution when Next.js runs on glibc-based Linux (Debian, Ubuntu, most non-Alpine node:* Docker images). Workaround: force sharp 0.35.5 or later.

Denial of service via Server Actions

Crafted requests to an App Router app with at least one Server Action spike CPU usage and block every other request in the same process. Apps using the Pages Router or no Server Actions are not affected.

2. Am I affected? A 3-minute check

# 1. Which Next.js version is actually installed?
npm ls next

# 2. Which sharp version is resolved (and by whom)?
npm ls sharp

# 3. Do you use use cache, Server Actions, image optimization?
grep -rn "use cache" src app --include=*.ts --include=*.tsx
grep -rn "use server" src app --include=*.ts --include=*.tsx
grep -rn "next/image" src app --include=*.tsx

Then ask yourself:

  • Version: are you below 15.5.28 (15.x line) or 16.4.1 (16.x line)? If so, you are in the risk zone.
  • Hosting: does your app run with a Next.js server (next start, Docker, Node on a VPS)? That is the exposed mode.
  • Static export: with output: "export", the site is generated as HTML/CSS/JS and served by a plain web server. There is no image API, no Server Actions and no server-side cache in production: these three flaws cannot be exploited remotely. Still upgrade for your development environment and future changes.

3. Patching properly

Step 1: upgrade Next.js

# 15.x line
npm install next@15.5.28

# 16.x line
npm install next@16.4.1

Step 2: check sharp (the lockfile trap)

On the 15.x line, next@15.5.28 still accepts a sharp range that includes 0.34. If your package-lock.json had already resolved a 0.34.x, simply upgrading Next.js can keep the old, vulnerable sharp.

# Check the version actually resolved
npm ls sharp

# If sharp is below 0.35.5: force the upgrade
npm install sharp@^0.35.5

You can also pin the minimum version for every transitive dependency:

{
  "overrides": {
    "sharp": "^0.35.5"
  }
}

Step 3: rebuild and redeploy

rm -rf .next
npm ci
npm run build

For Docker, rebuild the image without cache (docker build --no-cache) so the new dependencies are really included, then redeploy.

Step 4: verify in production

# Inside the container or on the server
node -e "console.log(require('next/package.json').version)"
node -e "console.log(require('sharp/package.json').version)"

4. Shrinking the attack surface beyond the patch

  • Disable what you don't use: if you don't need on-the-fly image optimization, images: { unoptimized: true } removes the /_next/image endpoint.
  • Restrict SVGs: don't allow optimizing SVGs from external sources (dangerouslyAllowSVG must stay false), and limit images.remotePatterns to domains you control.
  • Prefer Alpine (musl) or distroless images for your containers: the sharp flaw targets glibc environments.
  • Put a WAF / reverse proxy in front of the app with rate limiting on Server Action routes to absorb denial-of-service attempts.
  • Automate monitoring: enable Dependabot or Renovate and subscribe to the security advisories of the vercel/next.js GitHub repository.

Checklist

  • [ ] npm ls next shows 15.5.28+ or 16.4.1+
  • [ ] npm ls sharp shows 0.35.5+ across the whole tree
  • [ ] Build and Docker image rebuilt without cache
  • [ ] Versions checked in production, not just locally
  • [ ] Image optimization and remote SVGs limited to what is strictly needed
  • [ ] GitHub security alerts / Dependabot enabled

Official source: Next.js Security Update — October 14, 2026