Two Critical Next.js RCE Flaws and How to Patch Your App

On 14 October Vercel published three security advisories for Next.js. Two are rated critical for remote code execution, and one is rated high for denial of service. All three are fixed in Next.js 16.4.1, and two of them also in 15.5.28. The current release on the 16 line is 16.4.2, which carries the same fixes.

What catches teams out is how quiet it has been. Two days after publication, none of the three is in the GitHub Advisory Database. That database is what npm audit, Dependabot and the OSV-based scanners read, so a project running a vulnerable version can get a clean report from all of them today.

The Three Advisories at a Glance

Severity is Vercel's CVSS 4.0 score. None of the three needs a login, and each is reachable by anyone who can send a request to the application, as long as its condition holds.

Image Optimization and the SVG Library Underneath

The bug behind the first advisory sits in a library Next.js uses to optimize images. Vercel describes it as a memory bug that can lead to remote code execution when Next.js runs on glibc-based Linux.

The CVE attached to it tells you which library. CVE-2026-96889 was published by Red Hat on 23 September and describes a use-after-free in librsvg, the SVG renderer, triggered by an SVG document whose nested XML inclusions declare the same entity twice. Next.js reaches librsvg through sharp, which bundles libvips, which uses librsvg for SVG input.

It affects every release from 10.0.0 to 15.5.27 and the 16 line up to 16.4.0. That chain also explains the workaround Vercel gives. Make sure the sharp your Next.js uses is 0.35.5 or later. sharp 0.35.5 came out on 27 September, and the libvips build it bundles carries librsvg 2.63.2, up from 2.62.91 in the build before it.

A fresh install picks up a fixed sharp by itself, and the patched Next.js releases make sure package managers do. The case to watch is the one that looks safest, an older lockfile installed with npm ci, which keeps whatever sharp it recorded. Check it directly.

npm ls sharp

Debian and Ubuntu based images such as node:22-slim use glibc. Alpine images use musl. Going by the advisory's wording, an Alpine based container is outside the code execution path. Upgrade anyway, since the same release fixes the other two.

use cache Functions That Return Typed Arrays

The second critical advisory is about the App Router with Cache Components. An application is vulnerable when it has a use cache function that returns multiple typed arrays, values such as Uint8Array or Float32Array, and the advisory says this can lead to remote code execution.

The affected range starts at 16.0.0, so the 15 line is not part of this one. Few applications will have such a function, and Vercel still asks everyone on an affected version to upgrade immediately, because there is no workaround.

Finding out takes one search.

grep -rn --include='*.ts' --include='*.tsx' --include='*.js' "use cache" app src lib 2>/dev/null

Then look at what each match returns. How these cache layers fit together is covered in our piece on Next.js caching layers.

Server Actions Can Be Made to Burn CPU

The third advisory is rated high, one step below the other two, and it is the one most applications are actually exposed to. Crafted requests aimed at an App Router application with at least one Server Action can push CPU usage high enough that the process stops handling anything else.

Server Actions are everywhere in App Router code. Any form that posts to an action function counts, and so does any file that starts with 'use server'. The Pages Router is not affected, and neither is an App Router application without Server Actions.

This search lists the files that define them.

grep -rln --include='*.ts' --include='*.tsx' "use server" app src 2>/dev/null

This range starts at 13.0.0, further back than the other two. The advisory lists two fixed releases, 15.5.28 and 16.4.1, and none on the 13 or 14 lines, so an application still on either of those has to move to 15.5.28 or later. Vercel states that no workaround exists besides upgrading.

Why npm audit Says You Are Clean

GitHub keeps two kinds of advisory. A repository advisory is published by a project's maintainers on their own repository, and these three were published on vercel/next.js. The GitHub Advisory Database is the global list, and a repository advisory reaches it only after GitHub's own team reviews it.

npm audit gets its data from the npm registry, which serves the reviewed global database. Dependabot alerts are raised from reviewed advisories as well, and OSV.dev imports the same set. Until that review happens, the usual tools have nothing to report. On 16 October the global database and OSV.dev both returned not found for all three IDs, and npm audit on a lockfile pinned to Next.js 16.3.8 listed no Next.js advisory at all.

The repository advisories can be read directly, without waiting for the review.

gh api "repos/vercel/next.js/security-advisories?per_page=10&sort=published&direction=desc" \
  --jq '.[] | [.ghsa_id, .severity, .published_at[0:10], .summary] | @tsv'

This gap is why our own nightly vulnerability scan reads the repository advisories of every production dependency next to the usual lockfile scanners, and reports the ones GitHub has not reviewed yet. These three showed up there while osv-scanner and npm audit on the same lockfile stayed quiet.

Checking and Fixing Your App

The fix is the upgrade, and on the 16 line it is one command.

npm install next@16.4.2 eslint-config-next@16.4.2

On the 15 line, install next@15.5.28. Then confirm what actually resolved, because a caret range in package.json says nothing about what the lockfile holds.

npm ls next sharp

Rebuild the image without cached layers and ship it through your normal deploy. A minor Next.js release can change behaviour, so it deserves the same path to production as any other change, and editing the version on a running server skips that. If something does break after the deploy, the way back is in rolling back a Next.js deploy without downtime.

Here is a short list for the next hour.

• Read the Next.js version each app runs from the lockfile or npm ls next, never from package.json.
• Search for use server and use cache to see which advisories apply.
• Run npm ls sharp on anything that optimizes images.
• Upgrade to 16.4.1 or later, or to 15.5.28 on the 15 line.
• Add your framework's repository advisories to whatever you monitor, so the next one does not wait for a review.

If you run several Next.js applications and want them patched and kept that way, that is part of our security and compliance work, and Kubernetes for Next.js covers the build and rollout side.

Sources: GHSA-2464-fhr4-w9xw, GHSA-673q-mjm6-r5xr, GHSA-p3m5-59mp-jv5r, CVE-2026-96889 on CVE.org, sharp-libvips v1.3.4 release notes