React2Shell (CVE-2025-55182): Breaking the Server Boundary in React Server Components

In December 2025, the React ecosystem had its first truly server-grade security wake up call. A critical vulnerability affecting React Server Components (RSC) was disclosed under the name React2Shell, tracked as CVE-2025-55182.

React2Shell is not just another injection bug. It cuts straight through the abstraction React Server Components are built on, turning what should be a structured, declarative server rendering pipeline into a potential remote code execution primitive.

This post breaks down what React2Shell is, how it works at a technical level, why it exists, and what teams running RSC in production need to do now.

• Name: React2Shell
• CVE: CVE-2025-55182
• Disclosed: December 2025
• Severity: Critical
• Impact: Remote Code Execution on the server
• Affected: React Server Components implementations relying on the Flight protocol and dynamic module resolution
• Root Cause: Unsafe server-side module resolution and deserialization paths exposed through RSC request handling
• POC: Check Here

Background: Why RSC Changed the Threat Model

React Server Components fundamentally altered how React applications execute code.

Before RSC:

• Components ran either in the browser or during build time.
• User input mostly touched APIs you explicitly exposed.

With RSC:

• Components execute at request time on the server.
• The client and server communicate using the React Flight protocol, a structured stream that describes component trees, module references, and serialized props.
• The server dynamically resolves and executes component modules based on incoming Flight payloads.

That last point is where things went wrong.

High-Level Overview of React2Shell

React2Shell is a server-side vulnerability where a malicious client can craft a Flight request that causes the RSC runtime to:

1. Trust attacker-controlled module references
2. Resolve them through the server's module loader
3. Execute arbitrary server-side code

In short, the attacker escapes the RSC sandbox and lands in the Node.js runtime.

Hence the name: React to Shell.

The Vulnerable Surface: Flight + Module Resolution

At the center of React2Shell is the Flight protocol, the internal wire format used between the client and server to describe:

• Component trees
• Serialized props
• References to server modules and functions

A simplified flow looks like this:

Client
  -> sends Flight payload
     -> references server component/module
        -> server resolves module
           -> executes component
              -> returns stream

The vulnerability emerged because:

• Certain RSC implementations allowed dynamic module identifiers to be resolved at runtime
• The resolution path trusted values derived from the client-controlled Flight payload
• Validation was incomplete or entirely missing in some configurations

Once an attacker can influence what module the server loads, the jump from "render a component" to "execute arbitrary code" becomes very small.

Exploitation Flow (Conceptual)

A typical React2Shell attack chain looks like this:

1. Recon

   • Attacker identifies an application using RSC.
   • The Flight endpoint is usually discoverable via network inspection.

2. Payload Crafting

   • The attacker crafts a malicious Flight request.
   • The payload includes a manipulated module reference or serialized function call.

3. Module Resolution Abuse

   • The server attempts to resolve the supplied module identifier.
   • Path traversal, absolute paths, or poisoned bundler manifests may be leveraged depending on setup.

4. Code Execution

   • The server loads and executes attacker-chosen code.
   • This can result in command execution, environment variable access, or lateral movement.

No authentication bypass is required in the worst cases. A public RSC endpoint is enough.

Why This Was Easy to Miss

React2Shell is a classic example of framework-level trust assumptions breaking down.

Key contributing factors:

• Internal protocol exposure
  Flight was designed as an internal protocol, not a hardened public API.

• Serialization complexity
  The RSC data model includes functions, references, and symbols, all notoriously hard to safely deserialize.

• Node.js module system
  Node's dynamic require and ESM resolution are powerful and dangerous when exposed indirectly.

• Developer assumptions
  Many teams assumed RSC requests were equivalent to SSR, not realizing they exposed a new attack surface.

Affected Environments

While details vary by implementation, React2Shell primarily affects:

• Applications using React Server Components in production
• Frameworks that expose RSC endpoints directly to the internet
• Setups with:
  • Custom RSC loaders
  • Non-default bundler manifests
  • Insecure module resolution paths

Frameworks built on top of React, such as those providing app routers or server actions, may also be impacted depending on how closely they mirror the reference implementation.

Impact

Successful exploitation can lead to:

• Remote Code Execution (RCE)
• Reading server-side secrets
• Access to environment variables
• Database credentials exposure
• Full infrastructure compromise in cloud environments

In practical terms, React2Shell turns a rendering bug into a full server takeover.

Mitigations and Defensive Guidance

If you are running RSC today, treat this as a priority.

1. Patch Immediately

Apply all security updates released by the React team and your framework vendor addressing CVE-2025-55182.

2. Lock Down Module Resolution

• Disallow dynamic module paths derived from request data
• Use static manifests only
• Validate module identifiers against strict allowlists

3. Harden RSC Endpoints

• Do not expose RSC endpoints unnecessarily
• Apply authentication and CSRF protections where possible
• Rate-limit Flight requests

4. Monitor for Exploitation Signals

Look for:

• Unusual Flight payload sizes
• Unexpected module resolution errors
• Spikes in server-side exceptions tied to RSC routes

5. Reassess Trust Boundaries

Treat RSC input as untrusted user input, not internal data.

Lessons Learned

React2Shell is not just a bug. It is a warning.

As frontend frameworks continue moving logic to the server, they inherit the full risk profile of backend systems. Serialization, deserialization, dynamic loading, and execution are all sharp edges.

RSC is powerful. But power without strict boundaries always attracts attackers.

Final Thoughts

React2Shell (CVE-2025-55182) marks a turning point for React security. It demonstrates that server-first frontend architectures must be threat-modeled like any other backend platform.

If you are adopting RSC, do it with eyes open, patches applied, and assumptions challenged.

Because once rendering becomes execution, every request matters.