Next.js Critical RCE Fixes, October 2026: CVE-2026-96889, use cache, and Upgrading to 16.4.1

On 14 October 2026 Vercel released Next.js 16.4.1 and 15.5.28 outside the normal release schedule. They fix two critical flaws that let an attacker run code on the server without logging in, both scored 9.5 on CVSS 4.0, along with a denial of service in Server Actions. React published a related critical advisory for React Server Components the same day, and Singapore's Cyber Security Agency issued an alert on 20 October. No exploitation has been reported so far, but several repositories claiming proof-of-concept code for one of the flaws have appeared on GitHub. If you run Next.js on your own servers, this is an upgrade to do this week.

Three Advisories at a Glance

The denial of service advisory was later assigned CVE-2026-94482. The use cache flaw had no CVE number at the time of writing.

CVE-2026-96889: The Image Optimizer and sharp

The first flaw is not in Next.js code. It is a memory bug in a library bundled with sharp, the image processing package Next.js uses for its built-in Image Optimization API, the endpoint behind next/image that resizes images on request. According to Vercel, it can lead to remote code execution when Next.js runs on glibc-based Linux and SVG files are involved. Most Debian, Ubuntu, and RHEL based servers and container images use glibc. Alpine images use musl instead.

The fix is sharp 0.35.5 or later, and that detail matters. Next.js 16.4.1 requires sharp 0.35.5, but Next.js 15.5.28 still accepts sharp 0.34.x. An application on the 15 line that upgrades Next.js but keeps an existing lockfile can end up with the old sharp and the vulnerability intact. After upgrading, run npm ls sharp and confirm the version. If it is still 0.34, install sharp 0.35.5 or later explicitly, or add an override in package.json.

An application that does not use the built-in optimizer, for example one with images.unoptimized set to true, a static export, or a custom loader that sends images to a CDN such as Cloudinary or imgix, does not route requests through sharp in this way. It is still worth upgrading, but the urgency is lower.

The use cache Flaw: No Workaround

The second flaw affects applications on the App Router that use Cache Components, the Next.js 16 feature built around the use cache directive. An application is exposed when a use cache function returns multiple typed arrays, such as Uint8Array or Float32Array. Vercel says there is no workaround and asks everyone on 16.x to upgrade immediately, even if their code has no such functions. It is easy to miss one inside a shared library or a utility written months ago.

React published GHSA-xqc2-xf4c-x3h3 on the same day, a critical remote code execution issue in React Server Components that also involves responses carrying multiple typed arrays. It affects react-server-dom-webpack, react-server-dom-turbopack, and react-server-dom-parcel from 19.0.0 to 19.3.0, fixed in 19.0.9, 19.1.10, 19.2.9, and 19.3.1. Next.js ships its own copy of these packages, so upgrading Next.js covers it. Teams using React Server Components through another framework or bundler plugin need to update those packages directly.

Server Actions Denial of Service

The third advisory is less severe but touches more applications. A crafted request to an App Router application with at least one Server Action can drive CPU use high enough to block every other request handled by the same process. There is no workaround. Applications that use only the Pages Router, or that have no Server Actions, are not affected. Because Server Actions are the default way to handle forms in the App Router, many applications built in the last two years fall into the affected group.

Not the First Security Release Since September

October's fixes came on top of a busy September. On 22 September Next.js 16.3.6 fixed CVE-2026-94545, a critical remote code execution flaw in the Node.js ImageResponse from next/og when attacker-controlled values end up in SVG content. On 30 September a batch of advisories followed, including server-side request forgery in Image Optimization (CVE-2026-94483) and two cache poisoning issues affecting SSG and ISR pages on self-hosted deployments (CVE-2026-94543 and CVE-2026-94484). Teams that skipped those updates should not try to apply them one by one. Version 16.4.1 contains all of them.

How to Upgrade

1. 1Check the Next.js version in each project with npm ls next, and note whether it is on the 15 or 16 line.
2. 2Upgrade: npm install next@16.4.1 for the 16 line, or npm install next@15.5.28 for the 15 line. Applications on 14 or older have no patched release and should plan a move to 15 or 16.
3. 3Run npm ls sharp. If the version is below 0.35.5, install sharp@^0.35.5 or add it to overrides in package.json, then reinstall.
4. 4Run the build and the test suite, then check pages that use next/image, Server Actions, and use cache functions by hand on staging.
5. 5Rebuild the Docker image. With output set to standalone, make sure the new sharp is part of the final image, since the standalone folder carries its own node_modules.
6. 6Deploy and confirm inside the running container: check the next and sharp versions in node_modules, and run ldd --version to see whether the base image uses glibc.

Next.js runs on Node.js, and the Node.js security releases of 21 October fixed a Brotli decoder flaw that can also lead to remote code execution. If you are rebuilding images anyway, move the base image to Node.js 22.23.4, 24.22.1, or 26.12.1 in the same change.

After the Upgrade

Since there are no confirmed attacks, a full investigation is not needed for most teams. A quick review of logs is still sensible for internet-facing applications that ran a vulnerable version: look for unusual requests to the image optimizer endpoint under /_next/image with SVG sources, spikes in CPU on processes handling Server Actions, and any sign of the Node.js process starting shells or download tools. If you find something, treat the server as compromised and rotate the secrets in its environment variables, such as database credentials and API keys.

The bigger lesson is that a framework moving this fast needs an update routine. Projects that keep Next.js within a minor version or two of the latest release, with Dependabot or Renovate opening pull requests and a test suite to back them, can absorb a release like this in an hour. Projects that are several minors behind face a larger, riskier jump exactly when time is short. If you need help upgrading or reviewing a Next.js application, our team can take it on, and our Django REST and Next.js training covers these practices for in-house developers.