React Server Components (RSC) reshaped modern web development by blending client-side interactivity with the performance and security benefits of server-side rendering. But like any major shift, it opened new attack surfaces that many teams weren’t ready for. The disclosure of CVE-2025-55182, known as “React2Shell,” shows just how serious these risks can be.
This isn’t a simple XSS flaw—it’s a critical Remote Code Execution (RCE) vulnerability that lets unauthenticated attackers run arbitrary commands on the server behind a React app. For the millions of applications built with frameworks like Next.js or custom RSC setups, the “frontend” has suddenly become one of the most dangerous entry points into backend infrastructure.
What to Remember
- Critical RCE (CVSS 10.0): CVE-2025-55182 allows attackers to run arbitrary code on the server, bypassing authentication.
- Target: The vulnerability specifically affects React Server Components (RSC), particularly how they handle and deserialize props passed from the client.
- The Mechanism: It exploits a flaw in the serialization protocol used to bridge Client and Server components, turning valid data payloads into executable commands.
- Immediate Action: Patching the React framework and underlying meta-frameworks (like Next.js) is mandatory. WAF rules (Cloud Armor) can provide temporary mitigation.
The Technical Core: How React Became a Shell
To understand React2Shell, we must first understand the architecture it exploits. React Server Components allow developers to render components exclusively on the server, sending only the resulting HTML and minimal data to the client. This reduces bundle size and allows direct access to backend resources (like databases) from within the component code.
However, these Server Components often accept “props” (arguments) from Client Components. To make this work, React uses a complex serialization protocol to pass data back and forth. CVE-2025-55182 resides in the parser responsible for deserializing these user-supplied props on the server.
The vulnerability is a classic Insecure Deserialization flaw, re-imagined for the modern JavaScript stack. When a Client Component sends a request to render a Server Component, it includes a payload defining the props. The flaw exists because the parser fails to strictly validate specific object types before instantiating them.
What React Server Components are vulnerable?
The following components have been confirmed to be vulnerable:
| Affected Component | Affected Versions |
|---|---|
| react-server-dom-parcel | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-turbopack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-webpack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
However, other frameworks that bundle React are impacted as well including Next.js, React Router, Expo, Redwood SDK, Waku and more.
Did Next.js publish their own advisory and CVE?
Yes, the Next.js team published a security advisory and their own CVE, CVE-2025-66478. However, the National Vulnerability Database (NVD) rejected this CVE as a duplicate of CVE-2025-55182.
What Next.js versions are affected?
Affected versions of Next.js that use the App Router are vulnerable, including:
| Affected Next.js versions |
|---|
| 15.0.4 and below |
| 15.1.8 and below |
| 15.2.5 and below |
| 15.3.5 and below |
| 15.4.7 and below |
| 15.5.6 and below |
| 16.0.6 and below |
| 14.3.0-canary.77 and later releases |
How severe is this vulnerability?
It has the potential to be very severe. In 2024, according to the State of JavaScript, an annual developer survey of the JavaScript ecosystem, React was used by 82% of respondents.
What adds to the elevated severity is the fact that exploitation can occur in apps that support React Server Components, even if the React Server Function endpoints are not in use.
Has CVE-2025-55182 been exploited in the wild?
As of December 3, there have been no confirmed reports of in-the-wild exploitation for CVE-2025-55182. However, there are some unconfirmed reports of exploitation circulating. The RSO team is monitoring for further confirmation and will update this section accordingly.
Are patches or mitigations available for CVE-2025-55182?
Yes, the React Team published the following fixed versions of React Server Components:
| React Server Component | Fixed Versions |
|---|---|
| react-server-dom-parcel | 19.0.1, 19.1.2, 19.2.1 |
| react-server-dom-turbopack | 19.0.1, 19.1.2, 19.2.1 |
| react-server-dom-webpack | 19.0.1, 19.1.2, 19.2.1 |
The following are fixed versions of Next.js:
| Fixed Next.js versions |
|---|
| 15.0.5 |
| 15.1.9 |
| 15.2.6 |
| 15.3.6 |
| 15.4.8 |
| 15.5.7 |
| 16.0.7 |
The Attack Chain:
- Payload Crafting: An attacker intercepts the network request generated by the React app (often a
POSTor specializedGETrequest used for RSC hydration). - Injection: The attacker modifies the serialized payload, injecting a malicious object structure that mimics a valid React element but contains a “gadget chain”—a sequence of code interactions that triggers a system command.
- Deserialization & Execution: The server receives the payload. As React attempts to “hydrate” or render the component, it deserializes the malicious object.
- Shell Access: Instead of rendering a
<div>, the server executes a shell command (e.g.,/bin/sh), granting the attacker full control over the container or host machine.
This elevates a “frontend vulnerability” to a Level 1 Critical Infrastructure Risk.
Detection: Hunting for the Exploit
Detecting React2Shell can be challenging because the traffic looks like legitimate application usage. The malicious payload is encapsulated within the standard React serialization format (often appearing as JSON-like structures with special markers).
Network Indicators:
Security teams should look for anomalous patterns in requests targeting RSC endpoints (often /_next/data in Next.js or similar routes).
- Unusual Payload Sizes: Exploits often require larger-than-normal payloads to construct the gadget chain.
- Suspicious Characters: Look for shell metacharacters (
;,|,&&,$()) embedded within the serialized data values, specifically in fields that typically map to component props. - High Error Rates: Failed exploit attempts often result in 500 Internal Server Errors as the deserializer crashes.
Remediation: The Race to Patch
The only permanent fix for CVE-2025-55182 is to upgrade the underlying libraries. The React team and major meta-framework maintainers have released emergency patches.
1. Update Dependencies Immediately:
You must update react and react-dom packages to the latest patched versions (check the official advisory for the specific version number, likely 19.x.patch or similar). Crucially, if you are using a meta-framework like Next.js, Remix, or Hydrogen, you must update those frameworks as well, as they bundle the vulnerable React runtime.
# Example for npm users
npm update react react-dom next2. Audit Custom Serializers:
If your application implements custom serialization logic or uses third-party libraries to handle complex objects between client and server, audit them immediately. The vulnerability highlights the danger of trusting any object definition sent from the client.
3. Implement Runtime Protection:
As advised by Tenable, relying solely on patching is risky due to the time lag in deployment. Deploy Runtime Application Self-Protection (RASP) or strictly configured Container Security tools. These tools can detect when a Node.js process spawns an unexpected child process (e.g., calling bash or curl), killing the attack even if the vulnerability is exploited.
The Strategic Shift: DevSecOps for the Modern Frontend
React2Shell serves as a wake-up call for the industry. The line between “frontend” and “backend” has dissolved. Frontend developers are now effectively backend engineers, writing code that runs on the server.
Security leaders must adapt:
- Shift Left: Security training for frontend developers must now include server-side concepts like deserialization, command injection, and container security.
- SCA is Vital: Software Composition Analysis (SCA) tools must be tuned to flag frontend libraries as “critical” backend risks.
Conclusion: Reacting to the New Reality
CVE-2025-55182 is not just a bug; it is a symptom of complexity. As we push more logic to the server to gain milliseconds of performance, we open doors that were previously walled off. React2Shell proves that in 2025, your “User Interface” is a remote command shell waiting to be opened.
The response requires speed and precision. Patch your frameworks, enable your WAF rules, and rethink your trust boundaries. The days of treating frontend code as low-risk are officially over.
To further enhance your cloud security, contact me on LinkedIn Profile or [email protected].
Frequently Asked Questions (FAQ)
What is React2Shell (CVE-2025-55182)?
React2Shell is a critical Remote Code Execution (RCE) vulnerability affecting React Server Components. It allows attackers to inject malicious commands via the serialization protocol used to pass data between the client and the server, effectively taking over the server.
Am I affected if I only use Client-Side React (SPA)?
Generally, no. This vulnerability specifically targets React Server Components (RSC). If your application is a traditional Single Page Application (SPA) that renders entirely in the browser (client-side only), you are likely not vulnerable to this specific RCE, though you should still keep React updated.
How does the attack work technically?
The attack exploits an Insecure Deserialization flaw. When a client sends props (data) to a server component, the server deserializes this data. The vulnerability allows an attacker to craft a malicious object that, when deserialized by the server, triggers the execution of system commands.
Can a WAF block React2Shell attacks?
Yes, but standard rules might miss it due to the specific serialization format. Advanced WAFs like Google Cloud Armor have released specific signatures to detect the malicious object structures associated with this CVE. It serves as a strong temporary mitigation.
Which frameworks are most at risk?
Any framework utilizing React Server Components is potentially at risk. This includes Next.js (App Router), Remix, React Router, Expo, Redwood SDK, Waku, and potentially others. It is critical to update the meta-framework itself, not just the React dependency.
What React Server Components are vulnerable?
The confirmed vulnerable components are react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack in versions 19.0, 19.1.0, 19.1.1, and 19.2.0. Other frameworks that bundle React are also impacted.
Did Next.js publish their own CVE?
Yes, the Next.js team published CVE-2025-66478. However, the National Vulnerability Database (NVD) rejected this CVE as a duplicate of CVE-2025-55182.
Has CVE-2025-55182 been exploited in the wild?
As of December 3, 2025, there have been no confirmed reports of in-the-wild exploitation. However, there are some unconfirmed reports of exploitation circulating.
What are the patched versions?
For React Server Components, update to versions 19.0.1, 19.1.2, or 19.2.1. For Next.js, update to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7 depending on your current version.
Resources
- Google Cloud Security Blog: Responding to CVE-2025-55182 (React2Shell)
- Wiz Research: Critical Vulnerability in React: CVE-2025-55182 Analysis
- Tenable Security Alert: React2Shell: React Server Components RCE Explained
- React Official Blog: Check for the latest release notes and security advisories.
- OWASP Deserialization Cheat Sheet: Learn more about the mechanics of insecure deserialization.
