Next.js vulnerabilities from React2Shell to 2026: what happened and which version fixes what

If you run Next.js, the safe versions as of 25 October 2026 are 15.5.28 on the 15.5 line and 16.4.1 or later on the 16 line. Those releases include the fixes for every critical Next.js advisory published this year, including two unauthenticated remote code execution flaws in the image optimisation API. Anything older than 15.5.7 or 16.0.7 is also still exposed to React2Shell, the December 2025 flaw rated CVSS 10.0.

This article puts those advisories in order: what each one was, when it was disclosed, what it did in the real world, why it happened, and what to install. It is written for teams that self-host Next.js on their own servers or containers, because that is where the responsibility for patching sits.

React2Shell: the vulnerability that set the tone

React2Shell is CVE-2025-55182, an unauthenticated remote code execution flaw in React Server Components, disclosed on 3 December 2025 with a CVSS score of 10.0. Because Next.js uses React Server Components in its App Router, Next.js applications were affected too; Next.js initially tracked its side under CVE-2025-66478.

Who was affected and how quickly attacks started

The affected packages were the react-server-dom family in React 19.0, 19.1 and 19.2, plus Next.js 15.x, 16.x and 14.3 canary releases using the App Router. Wiz reported that 39% of the cloud environments it monitors contained vulnerable Next.js or React versions. Exploitation began within roughly two days: Wiz observed China-nexus groups experimenting on 4 December, and GreyNoise identified 95 IP addresses making largely automated attempts by 04:00 UTC on 5 December. Datadog reported more than 800 IP addresses scanning for the flaw by the same day.

What attackers did next is the useful part for defenders. Wiz documented harvesting of credentials from environment variables and cloud metadata, attempts to install the Sliver post-exploitation framework, and at least six cryptomining campaigns using XMRig. In other words, the server was the entry point and the cloud account was the target.

The day the fix took websites offline

React2Shell also caused one of the most visible outages of 2025, without a single exploit being involved. On 5 December, Cloudflare rolled out a change to its web application firewall to detect React2Shell payloads, raising the body buffer it inspects from 128 KB to 1 MB. The change to its body-parsing logic broke its network from 08:47 UTC. For about 25 minutes, until 09:12 UTC, roughly 28% of the HTTP traffic Cloudflare serves failed, and websites around the world went dark. Cloudflare's CTO stated that it was not caused by any attack.

The lesson is uncomfortable but important. Emergency mitigations are changes too, and they carry their own risk. That is an argument for patching the application properly rather than relying indefinitely on a filter in front of it.

The fixed versions were React 19.0.1, 19.1.2 and 19.2.1, and Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 and 16.0.7.

The 2026 Next.js advisories, in order

Image optimisation: the AVIF and SVG remote code execution flaws

Next.js resizes images on the fly through its Image Optimization API, the /_next/image endpoint, using a library called sharp, which in turn uses native image decoders. Both critical image flaws live in those decoders, not in Next.js code. In August, a heap buffer overflow in libheif, the AVIF decoder, could be triggered by a crafted AVIF image. Researchers describe a malformed file whose two alpha planes have different bit depths, so the decoder writes about 16 KB past the end of a buffer. Next.js 15.5.24 and 16.3.3 responded by disabling AVIF optimisation until a fixed decoder propagated.

In October, a second memory-related flaw arrived through the SVG path in librsvg, affecting Next.js on glibc-based Linux. The advisory's workaround is to make sure the sharp used by Next.js is 0.35.5 or later; upgrading Next.js to 15.5.28 or 16.4.1 pulls in a fixed sharp automatically.

Exploiting either flaw needs an image the attacker controls to reach the optimiser: a local file they can upload, or a remote image from a host allowed in remotePatterns. Sites that never optimise user-supplied or third-party images have a smaller attack surface, but 'smaller' is not 'none', and remotePatterns lists tend to grow over time.

Server Actions, use cache and cache poisoning

