CVE-2025-55182 (React2Shell): which versions are affected and how to fix it

What CVE-2025-55182 is, in plain words

React Server Components (RSC) run part of a React app on the server. When a page calls a Server Function (a Server Action, in Next.js), the browser sends a request in React's Flight format, and the server turns it back into values: that step is called deserialization. In the affected versions, the server unsafely deserializes the request, and a crafted one can make it run code chosen by whoever sent it.

No account, session or click is needed. The bug sits in three React packages, react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack, at versions 19.0.0, 19.1.0, 19.1.1 and 19.2.0, and in every framework that ships them, starting with the Next.js App Router. Security teams call it React2Shell.

You do not need to have written a Server Action. The React team says an app can be vulnerable as soon as it supports React Server Components, and Microsoft notes that default configurations are vulnerable with no developer error involved.

What a stranger can do with it

Code that runs on your server has your server's access. Here is what that reaches, with what Microsoft saw attackers do after breaking in:

• Environment variables: in a typical AI-built app, DATABASE_URL, a Supabase service role key, STRIPE_SECRET_KEY, OPENAI_API_KEY and session secrets. Microsoft saw attackers hunt for AI and cloud credentials.
• Your database, through those credentials. A service role key skips row level security entirely.
• Your cloud account, with identity tokens pulled from the machine's metadata endpoint.
• The machine itself, on a server you run: crypto miners, remote access tools, new user accounts, changed SSH settings.

Severity and exploitation status

The CVSS 3.1 base score is 10.0, critical, with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: over the network, low complexity, no privileges, no user interaction. The score comes from Meta, the CVE numbering authority (CNA). NVD shows the same score and has not published its own. The weakness is CWE-502, deserialization of untrusted data.

CISA rates the flaw as automatable, with total technical impact. An app that sat online unpatched in December 2025 should be treated as possibly compromised, even if nothing looks wrong.

Who is affected

For AI-built apps the split is usually clear. A React single-page app on a hosted backend such as Supabase runs React in the browser only, so this CVE does not apply to its frontend. A Next.js App Router app is in scope. Published v0 apps were: Vercel rolled out patches to existing v0 chats and asks owners to patch right away with the Fix with v0 button. Unpublished v0 apps are not affected.

Hosted on Vercel or self-hosted

The code is the same everywhere, so your version decides. Vercel deployed WAF rules (a web application firewall filters requests before they reach your app) for all its users before the disclosure, added more on December 5, and blocks new deployments of vulnerable versions. It also states that WAF rules cannot cover every variant and that upgrading is the only complete fix. AWS, Google Cloud, Netlify, Fastly and Akamai published their own stopgaps. On a server you run with next start, you only had the filters you set up yourself.

How to check if your app is affected

Check the installed version, not the range in package.json: "next": "^15.1.0" can still resolve to 15.1.0 in your lockfile. Run these at the root of your project:

# npm
npm ls next react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel

# pnpm (add -r in a monorepo)
pnpm why next

# yarn
yarn why next

# the version Next.js reports for itself
npx next --version

Read it from the lockfile

# package-lock.json
grep -A1 '"node_modules/next"' package-lock.json

# pnpm-lock.yaml
grep -E '^  /?next@' pnpm-lock.yaml

# yarn.lock (Yarn 1 and Yarn Berry)
grep -A1 -E '^"?next@' yarn.lock

Check the version that is live

Production can lag behind your repository. Open your live site, open the browser console and type next.version, a check Vercel's bulletin lists. Vercel also shows a dashboard banner when a production deployment uses a vulnerable version. Its npx fix-react2shell-next scans every package.json in a repository, monorepos included, and bumps the vulnerable ones: compare where it leaves you with the versions below.

How to fix CVE-2025-55182 in November 2026

There is no workaround: the Next.js team says upgrading is required. The first fixed versions shipped on December 3, 2025: 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. They stop the remote code execution. Today they are a floor, not a target.

Seven more advisories have hit the same React code since: one source code exposure and six denial-of-service bugs, the latest in July 2026. From the April 2026 advisory on, Next.js lists fixes only on the 15.5 and 16 lines and marks every version from 13.0.0 up to them as affected. A team that moved 15.3 to 15.3.6 in December is patched against React2Shell, but still exposed to the later bugs, and the ones from April 2026 on have no fix on 15.3.

# Next.js 16 (Active LTS), current patch as of November 6, 2026
npm install [email protected]

# Next.js 15 (Maintenance LTS), if you cannot move to 16 yet
npm install [email protected]

# same with pnpm or yarn
pnpm add [email protected]
yarn add [email protected]

# React Router, Waku, Parcel or the Vite RSC plugin:
# update the React server package you use (webpack, parcel or turbopack)
npm install react@latest react-dom@latest react-server-dom-webpack@latest

These two releases also carry the fixes for unrelated 2026 Next.js advisories, including critical remote code execution bugs in the image optimizer, so stopping at the December version is not enough.

On a canary from 14.3.0-canary.77 onward, the December advisory says to return to stable 14.x or to 14.3.0-canary.76. The 2026 advisories list Next.js 13 and 14 as affected, with fixes only on 15.5 and 16, so plan the move to one of those. Firewall rules from your host buy time. They are not the fix.

What to do after upgrading

1. 1

   Confirm production runs the fix

   Redeploy, then type next.version in the console of your live site. A build cache or an old container image can keep the vulnerable version running.

2. 2

   Close old preview deployments

   Previews built before the fix still run the old code. Vercel recommends Standard Protection on every deployment except your production domain, and an audit of shareable links.

3. 3

   Rotate your secrets

   The Next.js team asks every app that was online and unpatched as of December 4, 2025 at 1:00 PM PT to rotate its secrets, the most critical first: database password, Supabase service role key, Stripe secret key, AI provider keys, then session secrets. Our guide on what to do when an API key leaks has the steps per provider.

4. 4

   Look for signs of compromise

   CISA asks owners to check every internet-facing instance after patching. On a server you run, look for what Microsoft reported: unknown processes, crypto miners, new user accounts, changed SSH settings. Then check your database and provider logs for access you do not recognize.

Related CVEs: the React2Shell family

Researchers who studied the React2Shell patch found more bugs in the same decoding code. None allows remote code execution, and the React team says the React2Shell patch remains effective. They still need newer versions.

Timeline

What Keybrum checks on a live app

A version check says what you should run, not what answers on your production domain. On a Next.js app, Keybrum checks from the outside whether the app answers the React Server Components protocol and ships Server Action ids in its JavaScript, which means the path React2Shell uses is reachable, and reports the version floor to reach. That shows the surface is live, not that your version is vulnerable: the version check above decides that. It does not send the exploit payload: Keybrum never runs remote code execution or denial-of-service payloads.

The same run tries the Next.js CVEs it can prove by behaviour, such as the middleware bypass CVE-2025-29927. See the Next.js security guide for the rest of the framework, and vibe coding security risks for what AI-built apps leak most often.