React2Shell exposes a fundamental flaw in how React Server Components interpret untrusted data, turning a routine hydration step into a reliable remote execution pathway.
Introduction
If you work with React, Next.js, or any framework that leans on React Server Components (RSC), this is the one vulnerability you cannot ignore. React2Shell isn’t just another CVE that shows up in feeds and disappears a week later. This one hits the exact machinery that powers server-side rendering, the Flight protocol, and the whole serialization layer that RSC depends on.
And the moment you look at how this bug works, you understand why it carries a full 10.0 CVSS score and why exploit PoCs surfaced almost immediately.
This write-up breaks the issue down cleanly, explains the packet-level mechanics, and gives you a blueprint for what to patch, what to rebuild, and what to monitor.
What React2Shell Is
React2Shell (CVE-2025-55182) is a critical remote code execution vulnerability inside React Server Components. It occurs when the server deserializes crafted RSC Flight frames that contain malicious type-tagged values. React trusts these frames and reconstructs internal objects from them. If a frame includes a function reference pointing to a Node.js built-in module, React stores it exactly like a legitimate RSC function.
During hydration, React invokes the reconstructed function with the attacker-supplied argument. This gives the attacker full execution inside the Node runtime.
The vulnerability lives in the trust model, not in user code.
Why React2Shell Matters?
React2Shell breaks the assumption that client-generated data cannot instruct the server to execute code. The RSC pipeline treats incoming serialization streams as trusted component metadata. Once attackers exploit this trust, they gain direct control of server-side execution.
Real consequences include
• Access to environment variables holding API keys and secrets
• Ability to read internal configuration and sensitive files
• Execution of arbitrary commands with server-level privileges
• Lateral movement across containers and cloud environments
• CI pipeline compromise when SSR code executes during builds
This turns a front-end driven vulnerability into a full-stack compromise.
Are You Affected?
You are likely affected if your application uses any of the following without the latest patches
• Next.js 14
• Next.js 15
• Early Next.js 16
• React Server DOM packages before the fixed releases
• Turbopack or Webpack-based SSR
• Vite SSR with React Server Components
• Remix or Hydrogen RSC previews
• Any custom code that processes RSC Flight frames
You should assume exposure if
• Your RSC hydration endpoint is publicly reachable
• Your app uses dynamic server-side streaming
• Your CI pipeline runs SSR previews
• Your Node runtime loads unpatched RSC modules
Checking your dependency tree is essential. If react-server-dom or next packages show outdated versions, your system is at risk.
How React2Shell Works Under the Hood
React2Shell works because the RSC hydration pipeline blindly trusts incoming Flight frames. The server reconstructs objects exactly as the payload instructs, with no distinction between data generated by React and data controlled by an attacker.
The Flight Protocol’s Role in the Vulnerability
React Server Components communicate using the Flight protocol. Each message is a sequence of tagged records. Each record contains
• A numeric ID
• A type tag representing its meaning
• A payload that carries component data or function references
Important tags include
• I for values
• F for server function references
• M for module references
• R for call instructions
React parses these records and rebuilds objects inside the Node runtime. The parser never checks if the client should be allowed to reference server-side functions.
This makes the deserializer behave like a permissive object reconstruction engine.
How Attackers Build the Exploit
A minimal exploit requires three forged frames.
Forged function reference
1 F “require(‘child_process’).exec”
Argument containing attacker input
2 I [“<redacted payload>”]
Instructions to execute the call
3 R1(2)
React processes these as if they were legitimate RSC hydration frames. Node executes the payload.
Even more advanced payloads chain vm or fs modules to achieve file access, JS execution, and internal reconnaissance.
Why Frameworks Make This Easier
Most teams do not manually expose RSC endpoints. Frameworks do this by default.
Common exposure sources include
• Next.js hydration routes
• Vite streaming SSR
• Turbopack RSC internals
• Webpack RSC integrations
• Remix RSC preview features
These endpoints usually accept Flight frames without authentication.
If the route is reachable, exploitation becomes trivial.
What This Looks Like in Practice
These examples show structure, not weapons. They are redacted for safety while remaining educational.
Multi-stage chain using vm
1 F “vm.runInThisContext”
2 I [“<redacted JS payload>”]
3 R1(2)
File access chain
1 M {“id”:”fs”,”name”:”readFileSync”}
2 I [“<redacted file path>”]
3 R1(2)
These highlight how attackers can pivot into execution or reconnaissance using built-in modules.
How This Affects Your Environment
React2Shell transforms a client-side serialization flaw into a general-purpose server compromise.
In Kubernetes
• Service account tokens become accessible
• Internal cluster workloads become reachable
• Misconfigured RBAC can enable lateral pivoting
In Docker
• Secrets stored in environment variables become exposed
• Writable container layers support persistence
• Internal application config can be modified
In serverless
• Environment secrets are exposed
• Outbound network capabilities allow exfiltration
• Internal metadata endpoints become accessible
In CI
• Build artifacts become tamperable
• Container images can be poisoned
• Keys and tokens used for deployment can be stolen
This is why the vulnerability is considered infrastructure grade.
What You Should Do Next
Responding to React2Shell means tackling the issue from multiple angles. Start with urgent fixes, reinforce the environment to limit damage from unknown gaps, and then validate that everything is patched correctly.
Immediate corrective actions
- Upgrade React Server DOM to patched versions
- Upgrade Next.js to patched versions
- Rebuild all artifacts, including Docker images, node modules, and SSR bundles
- Rotate all secrets accessible to Node runtimes
- Restrict or remove public RSC endpoint exposure
Runtime strengthening
- Block malformed Flight frames at the WAF level
- Monitor Node for suspicious child process execution
- Limit outbound network access from application servers
- Reduce permissions of server containers
Verification steps
- Confirm dependency versions are patched
- Test for RSC endpoint reachability
- Confirm patched build rejects unsafe type tags
Remediation is incomplete until a full rebuild is completed.
How Strobes help detect, prioritize, validate, and track exposure
- SCA and SBOM analysis identify vulnerable RSC packages inside repositories and containers
- SAST integrations detect unsafe import patterns or unexpected server-side module references
- DAST validates whether RSC endpoints are externally reachable or exploitable
- RBVM prioritizes RCE class vulnerabilities with the context of exploit activity and asset criticality
- CTEM workflows unify detection, prioritization, validation, and remediation into one guided process
These layers ensure not only the identification of React2Shell but also the continuous tracking of exposure across assets, applications, and environments.
Final Words
React2Shell exposes a deep flaw in the design of server-side hydration. React Server Components were built for speed and efficiency, not for threat resistance. Attackers took advantage of this trust boundary and showed that by crafting specific serialization frames, they could trigger full server execution without ever touching application code.
The vulnerability affects many widely used frameworks and build systems. It affects containerized workloads, cloud functions, CI pipelines, and production Node servers. Organizations must respond with patched dependencies, complete rebuilds, endpoint validation, and runtime controls to reduce further exposure.
React2Shell is a reminder that serialization layers, even in modern JavaScript ecosystems, deserve the same scrutiny as traditional backend technologies.
