DEV Community

Cover image for React2Shell (CVE-2025-55182): Critical RCE in React Server Components and Next.js
Wilson Kinyua
Wilson Kinyua

Posted on

React2Shell (CVE-2025-55182): Critical RCE in React Server Components and Next.js

#react #nextjs #vulnerabilities

In early December 2025, the React and Next.js ecosystem was hit with a critical remote code execution (RCE) vulnerability in React Server Components (RSC), now widely known as React2Shell. Tracked as CVE-2025-55182, this issue allows an unauthenticated attacker to execute arbitrary code on servers running vulnerable React RSC implementations, including many modern Next.js apps using the App Router.

If your app was created recently with create-next-app and deployed without extra hardening, there's a good chance it was affected before you upgraded.

Where This Vulnerability Came From

The root cause lies in React's RSC "Flight" protocol, which defines how server components serialize and stream data to the client. Under certain conditions, the server-side handling of these RSC payloads allowed unsafe deserialization, opening a path to arbitrary code execution.

Security researcher Lachlan Davidson privately disclosed the issue to Meta's React team on November 29, 2025, and it was assigned CVE-2025-55182 with a maximum CVSS score of 10.0. React and Vercel coordinated patches that shipped publicly on December 2–3, 2025, followed by advisories from cloud vendors, security companies, and national CERTs.

Note on CVE tracking: You may see references to CVE-2025-66478 for Next.js specifically. This CVE was later rejected by the National Vulnerability Database (NVD) as a duplicate of CVE-2025-55182, so both React and Next.js vulnerabilities are now tracked under the single CVE-2025-55182 identifier.

How It Affects Websites and Servers

The vulnerability lets an attacker send specially crafted RSC requests that the server parses and executes in unsafe ways. Because RSC processing lives on the server, successful exploitation can lead to full RCE: running arbitrary commands, accessing environment variables, or pivoting deeper into your infrastructure.

Security researchers at Wiz constructed a fully working RCE proof-of-concept with near-100% reliability. Within hours of public disclosure, multiple security firms observed active exploitation in the wild.

This is not theoretical. Amazon's threat intelligence teams observed attackers establishing shells to harvest credentials from environment variables, filesystems, and cloud instance metadata. In some compromised environments, attackers attempted to identify and exfiltrate AWS credentials. At other organizations, exploitation was followed by attempts to install malware frameworks like Sliver.

Who Is Affected

React Core

The vulnerability affects server-side use of React 19 with React Server Components enabled. According to React's official advisory, the following versions are vulnerable:

  • React 19.0.0
  • React 19.1.0, 19.1.1
  • React 19.2.0

Patched React versions:

  • 19.0.1
  • 19.1.2
  • 19.2.1

Next.js

Any framework that embeds RSC support on the server is in scope. For Next.js specifically:

Affected versions:

  • All Next.js 15.x versions before their patched releases (including 15.0.x, 15.1.x, 15.2.x, etc.)
  • Next.js 16.0.0–16.0.6
  • Next.js 14.3.0‑canary.77 and later 14.x canary builds using App Router + RSC​

Patched versions (upgrade to at least):

  • 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, or 15.5.7
  • 16.0.7 or higher
  • Stable Next.js 14.x (avoid canary builds in production)

Other Affected Projects

The vulnerability also affects other RSC implementations:

  • React Router (RSC preview)
  • Waku
  • Redwood SDK
  • @parcel/rsc
  • @vitejs/plugin-rsc

If you're running a typical App Router project created recently with create-next-app on 15.x or 16.x, assume you were affected until you upgrade.

In practice:

React Server Components rely on a binary protocol called Flight to serialize component trees and data between server and client. In vulnerable versions, the server trusted certain parts of this payload too much, allowing an attacker-controlled message to influence how values are resolved on the server.

In practice:

  1. An attacker sends a crafted HTTP request targeting the RSC endpoint in a vulnerable app
  2. The server parses the payload and, due to unsafe deserialization, ends up calling dangerous APIs under some conditions
  3. The result is unauthenticated RCE on the machine running your Next.js server or serverless function

