React2Shell (CVE-2025-55182): A Deep Dive Into the Most Severe RSC Vulnerability to Date
Dec 12, 2025, 02:20
The React ecosystem has just experienced one of its most consequential security incidents in years. CVE-2025-55182, now widely referred to as React2Shell, exposes a class of unauthenticated remote code execution (RCE) vulnerabilities rooted in the internals of the React Server Components (RSC) Flight protocol. With a CVSS score of 10.0, concrete proof-of-concept exploits, and widespread downstream exposure (Next.js, RedwoodJS, Waku, Vite RSC plugins, Parcel), this vulnerability represents a rare, ecosystem-wide supply-chain event.
This article provides a technical deep dive into how the flaw works, why it matters, and what engineering organizations must do immediately to secure production systems.
1. Background: How RSC and the Flight Protocol Work
React Server Components introduce a hybrid execution model in which part of the UI tree executes on the server and part on the client. Communication between the two occurs through the Flight protocol, a compact, non-JSON serialization format designed for streaming component hierarchies, module references, and server action metadata.
In a typical RSC architecture:
2. The server uses the RSC loader to deserialize the request payload into:
●arguments for those actions,
●component boundaries,
●placeholders for client components.
3. React executes server code, resolves modules, then streams back a Flight response.
In other words, React intentionally exposes a server-side evaluation surface. As long as the deserialization layer is fully trusted and strongly validated, the model works.
With React2Shell, that trust boundary was broken.
2. Root Cause: Unsafe Deserialization in RSC Request Handling
The vulnerability stems from unsafe deserialization of attacker-controlled Flight payloads inside react-server-dom-* packages (React 19.0.0 through 19.2.0).
More specifically:
●The deserializer does not sufficiently validate the structure or origin of these embedded tokens.
●An attacker can craft a malicious POST request to an RSC endpoint, injecting a payload that forces the server to:
●invoke server actions with forged metadata,
●or coerce the evaluation engine into executing arbitrary code paths.
This is not a traditional injection bug; it is a logic flaw in the core interpreter for Flight payloads.
Because the RSC protocol is inherently interpreted and not declarative, malformed payloads can break out of the intended execution sandbox entirely.
3. Why the Impact Is So Severe
This vulnerability is rated CVSS 10.0 for three reasons:
3.1 Unauthenticated RCE
No authentication, sessions, CSRF, or cookies are required. Any remote client can POST a malicious Flight payload.
3.2 Abusable in Default Framework Configurations
A freshly created Next.js app (create-next-app) configured for production is exploitable without any custom code.
3.3 Full compromise of server integrity
Successful exploitation gives an attacker:
●Access to deployed secrets
●Access to environment variables (database credentials, API tokens)
●Ability to drop persistent backdoors (webshells, cron jobs)
●Ability to pivot laterally within the hosting environment
With modern hosting platforms (Vercel, AWS Lambda, Cloudflare Workers), this translates into high-speed compromise across thousands of deployments.
4. Affected Ecosystem: React, Next.js, and Beyond
The vulnerability exists within React’s core RSC handler, but all frameworks relying on the Flight protocol are affected by default.
4.1 Affected React Versions
●React 19.0.0●React 19.1.0
●React 19.1.1
●React 19.2.0
Affected packages include:
●react-server-dom-webpack●react-server-dom-vite
●react-server-dom-esm
4.2 Downstream Frameworks
Because RSC sits at the core of many modern full-stack React frameworks, downstream ecosystems inherit the vulnerability:
●Next.js (CVE-2025-66478)●React Router RSC preview
●RedwoodJS
●Waku
●Vite RSC plugin
●Parcel RSC plugin
If your application uses the App Router, Server Components, or Server Actions, it is almost certainly affected unless patched.
5. What Makes This Vulnerability Trivial to Exploit?
Proof-of-concept exploits now publicly demonstrate:
●How to craft a malicious Flight stream via cURL●How to inject server-action tokens into the deserializer
●How to coerce module loading paths into executing arbitrary code on Node.js servers
Importantly:
Exploitability does not require knowledge of the application’s internal components. Flight tokens reference built-in RSC execution primitives available in every RSC deployment.
This makes React2Shell more similar to a language-runtime RCE (e.g., unsafe Ruby/YAML deserialization) than a typical application-level bug.
6. Remediation: What Teams Must Do Right Now
6.1 Patch Immediately
Upgrade affected packages:
Patched versions include:
●19.0.1, 19.1.2, 19.2.1 or later (Your minor line determines which one applies.)For Next.js:
Or, if pinned to a major/minor:
npm install next@16-latest
6.2 Redeploy All Builds
Next.js must regenerate its RSC manifest and re-serialize Flight boundaries.
6.3 Add Temporary WAF Rules (Recommended)
Block suspicious POST requests to known RSC endpoints:
●POST /_rsc●POST /?__flight__*
●Any request with Flight markers ($, J, @ tokens)
While not a full mitigation, WAF rules buy time during incident response.
6.4 Review CI/CD Secrets
Assume the possibility of leakage if your servers were publicly reachable and unpatched for a meaningful period.
Rotate:
●API keys
●JWT secrets
●OAuth tokens
6.5 Monitor for Indicators of Compromise
Set alerts for unusual behavior:
●Suspicious Node.js child processes●Unexpected file writes on the server
●Unusual outbound network connections
●High CPU usage (crypto-miners)
7. Architectural Lessons: RSC as a Security Boundary
React Server Components introduce a radically different trust model:
●The server interprets client-provided payloads.●The serialization format is custom, non-JSON, and not human-auditable.
●The protocol acts as an instruction stream rather than a data structure.
This vulnerability should be a wake-up call for the ecosystem.
Key takeaways:
1. RSC is not just a rendering feature — it is a distributed execution layer.2. Serialization formats that carry execution semantics require strict validation.
3. A compromised deserializer becomes a universal attack vector.
4. Frameworks must treat RSC boundaries with the same rigor as language runtimes.
The industry has faced similar incidents with:
●Java’s serialization engine●Python’s pickle
●Ruby’s YAML deserialization
●PHP’s unserialize
●Node.js prototype pollution attacks
React2Shell brings this class of vulnerability into the JavaScript UI ecosystem for the first time at scale.
8. Where the Ecosystem Goes Next
We expect significant ecosystem shifts in the coming months:
●Hardened RSC deserialization logic●Additional validation layers inside Next.js and other frameworks
●Industry-wide push toward isolation of server actions
●Runtime isolation models (edge sandboxes, per-request VMs)
●Potential redesign or versioning of the Flight protocol
Organizations leveraging React for production workloads must begin treating RSC as a critical server-side platform, not just a frontend optimization.
9. Conclusion
CVE-2025-55182 marks a turning point for React as a full-stack platform. The combination of:
●unauthenticated RCE,●widespread framework adoption,
●trivial exploitability,
●and deep integration into production systems
makes React2Shell the most severe vulnerability in the history of the React ecosystem.
Immediate patching is mandatory. Long-term architectural vigilance is non-negotiable.
As full-stack React becomes the norm, the boundary between UI development and backend security has dissolved. Engineering teams must treat RSC infrastructure with the same respect traditionally reserved for application runtimes and API servers.
If your organization depends on Next.js, RSC, or React 19, now is the time to patch, harden, and re-evaluate your security posture.
