CVE-2025-55182 (React2Shell): RSC deserialisation RCE

02Affected versions and the follow-ups

The vulnerable code is in the React server packages, but most teams consume them through Next.js, so the Next.js version is usually what decides exposure. As with Log4Shell, researchers probing the first patch found more issues, so a cluster of follow-up CVEs landed over the following weeks — several denial-of-service bugs and one source-code-exposure bug — and in October 2026 a second remote-code-execution advisory. Keep moving to the latest patch in your line rather than stopping at the first fix.

03How an attack works, conceptually

React Server Functions expose endpoints that accept a serialised payload describing the call. The Flight decoder reconstructed objects from that payload without sufficiently validating them, so a crafted body could steer the server into executing code rather than simply handling data. No valid Server Function call, authentication or specific route was required beyond reaching an endpoint that the framework exposes.

Observed exploitation matched the theory. Within hours of disclosure, Amazon's threat-intelligence teams reported exploitation attempts by multiple China state-nexus groups. One cluster spent nearly an hour refining its attempts against a live target — running reconnaissance commands such as whoami and id, trying to write a marker file to /tmp and to read /etc/passwd. The common thread was speed: public details were minimal, but the vulnerability class was understood quickly enough to exploit the same day.

04How to check your installed versions

Check the resolved versions, not the ranges in package.json, because a caret range can resolve to a vulnerable build. For Next.js apps the critical detail is that Next.js vendors its own copy of the React server packages inside the framework, so the installed Next.js version — not a separately installed react-server-dom-* — is what matters. Upgrading Next.js is how you get the fixed RSC code.

• Next.js App Router with React Server Components is the main exposure; Next.js 13.x, stable 14.x, Pages Router applications and the Edge Runtime are not affected by the RCE
• Upgrade Next.js to the latest patch in your line rather than bumping React directly; 15.5.7 and 16.0.7 were only the first fixed releases
• React Router, Waku, Parcel RSC, the Vite RSC plugin and Redwood SDK also bundle the affected packages — update those too
• After patching and redeploying, rotate application secrets, since an unpatched window may have exposed them

# What is actually installed
npm ls next react react-dom react-server-dom-webpack 2>/dev/null
node -p "require('next/package.json').version"

# Read every copy straight from the lockfile (lockfileVersion 2 or 3)
node -e 'const l=require("./package-lock.json");
  for (const [k,v] of Object.entries(l.packages||{}))
    if (/node_modules\/(next|react-server-dom-[a-z]+)$/.test(k))
      console.log(k, v.version)'

# yarn / pnpm equivalents
yarn why next    # or: pnpm why next

05How to fix it

Upgrade to a patched release and redeploy. For React consumers the first fixes were 19.0.1, 19.1.2 and 19.2.1; as of October 2026 the minimum covering every advisory in the table is 19.0.9, 19.1.10, 19.2.9 or 19.3.1. For Next.js, the first fixed releases were 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 and 16.0.7, but later advisories need newer builds — Next.js 16.4.1, for example, fixed a related October 2026 typed-array RCE in 'use cache' functions — so install the newest patch of your line. Vercel also published an interactive helper, fix-react2shell-next, that checks versions and performs the bump. There is no safe workaround that leaves the vulnerable code running.

# A partial version is a range: npm installs the highest matching release.
npm install [email protected]     # newest 15.5.x
npm install next@16       # newest 16.x

# Or run Vercel's guided checker/updater (published for this CVE)
npx fix-react2shell-next

# Then redeploy and rotate secrets.

06What virtual patching at the edge can and cannot do

React worked with several hosting providers to deploy temporary mitigations before disclosure, and CDN and cloud operators such as AWS shipped managed WAF rules. A WAF in front of Server Function endpoints can drop obviously malformed deserialisation payloads and rate-limit probing, and a proxy such as GuardX can absorb the burst of scanning that follows a disclosure of this magnitude.

But the vendors were explicit: do not depend on these mitigations, upgrade immediately. Virtual patching is pattern-matching against a serialisation format that is designed to be flexible, and AWS observed attackers actively debugging and refining their payloads against live targets. Edge filtering narrows the window and slows mass exploitation; it does not make an unpatched server safe. Treat it as cover during the upgrade, exactly as with Log4Shell.

07Disclosure and exploitation timeline

The speed is the headline: a critical deserialisation bug in a widely used framework was exploited the same day it was disclosed. If you run an RSC app, keep protection always on and your dependency inventory current, because the gap between disclosure and mass exploitation is now measured in hours, not weeks.