Next.js shipped two 9.5s out of band. The one most applications are actually exposed to is the 8.2

Next.js published three security advisories out of band on 14 October: two rated 9.5 critical, both unauthenticated remote code execution, and one rated 8.2 high, a denial of service. Fixed in 16.4.1 and 15.5.28.

Every write-up led with the two nines. That is the correct order by severity and, for most applications running the framework, the wrong order entirely. The conditions are what decide, and the advisories state them plainly.

The first 9.5 needs a feature most applications do not use

GHSA-673q-mjm6-r5xr affects 16.0.0 through 16.4.0 and is fixed in 16.4.1. It has no CVE. The condition is one sentence: "The application needs to have a use cache function that returns multiple typed arrays."

That means App Router with Cache Components, and a cached function handing back more than one typed array. If your application does not use use cache, this advisory does not describe a path into it. There is no workaround for applications that do — Vercel says to upgrade, and recommends upgrading anyway even if you have no such functions.

The second 9.5 needs SVG, and a particular Linux

CVE-2026-96889, advisory GHSA-2464-fhr4-w9xw, affects 10.0.0 through 15.5.27 and 16.0.0 through 16.4.0, fixed in 15.5.28 and 16.4.1. It is in the Image Optimization API, and the advisory's own title limits it: the flaw is reachable "when SVG files are used". The description narrows it again — the risk applies "when Next.js runs on glibc-based Linux". The bug is in an upstream library reached through sharp. Credited to randomguy6407 and rafabd1.

By default Next.js does not optimise SVG at all. Reaching this needs the SVG allowance turned on, or the OG image generator running on the Node.js runtime.

This one carries the trap in the batch. The stated workaround is to make sure the sharp version in use is at least 0.35.5. Upgrading Next.js normally pulls a fixed sharp along with it, but a lockfile can hold an older one in place, so on the 15 line the sensible move is to check what actually resolved — npm ls next sharp will tell you — rather than assume the framework bump carried the dependency with it.

We looked at a different image-handling flaw in this framework in September, an AVIF heap overflow that only mattered on Windows. The pattern is the same: the headline is the framework, the bug is in what the framework calls.

The 8.2 needs almost nothing

GHSA-p3m5-59mp-jv5r is rated high, not critical, and has no CVE. It affects 13.0.0 through 15.5.27 and 16.0.0 through 16.4.0, fixed in the same two releases.

Its condition: "Crafted requests targeting Next.js applications using App Router with at least one Server Action" can drive CPU use high enough to block every other request in that process. No privileges, no user interaction, no workaround. Pages Router applications and applications with no Server Actions are not affected.

App Router with at least one Server Action is not a niche configuration. It is the default shape of a modern Next.js application, and a single form handler anywhere in the codebase satisfies it. Measured by how many deployed applications meet the condition, the 8.2 reaches far more of them than either 9.5.

Why the ranking inverts

CVSS scores what happens if a flaw is exploited. It does not score whether your deployment can be. A 9.5 that needs Cache Components and a 9.5 that needs SVG optimisation on glibc are both worse than an 8.2 if you meet the condition, and neither is anything if you do not.

The practical reading of this release is therefore the opposite of the headline. Upgrade for all three, but if you are triaging under time pressure, the question "do we use App Router and have we got a Server Action" is the one most likely to return yes.

We run this framework here, and the check was three questions and about ten minutes: is there a cached function returning typed arrays, is SVG optimisation or server-side OG rendering in the path, and is there a Server Action anywhere. Any team can answer those faster than they can read the advisories.

What to do

• Upgrade to 16.4.1 or 15.5.28. All three advisories are fixed in those releases and two of the three have no workaround at all.
• On the 15 line, verify the resolved sharp version is 0.35.5 or later after upgrading rather than assuming it moved.
• Answer the three condition questions for your own application before deciding how urgent this is. Two of them are a grep.
• If you cannot upgrade immediately, note which advisories you are actually exposed to and say so in the record. "Two critical RCEs" in a risk register with no conditions attached is worse than useless.

What is not established

• The root cause of the use-cache flaw. The advisory does not describe it.
• Which upstream library the SVG flaw sits in. The advisory says only that it is an upstream library used for Image Optimization; the naming comes from reporting rather than from Vercel.
• Whether either critical flaw has been exploited. No advisory claims it and no telemetry has been published.
• Why neither 9.5 received a CVE while the SVG one did. The advisories record "No known CVE" for two of the three.
• How many deployed applications meet each condition. Nobody publishes that, which is exactly why the conditions have to be checked locally.