React2Shell Critical Vulnerability (CVE-2025-55182)

On December 3, 2025, the React ecosystem was hit with its own "Log4Shell-style" moment: React2Shell, tracked as CVE-2025-55182, a CVSS 10.0 unauthenticated remote code execution (RCE) vulnerability in React Server Components (RSC) and the underlying Flight protocol. It also cascades into Next.js and other frameworks as a downstream issue, tracked there as CVE-2025-66478.

Because React and Next.js sit behind millions of websites and services, and because default configurations are often exploitable, the blast radius is massive. Estimates already suggest tens of millions of sites and roughly 39% of observed cloud environments have or had vulnerable instances before patching.

Meanwhile, multiple China-nexus threat groups (including Earth Lamia and Jackpot Panda) began exploiting React2Shell within hours of disclosure, focusing on cloud credentials and further payload delivery.

TL;DR - What You Need to Know About React2Shell (CVE-2025-55182)

• Name: React2Shell

• CVE IDs:

  • CVE-2025-55182: Core RCE in React Server Components / Flight protocol

  • CVE-2025-66478: Downstream RCE in Next.js App Router and other RSC integrations

• CVSS 10.0 (maximum): unauthenticated RCE over HTTP

• Impact: 

  • Attacker can execute arbitrary code on the server, often with the same privileges as the Node.js process hosting the app.

  • No authentication required.

  • Exploitable over a single HTTP request to RSC / Server Function endpoints.

React2Shell in Plain English

Let's briefly put the jargon aside. React has a server side feature called React Server Components (RSC). RSC uses an internal protocol called Flight to send "component trees" and server function results between your browser and your server. To do this, the server serializes some data into a special format, then later deserializes it back into JavaScript objects on the server.

React2Shell is basically this:

If an attacker can send maliciously crafted RSC / Flight data to your server, React's deserialization logic can be tricked into running attacker-controlled JavaScript on your server, even if the user is not logged in.

React2Shell

Technical Deep Dive: How React2Shell Actually Works

1. The Flight Protocol and Server Functions

   1. React Server Components use Flight as a structured streaming protocol. Flight encodes

      1. Component references (e.g. which component to render).

      2. Server Functions (server-only code that can be invoked by the client via form submissions or actions).

      3. Serialized props, return values, errors, and metadata.

   2. Frameworks like Next.js App Router and others integrate Flight so that:

      1. Client submits an HTTP request (often POST) to an RSC / server action endpoint.

      2. The server decodes the Flight stream using a React server package such as react-server-dom-webpack.

      3. As part of decoding, React reconstructs server functions and objects based on identifiers in the payload.

2. The Core Bug: Unsafe Deserialization and Prototype Abuse

   1. Multiple technical write-ups (Datadog, Horizon3, eSecurityPlanet, Mondoo, etc.) converge on the same core issue: unsafe deserialization logic in React's Flight handling of server references, which can be turned into server-side prototype pollution and arbitrary code execution.

   2. The attacker sends a crafted Flight payload to an RSC/server action endpoint. This payload includes fields that React expects to represent legitimate server references.

   3. The vulnerable versions of React do not sufficiently constrain which "IDs" and object shapes are allowed when deserializing these references. Under certain conditions, an attacker can smuggle in object structures that React treats as internal capability objects instead of simple data.

   4. Once the attacker can control which "function" or "object" React reconstructs, this can lead to prototype pollution where shared prototypes gain malicious behaviors.

   5. The final stage is server-side JavaScript execution within the Node process hosting the React app.

Who Is Actually Affected?

1. React core packages

   1. From the official React advisory:

   2. Vulnerable:

      1. react-server-dom-webpack

      2. react-server-dom-parcel

      3. react-server-dom-turbopack

   3. in versions:

      1. 19.0.0

      2. 19.1.0

      3. 19.1.1

      4. 19.2.0

Vercel’s advisory and subsequent research indicate that Next.js App Router releases that integrate vulnerable React RSC builds are affected.

2. Other RSC-enabled frameworks

   1. Several frameworks and tools use RSC and the Flight protocol under the hood, including:

      1. React Router (RSC preview)

      2. Vite RSC / Flight plugins

      3. Parcel RSC

      4. Waku

      5. RedwoodJS (RSC integrations)

Remediation: How to Fix or Safely Work Around React2Shell

1. Primary fix: Patch React & Frameworks

   1. Upgrade the RSC packages to fixed versions

   2. Upgrade App Router apps to patched versions listed in Vercel’s changelog (e.g., 16.0.7 and the specific 15.x patch lines).

   3. Follow vendor advisories for:

      1. React Router RSC

      2. Vite/Parcel RSC plugins

      3. Waku, RedwoodJS, and other RSC adopters.

2. Disable React Server Components / Server Actions

3. Restrict access to RSC endpoints

4. Deploy WAF rules / signatures

5. Harden environment & secrets handling

6. Rotate API keys, database passwords, and cloud credentials if exploitation is suspected.

7. Review .env and config files, assume they may be exposed if your RSC endpoints were reachable.

In conclusion, React2Shell (CVE-2025-55182) stands as one of the most far reaching and consequential vulnerabilities the modern JavaScript ecosystem has ever faced, not because of its complexity, but because of how deeply React Server Components and Next.js are woven into today's web infrastructure. Its emergence reminds us that even mature, widely trusted frameworks can expose organizations to critical risk when powerful server-side features intersect with unsafe serialization pathways.

Ultimately, the path forward is clear: patch decisively, monitor continuously, architect defensively, and treat every client-supplied byte as untrusted. By learning from React2Shell and reinforcing secure-by-default principles across our stacks, we not only protect our applications today but strengthen the resilience of the web for years to come.

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don’t forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let’s keep the conversation going and make cybersecurity a community effort!

-AJ