Next.js 16.4.1: two critical RCEs and who is exposed

Next.js 16.4.1 and 15.5.28 landed on 14 October 2026 with fixes for two Critical unauthenticated remote code execution issues and one High denial of service. Both RCEs score CVSS 9.5. The number that matters more is in the advisories rather than the release post: one of them lists affected versions from 10.0.0.

That single line changes the job. If you are on 16.x or 15.x this is a patch and a deploy. If you are on 12, 13 or 14 — and plenty of production apps are — there is no patched release waiting for you, and the only published mitigation is a transitive dependency bump.

What Next.js 16.4.1 and 15.5.28 actually fix

Vercel pre-announced the out-of-band release on 8 October, noting that two of the three fixes had been postponed from the September security release because of upstream coordination. The update shipped a week later as 16.4.1 for Active LTS and 15.5.28 for Maintenance LTS.

Advisory	Severity	Affected	Needs to be true
CVE-2026-96889 — Image Optimization API	Critical, 9.5	10.0.0–15.5.27, 16.x up to 16.4.0	Image Optimization API, SVG, glibc Linux
GHSA-673q-mjm6-r5xr — use cache	Critical, 9.5	16.0.0–16.4.0	App Router, Cache Components, use cache returning multiple typed arrays
GHSA-p3m5-59mp-jv5r — Server Actions DoS	High, 8.2	13.0.0–15.5.27, 16.0.0–16.4.0	App Router with at least one Server Action

Two of the three have no workaround. Neither Critical RCE has a CVE beyond the image one, which is worth knowing if your vulnerability management process only ingests CVE feeds — a scanner keyed to CVE IDs will see one of these three, not three.

Which Next.js versions are vulnerable

The ranges are not the same across the three advisories, and the differences are the whole triage. The use cache RCE is 16-only. The Server Actions DoS starts at 13.0.0. The image RCE starts at 10.0.0 — a version released in October 2020.

There is also a small inconsistency worth checking if you are pinned exactly: the image advisory writes its 16.x range as greater than 16.0.0, while the other two write it as 16.0.0 and above. If you are running precisely 16.0.0, treat yourself as affected and move on; the distinction is not worth an afternoon.

The image RCE reaches back to version 10, and most of that range gets no patch

Next.js publishes a support policy with two supported phases. A major stays in Active LTS until the next major ships, then moves to Maintenance LTS for "two years following the initial release", receiving "only critical bug fixes and essential security updates". The policy lists 16.x (released 21 October 2025) as Active LTS and 15.x (released 21 October 2024) as Maintenance LTS. Everything from 14.x down is listed as unsupported.

So the image advisory marks versions 10 through 14 as affected, and the support policy says no release is coming for them. The policy does leave a door open — "in rare circumstances, depending on the severity of the underlying bug, we will patch versions of Next.js that are outside of our LTS policy" — but a Critical with a published advisory and no 14.x release three days later is not a promise you can plan around.

For those versions the mitigation is the dependency, not the framework. The advisory states the root cause is a memory bug in the upstream image library and that ensuring sharp is at least 0.35.5 is the workaround. On an unsupported Next.js major you can take that bump without touching your framework version:

npm ls sharp
npm install sharp@^0.35.5

This is the same class of problem as the HEIC upload vulnerability in libheif: the framework is the thing you patch, but the memory-unsafe decoder several layers down is the thing that is actually wrong.

SVG optimisation is off by default, which narrows this considerably

The advisory title says the issue arises "when SVG files are used". Next.js documentation is explicit that "by default, Next.js does not optimize SVG images", and that serving them through the optimiser requires setting dangerouslyAllowSVG: true in next.config.js. The flag is named the way it is for a reason.

If that flag has never appeared in your config, the vulnerable path should not be reachable through next/image. Vercel has not said this explicitly, so we are reasoning from the documented default rather than quoting a scope statement — which means it is a reason to prioritise, not a reason to skip the patch. Grep for it before you decide how fast to move:

grep -rn "dangerouslyAllowSVG" next.config.*

The use cache RCE needs three things to be true at once

This is the advisory most likely to be over-read. It requires the App Router, Cache Components enabled, and a use cache function that returns multiple typed arrays. The upstream React advisory is narrower still, describing the flaw as arising "only in rare cases where responses carry multiple typed arrays alongside an attacker-controlled value".

Narrow conditions, and Vercel still says to "upgrade immediately even if your application does not have similar functions". Take that at face value. Serialisation bugs are reachable through code paths nobody has enumerated, and a condition that looks rare in your own handlers is not a condition you have ruled out across your dependencies.

The React side matters if you pin React directly. The patched packages are react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack at 19.0.9, 19.1.10, 19.2.9 and 19.3.1. Upgrading Next.js pulls a fixed version in; a lockfile that pins React independently may not.

Patching 15.x to 15.5.28 buys you about six days

Here is the consequence nobody patching this week seems to be costing. 15.x was released on 21 October 2024, and the policy commits to two years of Maintenance LTS. The policy page does not print an end date, so this is arithmetic on Vercel's own stated rule rather than a published deadline — but it puts 15.x out of Maintenance LTS around 21 October 2026.

That is a week after 15.5.28 shipped. If you are on the 15 line, 15.5.28 is plausibly one of the last security releases it receives, and the next Critical will find you on an unsupported major. The patch is still the right move today. The migration to 16 is the decision this advisory should actually trigger, and it is a planning conversation, not a hotfix — the same reasoning we applied to self-hosted exposure in 16.3.8.

A ten-minute triage

1. Get your real version. npm ls next, not what package.json asks for. A caret range and a stale lockfile disagree more often than teams expect.
2. Router and features. App Router with any Server Action means the DoS applies. Cache Components with use cache means the first RCE applies. Pages Router with neither means only the image issue is in scope.
3. Check the SVG flag. dangerouslyAllowSVG present and true moves the image RCE to the top of your list.
4. Check sharp independently. npm ls sharp. On 16.x and 15.x the framework upgrade handles it; below that, bump it yourself.
5. Patch. npm install next@16.4.1 or npm install next@15.5.28, then confirm the lockfile actually moved.

If step one takes you more than a few minutes across your estate, that is the finding — not the advisory. Teams that can answer "which Next.js version is in production, right now, per service" inside ten minutes patch this in an afternoon. Teams that cannot spend the afternoon building an inventory instead, and do it again at the next Critical. Deciding what deserves that automation, and what is better left to a human reading the advisory, is the alert triage question we have written about before.

Our last Next.js advisory walkthrough covered who was exposed to the 16.3.6 next/og RCE, and the pattern is holding: three advisories in three releases, the exposure gated behind features rather than versions, and the honest answer usually narrower than the headline. If you want help working out which of your services are actually in scope, or planning the 15-to-16 move before the support window closes, that is the kind of web application work we do.