No special misconfiguration or app-level bug is required. The vulnerability exists in the framework's RSC path itself under default settings—a standard Next.js app created with create-next-app and built for production can be exploited with no code changes by the developer.

How to Fix It

There is no reliable config toggle or middleware workaround. The fix is to upgrade React and Next.js to patched versions and redeploy.

Step 1: Check If Your App Is Vulnerable

Inspect your package.json for next, react, and react-dom versions:

cat package.json | grep -E '"(next|react|react-dom)"'
Enter fullscreen mode Exit fullscreen mode

You are vulnerable if:

  • next is in the 15.0.0–15.0.4 or 16.0.0–16.0.6 range
  • You're on 14.3.0-canary.77 or later canary builds
  • react is 19.0.0, 19.1.0, 19.1.1, or 19.2.0

Step 2: Upgrade to Patched Versions

For most projects, upgrade to the latest patched stable in your major line:

# General case - upgrade to latest
npm install next@latest react@latest react-dom@latest

# Or with yarn
yarn add next@latest react@latest react-dom@latest

# Or with pnpm
pnpm add next@latest react@latest react-dom@latest
Enter fullscreen mode Exit fullscreen mode

If you need to stay within specific majors:

# For Next.js 15.x
npm install next@15.0.5 react@19.0.1 react-dom@19.0.1

# For Next.js 16.x
npm install next@16.0.7 react@latest react-dom@latest
Enter fullscreen mode Exit fullscreen mode

Step 3: Scan Your Dependencies

Beyond this specific vulnerability, it's good practice to scan your npm packages for security issues. Tools you can use:

npm audit (built-in):

npm audit
npm audit fix
Enter fullscreen mode Exit fullscreen mode

npmscan.com — A browser-based tool focused on detecting malware, crypto-drainers, and supply-chain attacks that traditional CVE databases might miss. Simply paste your package.json content for instant analysis. Unlike npm audit which only checks known CVEs, npmscan uses heuristics to detect suspicious behavior patterns like obfuscation, exfiltration attempts, and malicious postinstall hooks.

For sensitive/private codebases, review their privacy policy before pasting your full package.json, or stick to npm audit inside your CI.

Step 4: Rebuild and Redeploy

After upgrading:

  1. Rebuild your application: 
   npm run build
Enter fullscreen mode Exit fullscreen mode

  1. Redeploy to production (Vercel, your own Node server, containers, etc.)

  2. Review logs and monitoring for suspicious RSC-related traffic or unexpected process behavior, especially if your app was publicly exposed before the patch window

  3. Look for indicators of compromise:

    • Unexpected outbound network connections
    • Suspicious processes spawned by your Node.js application
    • Unauthorized access to environment variables or secrets
    • POST requests with next-action or rsc-action-id headers in your logs

Who Should Treat This as Urgent

You should treat this as an immediate incident if:

  • You run a public Next.js App Router app on 15.x or 16.x with RSC enabled, especially on self-hosted infrastructure
  • Your servers have direct access to sensitive resources (databases, message queues, internal APIs, secrets)
  • You manage multi-tenant SaaS where compromise of one Node process could expose multiple customers
  • You haven't updated your Next.js or React dependencies since before December 3, 2025

Cloud providers and managed platforms (Vercel, AWS, Google Cloud) have added protective filtering, but all of them emphasize that upgrading your app's dependencies is mandatory—platform-level mitigations are not a substitute for patching.

Why This Matters for Everyday Next.js Developers

For most of us, this incident is a reminder that "framework defaults" are still security-sensitive code paths. You don't have to be doing anything fancy with RSC for a vulnerability like this to affect you—simply using the modern App Router with current defaults was enough.

On the positive side, the coordinated response between the React team, Vercel, security researchers, and cloud vendors has been fast and transparent. If you keep a disciplined habit of dependency updates and subscribe to framework security advisories, you're already doing one of the highest-leverage things you can do for your app's security posture.

Resources

If you’d like to see how I’m building and securing real-world React/Next.js projects, you can check out my portfolio and resume here: https://wilsonkinyua.com/

Top comments (1)

Collapse
 
treelz profile image
Dean Walters •

Despite long-term operation, this vulnerability was the first to be exploited against me. Attackers deployed a miner onto several of my pet projects.