Like and comment this article so more people can see it.
A security vulnerability with a critical CVSS score of 10.0, now widely known as "React2Shell," is threatening a substantial portion of the modern web. Tracked as CVE-2025-55182 in React and CVE-2025-66478 in Next.js, this flaw allows unauthenticated attackers to execute arbitrary code on servers running vulnerable applications. It is potentially affecting 82% of developers who use React, this is one of the most severe vulnerabilities ever disclosed in the JavaScript ecosystem.
Understanding the Vulnerability: From Deserialization to Remote Code Execution
At its core, the vulnerability is an unsafe deserialization flaw within the React Server Components (RSC) architecture. The issue resides in key react-server-dom-* packages (-webpack, -turbopack, -parcel) used to communicate between server and client.
- The Root Cause: The flaw exploits how these packages process serialized data from HTTP requests using React's "Flight" protocol. A security researcher discovered that the deserialization logic used a colon (
:) to navigate object properties without proper validation. By sending a specially crafted payload that references a non-existent property, an attacker could cause the server to crash or, more critically, manipulate the process to execute arbitrary JavaScript code. - Why It's So Dangerous: Unlike many prototype pollution bugs that require a second flaw to be useful, this vulnerability provides a direct path to Remote Code Execution (RCE) in a single request. Attackers need no prior authentication, do not need to find a specific server function to target, and require no special configuration mistakes by developers. As one advisory starkly notes, even a brand-new Next.js application created with
create-next-appis vulnerable out of the box.
Scope of Impact: Who is Affected?
The vulnerability's reach is exceptionally broad due to React's dominance and the design of modern frameworks.
| Affected Software | Vulnerable Versions | Patched Versions |
|---|---|---|
React Packages react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel
|
19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
| Next.js Framework (Using App Router) | 15.0.0 – 15.0.4, 15.1.0 – 15.1.8, 15.2.0 – 15.2.5, 15.3.0 – 15.3.5, 15.4.0 – 15.4.7, 15.5.0 – 15.5.6, 16.0.0 – 16.0.6 | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
| Next.js Canary Releases | 14.3.0-canary.77 and later | Downgrade to stable 14.x or use 14.3.0-canary.76 |
Crucially, an application is vulnerable if it supports React Server Components, even if it does not explicitly use React Server Functions. This means many developers may be at risk without realizing it.
The impact extends beyond React and Next.js. Other frameworks and tools that bundle the vulnerable RSC implementation are also affected, including:
- React Router (unstable RSC APIs)
- Waku
- Redwood SDK
- Parcel (
@parcel/rsc) - Vite RSC plugin (
@vitejs/plugin-rsc)
Immediate Actions for Development Teams
1. Patch Immediately (Primary Solution)
The only complete fix is to upgrade dependencies. Teams should update their package.json and ensure lock files are regenerated.
# For Next.js users (npm example)
npm install next@latest react@latest react-dom@latest
# For projects managing React directly
npm install react-server-dom-webpack@19.2.1
# (Use the appropriate package and patched version: 19.0.1, 19.1.2, or 19.2.1)
After upgrading, rebuild and redeploy all applications. Teams using Vercel hosting should note that while the platform applied temporary mitigations, the official patches must still be applied for full security.
2. Detect Vulnerable Systems
For security teams managing large inventories, verifying patches can be challenging. Researchers have published a high-fidelity detection method to identify truly vulnerable hosts, differentiating them from those merely running RSC. The technique involves sending a specific HTTP POST request and checking for a characteristic error response containing E{"digest" with a 500 status code. Open-source scanners based on this method are also available.
3. Apply Runtime Protections
While patching is underway, organizations should leverage Web Application Firewalls (WAF) and runtime security tools. Major providers like Fastly and Barracuda have released virtual patches and updated rules to detect and block exploitation attempts based on known malicious request patterns. Solutions like Upwind also offer runtime monitoring to detect RCE payload execution, such as unexpected shell commands or process spawning.
The Coordinated Response and Current Threat Status
The disclosure followed a responsible and coordinated process:
- Nov 29, 2025: Researcher Lachlan Davidson reported the flaw.
- Dec 1-2: Maintainers prepared fixes and privately notified major hosting providers and ecosystem partners.
- Dec 3: Public disclosure and release of patches across the ecosystem.
Top comments (1)
Like and comment this article so more people can see it.