CVE-2025-55182, widely nicknamed React2Shell, is a critical React Server Components remote code execution flaw that affected default RSC setups across React and several framework integrations. The safest reading is simple: if your application supports React Server Components, do not assume you are safe just because you never wrote a custom Server Function endpoint.
The issue sits in how React Server Components handle serialized payloads. In vulnerable versions, a crafted request can reach the server-side React Flight handling path and lead to arbitrary JavaScript execution in the Node.js process. That is why the vulnerability received a 10.0 CVSS score and why framework teams, cloud providers, and WAF vendors treated it as an emergency.
What is vulnerable?
The React team’s official advisory says the affected packages are the React Server Components packages in React 19.0, 19.1.0, 19.1.1, and 19.2.0 [1]:
react-server-dom-webpackreact-server-dom-parcelreact-server-dom-turbopack
Fixed React versions are 19.0.1, 19.1.2, and 19.2.1. For Next.js App Router, patched releases include 16.0.7, 15.5.7, 15.4.8, 15.3.6, 15.2.6, 15.1.9, and 15.0.5. The vulnerability was also discussed under Next.js-specific tracking before being treated as part of the same underlying React Server Components issue.
The affected ecosystem goes beyond a single package name. Applications using Next.js App Router, React Router RSC preview features, Waku, Parcel or Vite RSC integrations, or other frameworks that bundle RSC support should verify their exact dependency tree. A project may be exposed because a framework depends on the vulnerable RSC package, even if the app code does not obviously import it.
Why React2Shell was treated as urgent
React2Shell is dangerous because the vulnerable path sits in normal server-side framework behavior. This is not a “debug endpoint left open” problem and not a case where an attacker needs a user account. If the vulnerable RSC processing path is reachable, the attacker may be able to send a malicious request directly to the application.
That also changes incident response. Teams should not only patch package versions. They should check whether suspicious requests reached Server Function or RSC endpoints before patching. Cloudflare and other edge providers published emergency WAF guidance because many organizations needed a temporary shield while applications were being rebuilt and redeployed [2].
What to do now
- Patch React and framework packages to the fixed versions from the official advisory.
- Rebuild and redeploy affected applications. Updating
package.jsonis not enough if old server bundles are still running. - Search logs for unusual POST requests to RSC, Server Function, or framework action endpoints.
- Use WAF rules as a temporary layer if immediate patching is blocked, but do not treat WAF as the final fix.
- Review secrets available to the server process if exploitation is suspected. RCE means environment variables, API keys, and cloud credentials may be in scope.
How to patch quickly
For a typical Next.js application, update Next.js, React, and React DOM together, then rebuild from a clean dependency install:
# npm
npm install next@latest react@latest react-dom@latest
npm run build
# yarn
yarn upgrade next react react-dom
yarn buildFor monorepos, check each application independently. A patched root package does not guarantee every workspace or deployed service is using the fixed build. Also check lockfiles and container images, because a stale Docker layer can keep vulnerable packages alive after the repository looks corrected.
What to check after patching
After deployment, confirm the running server no longer includes the vulnerable RSC package versions. Then review access logs, WAF logs, application errors, and outbound network telemetry from the exposure window. A successful exploit can run code in the server process, so suspicious outbound connections after unusual RSC requests should be treated seriously.
If you find signs of exploitation, rotate secrets exposed to the application runtime. That may include database credentials, cloud access keys, API tokens, signing keys, and deployment credentials. React2Shell is a framework vulnerability, but the real damage depends on what the compromised process could reach.
References
- React, “Critical Security Vulnerability in React Server Components,” December 3, 2025. Official advisory
- Cloudflare, emergency WAF guidance for the React vulnerability. Cloudflare guidance
- AWS Security Bulletin AWS-2025-030. AWS bulletin
- Wiz analysis of CVE-2025-55182 exposure patterns. Analysis