The other October fixes target newer App Router features. CVE-2026-94482 lets an attacker exhaust a server through Server Actions, a feature many forms now use. GHSA-673q-mjm6-r5xr affects applications using Cache Components with a use cache function that returns multiple typed arrays; the advisory states there is no workaround and recommends upgrading even if you do not think you use the pattern. The earlier cache poisoning issue lets crafted requests poison statically generated or ISR pages in self-hosted deployments, so other visitors receive the attacker's version of a page.

Why Next.js keeps producing critical advisories

It is tempting to read a run of critical fixes as a sign the framework is careless. The pattern is more specific than that. Next.js has moved a lot of work onto the server: rendering, data fetching, caching, form handling and image processing. Every one of those features accepts input from the internet. React2Shell came from how the server deserialises data sent by the client. The image RCEs came from native C libraries parsing untrusted files. The caching issues came from deciding which response belongs to which request.

That is the trade-off of a full-stack framework: more server features mean more server attack surface. It does not make Next.js a bad choice. It does mean a Next.js site is a server application with a server application's patching duties, not a static website.

How to check which version you run

# In the project (what the lockfile resolves to)
npm ls next react react-dom sharp

# Inside a running container (what is actually deployed)
docker exec <container> node -e "console.log(require('next/package.json').version)"
docker exec <container> node -e "console.log(require('sharp/package.json').version)"

Check the deployed artifact, not just the repository. A repository bumped to 15.5.28 means nothing until the image is rebuilt and the container replaced. Also check sharp separately: with standalone builds it ships in the image, and the SVG workaround depends on its version.

How to patch safely

1. 1

   Stay on your line

   Upgrade 15.5.x to 15.5.28 and 16.x to 16.4.1 or later. Patch releases within a line are designed to be drop-in; a major upgrade is a separate project.

2. 2

   Update the lockfile

   Run npm install next@15.5.28 (or the 16.x version), then confirm React and sharp resolved to fixed versions with npm ls.

3. 3

   Build and smoke-test

   Run the production build, then load key pages, an optimised image, forms that use Server Actions, and any ISR pages.

4. 4

   Deploy with a rollback

   Keep the previous image tagged so a rollback is one command, and watch error rates and response times after the switch.

5. 5

   Review image sources

   Trim remotePatterns to hosts you control, and make sure uploaded files are not served to the optimiser without validation.

Pinning matters here as much as patching. A Dockerfile that builds from a floating tag and runs npm install without a lockfile can quietly change versions between builds. Pin the Node.js base image, install with npm ci, and the version you tested is the version you ship.

Hardening a self-hosted Next.js server

Upgrading closes the known holes. A few configuration choices limit the damage from the next one, and none of them require changing application code.

• If the site does not need on-the-fly image resizing, set images.unoptimized so the optimiser is not running at all.
• Keep remotePatterns to hosts you control. Every allowed host is a source of images that reach native decoders.
• Run the server as a non-root user with a read-only filesystem, leaving only the .next cache writable.
• Keep secrets out of the environment of the web process where you can, since React2Shell attackers went straight for environment variables and cloud metadata.
• Rate-limit /_next/image and Server Action endpoints at the reverse proxy, which blunts denial-of-service attempts.
• Block access to cloud instance metadata from the application container if your platform allows it.

Watch the right signals after a release

After any security upgrade, watch error rates, response times and memory use of the Next.js process, and look for new outbound connections from the web container. A compromised Next.js server usually reveals itself through unexpected outbound traffic or CPU use long before anyone reads a log line.

An earlier warning: the middleware bypass of March 2025

React2Shell was not the first serious Next.js issue to catch teams relying on the framework for security. In March 2025, CVE-2025-29927 showed that a crafted x-middleware-subrequest header could make Next.js skip middleware entirely, bypassing authorisation checks implemented there. It was fixed in 12.3.5, 13.5.9, 14.2.25 and 15.2.3. The durable lesson: enforce authorisation where the data is read, not only in a layer in front of it.