React Server Components RCE Crisis Decoded

React has become ubiquitous, powering dashboards, e-commerce, SaaS, and enterprise apps worldwide. React 19’s Server Components promised major performance and SEO gains by running logic server-side, driving rapid adoption. Next.js made this the default via its App Router for millions of projects—unaware of the critical flaw at its core.

On December 3, 2025, researchers disclosed CVE-2025-55182 (React2Shell), a CVSS 10.0 pre-auth RCE in React Server Components, Next.js, and related frameworks. Attackers need just one malicious HTTP request to execute arbitrary server code, making this one of the most alarming vulnerabilities given React’s massive footprint.

In this article, we will walk through exactly what the React Server Components security vulnerability is, how it works technically, which versions are affected, what attackers were observed doing with it in the wild, and the precise steps you need to take to protect your applications right now.

TL;DR:

• CVSS 10.0 pre-auth RCE: Single malicious HTTP request executes arbitrary server code—no login required.
• Affects React 19 + Next.js 15/16: Nearly 1M exposed instances; default configs vulnerable.
• Exploited within 2 days: Recon, reverse shells, cloud credential theft by nation-states.
• Patch immediately: React ≥19.0.1/19.1.2/19.2.1; Next.js ≥15.0.5/15.1.9/etc.
• RSC enabled = vulnerable: Even without Server Actions, you’re at risk.

What is React Server Components RCE Crisis Decoded?

React Server Components face a critical vulnerability (CVE-2025-55182) that allows unauthenticated remote code execution (RCE) through insecure deserialization of HTTP payloads. Attackers can craft malicious requests to Server Function endpoints, exploiting React’s decoding flaws to execute arbitrary server-side code (CVSS 10.0). The issue affects React 19.x versions and frameworks like Next.js, making urgent patching to version 19.0.1 or later essential as active exploits have been observed.

What Is CVE-2025-55182 ?

It is a flaw in how React Server Components deserialize HTTP requests, allowing attackers to run code on your server without any login or authentication

The flaw allows unauthenticated attackers to execute arbitrary code on the server via insecure deserialization of malicious HTTP requests. Testing indicates the exploit has near-100% reliability and requires no code changes to be effective against default configurations.

In plain language: an attacker can send a single crafted web request to your server, and your server runs their code. No username, no password, no special conditions required.

How the Vulnerability Actually Works

Step 1: React Server Components and Flight Protocol

To understand why this vulnerability exists, you need to understand how React Server Components communicate between the browser and the server. React Server Components use something called the “Flight protocol,” a serialization format that allows the server to send component trees, data, and function calls to the client in a structured way.

Step 2: Server Actions and Payload Vulnerability

When a user interacts with a server action (a function that runs on the server in response to a user action), the browser sends a payload back to the server using this protocol. The vulnerability exists because affected React Server Component versions fail to validate incoming payloads. This could allow attackers to inject malicious structures that React accepts as valid, leading to prototype pollution and remote code execution.

Step 3: Deserialization Flaw in the React-Server Package

The vulnerability resides in the react-server package and its implementation of the RSC Flight protocol. It is a logical deserialization flaw where the server processes RSC payloads. When a server receives a specially crafted, malformed HTTP payload, typically through data delivered in a POST request, it fails to correctly validate the structure of the data. 

Because of this insecure deserialization, the server allows attacker-controlled data to influence server-side execution logic. This results in RCE, allowing an attacker to execute arbitrary privileged JavaScript code on the server.

Step 4: Broad Exposure Even Without Server Actions

The critical technical nuance worth noting: even if an application does not strictly implement or use React Server Functions, it remains vulnerable if the application supports React Server Components generally. This catches many developers off guard; simply having RSC enabled in your project is enough to be exposed, even if you have not written a single Server Action yourself.

Which Versions Are Affected

1. Check React 19 Projects Immediately

The affected versions span the entire React 19 generation and the frameworks built on top of it. If your project upgraded to React 19 after its stable release in December 2024, you need to check your version immediately.

2. Specific Affected Package Versions

React versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages are affected: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Next.js versions affected are 15.0.0 through 15.5.6, 16.0.0 through 16.0.6, and 14.3.0-canary.77 and later canary releases.

3. Broader Framework Impact and Scale

Other frameworks bundling these packages are also affected, including React Router, Waku, RedwoodSDK, Parcel, and the Vite RSC plugin. Palo Alto Networks Cortex Xpanse identified the presence of over 968,000 React and Next.js instances in their telemetry alone. 

React is used by roughly 40% of all developers, and Next.js by approximately 18 to 20%. The scale of exposure makes this one of the most broadly impactful framework vulnerabilities in recent memory.

What Attackers Were Actually Doing With It

This was not a theoretical vulnerability that sat quietly after disclosure. Exploitation activity related to this vulnerability was detected as early as December 5, 2025, just two days after public disclosure. Both Windows and Linux environments were observed to be impacted.

1. The attack chain started with reconnaissance. Attackers rapidly fingerprinted compromised systems, verified privilege levels, mapped network interfaces, and enumerated sensitive credentials and DNS configurations to identify cloud environments or internal targets for lateral movement.
2.  After reconnaissance, the attacks moved into payload delivery. Post-exploitation, attackers were observed to run arbitrary commands such as reverse shells to known Cobalt Strike servers.
3.  To achieve persistence, attackers added new malicious users, utilized remote monitoring and management tools such as MeshAgent, modified authorized key files, and enabled root login. 
4. The payloads varied widely across different attack campaigns: malware payloads seen included remote access trojans like VShell and EtherRAT, the SNOWLIGHT memory-based malware downloader, ShadowPAD, and XMRig cryptominers.
5. One of the most concerning aspects of the post-exploitation activity was the targeting of cloud credentials specifically. 
6. Credentials targeted included Azure Instance Metadata Service endpoints for Azure, Amazon Web Services, Google Cloud Platform, and Tencent Cloud to acquire identity tokens, which could be used to move laterally to other cloud resources.
7.  Attackers also deployed secret discovery tools such as TruffleHog and Gitleaks, along with custom scripts to extract several different secrets.
8.  Attempts to harvest AI and cloud-native credentials such as OpenAI API keys, Databricks tokens, and Kubernetes service-account credentials were also observed.
9. Unit 42 also identified activity consistent with CL-STA-1015, an initial access broker assessed with medium confidence to be a Chinese state-sponsored threat actor, as well as activity sharing overlaps with North Korean DPRK contagious interview tooling. 
10. This was not just opportunistic criminals; sophisticated nation-state actors were moving on this vulnerability within days of its disclosure.

Why This Vulnerability Is So Dangerous

CVE-2025-55182 is Exceptionally Dangerous

• Several factors combine to make CVE-2025-55182 exceptionally dangerous, even by the standards of critical vulnerabilities. This vulnerability presents a significant risk because default configurations are vulnerable, requiring no special setup or developer error.
•  Public proof-of-concept exploits are readily available with near-100% reliability. Exploitation can happen without any user authentication since this is a pre-authentication vulnerability. The vulnerability could be exploited using a single malicious HTTP request.

Pre-Authentication and Deterministic Exploitation

• The pre-authentication aspect deserves extra emphasis. Most serious vulnerabilities require an attacker to at least have a valid user account on your application, which means compromising credentials first. CVE-2025-55182 requires nothing. An attacker who knows your application runs React Server Components can attempt exploitation immediately, with no prior access needed. 
• The critical distinction of this vulnerability is its nature as a deterministic logic flaw in the Flight protocol, rather than a probabilistic error. Unlike memory corruption bugs that may fail, this flaw guarantees execution, transforming it into a reliable system-wide bypass for attackers. 
• Amplified by the massive footprint of Next.js in enterprise environments, this creates a direct conduit to sensitive internal data.

How to Fix It: Patching Steps

Step 1: Understand the Fix

The fix is clear and straightforward. There are no workarounds that fully address the vulnerability. Patching to the fixed versions is the only definitive mitigation.

Step 2: Upgrade to Patched Versions

Upgrade to the following patched versions or later within the same release line: React 19.0.1, 19.1.2, or 19.2.1. Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. Because many frameworks and bundlers rely on these packages, make sure your framework-level updates also pull in the corrected dependencies.

Step 3: Check Your Current Versions

To check which version of React you are currently running, open your terminal in your project directory and run `npm list react`. To check Next.js, run npm list next. If either returns a version in the affected ranges listed above, update immediately.

Step 4: Manually Verify Packages

Navigate to your project directory and open the node_modules folder. Review installed packages and look for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Validate versions against the known affected range. If any of these packages match the affected versions, remediation is required. Prioritize internet-facing assets first.

Additional Protective Measures

1. Prioritize Patching as Primary Fix

While patching is the only complete fix, several additional measures can reduce your risk and help you detect exploitation attempts.

2. Azure WAF Rules for Immediate Protection

For teams using Azure, apply Azure Web Application Firewall custom rules for Application Gateway and Application Gateway for Containers to help block exploit patterns while patching is in progress. Microsoft has published rule guidance and JSON examples in the Azure Network Security Blog, with ongoing updates as new attack permutations are identified.

3. Harden Container Security Configurations

For container and cloud environments, review your container security configurations carefully. Some of the vulnerable applications are deployed inside containers, and the impact on the underlying host is dependent on the security configurations of the container. A well-hardened container limits the blast radius of a successful exploit, but hardening alone is not a substitute for patching.

4. Monitor Logs for Exploitation Indicators

Monitor your logs for the reconnaissance signatures that attackers used early in the exploitation chain. Commands like id, whoami, uname -a, and hostname being executed by your Node process, or unexplained outbound connections from your application server, are strong indicators that exploitation has already occurred, and an incident response process should begin immediately.

Why Updating Dependencies Matters More Than You Think

• Many developers think of framework updates as something to schedule at their convenience, a routine maintenance task that can wait until the next sprint cycle. CVE-2025-55182 is a clear reminder of why that mindset is dangerous for security-critical updates.
• The immediate and expansive exploitation of this vulnerability highlights the speed at which threat actors move to seize on opportunities.
•  Exploitation began within days of public disclosure, and the scale of affected instances, nearly a million React and Next.js deployments visible in one telemetry dataset alone, meant attackers had an enormous target surface to scan.
• The tooling that attackers used, automated scanners probing for the vulnerability, means that even applications that are not well-known or high-profile were exposed.
•  You do not have to be a significant target to get hit by opportunistic automated exploitation. Any application running an affected version and accessible from the internet was at risk from the moment public proof-of-concept code became available.

Ready to master AI-powered threat detection, secure React/Next.js deployments against CVE-2025-55182, and build resilient ML models for cybersecurity? Explore HCL GUVI’s AI and ML Course and supercharge your tech career with cutting-edge security skills.

Final Thoughts

CVE-2025-55182 is one of the more impactful framework-level vulnerabilities the JavaScript ecosystem has seen. A perfect CVSS score, pre-authentication exploitation, near-100% exploit reliability, and a target surface of nearly a million deployments is a combination that demands immediate action rather than scheduled maintenance.

If your application uses React 19 or Next.js 15 or 16, check your versions today, patch to the fixed releases, and verify that your dependencies have pulled in the corrected packages. If you are not sure whether you are affected, the manual identification steps above will tell you in under five minutes.

The patch is available, the fix is straightforward, and there is no reason to leave your application exposed.

FAQ’s

1. Do I need Server Actions to be vulnerable?

No, even basic React Server Components (RSC) enabled make you vulnerable.

2. How do I check if I’m affected?

Run npm list react next upgrade` if React 19.0.0-19.2.0 or Next.js 15.0.0-15.5.6.

3. Was this exploited in the wild?

Yes, starting Dec 5, 2025: reconnaissance, Cobalt Strike, credential theft, and cryptominers.

4. What’s the patch?

React 19.0.1+, Next.js 15.0.5+ (full list in article). No workarounds.

5. How to block exploits while patching?

Azure WAF rules + log monitoring for id, whoami, outbound connections.