All Posts
10 min read

React2Shell: What Security Teams Need to Know Right Now

CVE-2025-55182 is being exploited within hours of disclosure. Here's the technical breakdown, who's attacking, and exactly what your team needs to do.

vulnerability-response react-security threat-intelligence incident-response
React2Shell: What Security Teams Need to Know Right Now

Last updated: December 6, 2025. Details including payload patterns and IOCs are changing quickly-check vendor advisories for the latest.

Who this is for: security engineers, incident responders, and platform teams running Next.js or other RSC-enabled frameworks.

A critical vulnerability in React Server Components is being actively exploited by state-sponsored threat groups. If your organization runs Next.js with App Router or any framework using React Server Components, you need to act now.

This isn’t theoretical. AWS threat intelligence confirmed exploitation attempts within hours of public disclosure on December 3, 2025. The vulnerability, tracked as CVE-2025-55182 and nicknamed React2Shell, carries the maximum CVSS score of 10.0.

Here’s everything security teams need to know.

The 60-Second Summary

What it is: An unsafe deserialization vulnerability in React Server Components that enables unauthenticated remote code execution.

What’s affected:

  • React Server Components packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack) versions 19.0 through 19.2.0
  • Next.js 15.x, 16.x, and canary builds from 14.3.0-canary.77 when using App Router
  • Other RSC-supporting frameworks: React Router RSC, Waku, Redwood SDK, Expo, Parcel and Vite RSC plugins

Who’s exploiting it: Multiple China-nexus threat groups including Earth Lamia and Jackpot Panda, plus numerous unattributed clusters. Exploitation began within hours of disclosure.

What to do: Patch immediately. This is not optional.

Why React2Shell Is Different

The security community is drawing comparisons to Log4Shell, and for good reason. Both vulnerabilities share a dangerous pattern:

  1. Massive attack surface. React dominates frontend development. Next.js is one of the most popular SSR frameworks in production. Millions of applications are potentially affected.

  2. Unauthenticated exploitation. Under typical RSC configurations, a single malicious HTTP request can trigger code execution when RSC endpoints are reachable from the internet. No credentials required. No user interaction needed.

  3. Default configurations are vulnerable. You don’t need to have written insecure code. Datadog has confirmed exploitation against a blank Next.js app created with create-next-app. If your application supports React Server Components with App Router, the vulnerable code path likely exists.

  4. State actors moved immediately. This isn’t a vulnerability that will “eventually” be exploited. It’s being exploited now, by sophisticated threat groups with resources and intent.

The key difference from Log4Shell: the React team, major cloud providers, and framework maintainers coordinated before public disclosure. Patches existed on day one. The question is whether organizations will apply them fast enough.

Technical Background: How React2Shell Works

React Server Components (RSC) and Server Functions use a protocol called Flight to serialize and deserialize data between client and server. When a browser calls a server function, React decodes a Flight payload from the HTTP request, maps tokens to server-side modules and values, executes the function, and streams the response back.

React2Shell exploits a flaw in how those references are resolved during deserialization.

The Core Bug

Two related issues combine to create the vulnerability:

Unsafe path traversal in Flight payloads. The Flight serializer uses colon-separated paths like "$1:a:b" to reference nested objects. The deserializer splits these paths and walks through objects via property access. Vulnerable versions don’t properly validate property ownership, allowing attackers to traverse into unexpected structures-including locations influenced by the JavaScript prototype chain.

Missing property existence checks in module resolution. Before the patch, the code that loads module exports would return moduleExports[someName] directly without verifying the property actually exists on the module object. This allows corrupted metadata to cause the deserializer to resolve names that shouldn’t be accessible.

Together, these behaviors mean an attacker can craft a request that manipulates how the server resolves references, ultimately achieving code execution.

Critical Detail: You Don’t Need Server Functions to Be Vulnerable

This trips up many teams during initial assessment. The vulnerability exists in the RSC infrastructure itself, not in your custom server functions. Even if you never explicitly wrote a server function, your application can be vulnerable if the runtime supports React Server Components.

Any internet-reachable endpoint that processes RSC Flight payloads is potential attack surface-particularly Next.js applications using App Router or other frameworks with RSC enabled by default.

Affected Versions: The Complete List

React Server Components Packages

Vulnerable:

  • react-server-dom-webpack: 19.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-parcel: 19.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-turbopack: 19.0, 19.1.0, 19.1.1, 19.2.0

Patched:

  • react-server-dom-webpack: 19.0.1, 19.1.2, 19.2.1
  • react-server-dom-parcel: 19.0.1, 19.1.2, 19.2.1
  • react-server-dom-turbopack: 19.0.1, 19.1.2, 19.2.1

Next.js

Vulnerable:

  • 15.0.4 and below
  • 15.1.8 and below
  • 15.2.5 and below
  • 15.3.5 and below
  • 15.4.7 and below
  • 15.5.6 and below
  • 16.0.6 and below
  • 14.3.0-canary.77 and later canary releases

Patched:

  • 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7
  • 16.0.7

Note: CVE-2025-66478 was initially assigned to Next.js but rejected by NVD as a duplicate-the root cause is in React, not Next.js-specific code.

Other Affected Frameworks

  • React Router RSC preview
  • Waku
  • Redwood SDK (rwsdk)
  • Parcel RSC plugin (@parcel/rsc)
  • Vite RSC plugin (@vitejs/plugin-rsc)
  • Expo integrations supporting RSC

Each framework has specific upgrade guidance, but the fix is always the same: pull in the patched react-server-dom-* packages.

How to Check If You’re Vulnerable

Quick commands to assess your exposure:

Check for vulnerable React RSC packages:

npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel

Check your Next.js version:

npm ls next

Compare the output against the vulnerable version ranges above. If you’re running:

  • react-server-dom-* at 19.0, 19.1.0, 19.1.1, or 19.2.0 → vulnerable
  • Next.js at 15.0.4 or below, 15.1.8 or below, etc. → vulnerable

For monorepos or complex setups:

npm audit

This should flag CVE-2025-55182 if vulnerable packages are present.

Platform-hosted apps: If you’re on Vercel, Netlify, or similar platforms, check their security advisories for guidance specific to their deployment model. Vercel has published detailed guidance including platform-level protections they’ve deployed.

Who’s Exploiting React2Shell

AWS threat intelligence teams observed exploitation attempts in their MadPot honeypot infrastructure within hours of the December 3 disclosure.

Confirmed Threat Groups

Earth Lamia: A China-nexus threat actor known for exploiting web application vulnerabilities. Targets span financial services, logistics, retail, IT companies, universities, and government organizations across Latin America, the Middle East, and Southeast Asia.

Jackpot Panda: Another China-nexus group primarily targeting entities in East and Southeast Asia. Their activity typically aligns with collection priorities around domestic security and corruption concerns.

Shared Anonymization Networks: Large-scale anonymization infrastructure has become a defining characteristic of Chinese cyber operations. Multiple threat groups use these networks simultaneously, making individual attribution difficult but confirming the regional origin of most activity.

Observed Attacker Behavior

AWS provided detailed observations from honeypot monitoring:

  • Attackers are mixing React2Shell attempts with exploitation of other recent CVEs in the same campaigns
  • Automated tools use user agent randomization and cycle through multiple payload variants
  • One cluster spent 52 minutes (116 requests) systematically debugging exploitation attempts, trying commands like whoami, id, reading /etc/passwd, and writing marker files to /tmp/

This demonstrates that actors aren’t just running automated scans-they’re actively refining their techniques against live targets.

The PoC Problem

Many public proof-of-concept exploits are technically flawed. AWS and researchers note that several published PoCs require unrealistic preconditions (like deliberately registering dangerous modules in the server manifest) that wouldn’t exist in real applications.

Despite this, threat actors are attempting to use them anyway. Their strategy: scan broadly with every available tool, hope to find the small percentage of vulnerable configurations, and refine from there. Failed attempts create noise in logs that can mask more sophisticated attacks.

Working PoCs do exist. Tenable confirmed that Lachlan Davidson (the original researcher) has released an official PoC, and Datadog’s analysis confirms exploitation succeeds against default Next.js RSC setups.

Detection: What to Look For

Network Indicators

Request patterns:

  • HTTP POST requests to RSC/Next.js application endpoints
  • Headers: Next-Action, X-Nextjs-Request-Id, rsc-action-id
  • Request bodies containing:
    • multipart/form-data with JSON parts
    • Flight reference tokens like "$1:..." or "$@" patterns
    • Structures containing "status":"resolved_model"

Response patterns:

  • 500 Internal Server Error with Content-Type: text/x-component
  • Short Flight payloads in error responses (strong signal of vulnerable target)

Host Indicators

  • Node.js processes spawning unexpected children: sh, bash, whoami, id, uname
  • Attempts to read /etc/passwd or application secrets
  • File writes to /tmp/ with suspicious names
  • In containers: unexpected exec operations not matching operator activity

Detection Tools

Published IOCs

Important: These are examples from early exploitation activity, not a complete list. Attacker infrastructure rotates rapidly-prioritize behavioral detection over IP blocklists.

Example infrastructure from AWS observations (December 4, 2025):

  • 206.237.3.150 - Earth Lamia
  • 45.77.33.136 - Jackpot Panda
  • 143.198.92.82 - Anonymization Network
  • 183.6.80.214 - Unattributed cluster

Datadog maintains an evolving IOC set in their public GitHub repository. Use these for threat hunting context, but don’t rely on them as a primary control.

Immediate Actions

1. Identify Affected Applications

Inventory all applications using:

  • Next.js 15.x, 16.x, or recent canaries
  • Any framework supporting React Server Components
  • Direct dependencies on react-server-dom-* packages

Check: Is App Router enabled? Are RSC features in use? Even if you don’t think you’re using server functions, the vulnerable code path may exist.

2. Patch

React packages: Upgrade to 19.0.1, 19.1.2, or 19.2.1 for the react-server-dom-* packages.

Next.js: Upgrade to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7.

Canary users: Downgrade to stable 14.x until a fixed canary is available.

Other frameworks: Follow vendor-specific guidance; all fixes ultimately pull the patched React server packages.

3. Deploy Temporary Mitigations (If Patching Is Delayed)

These are not substitutes for patching:

  • AWS WAF: Enable AWSManagedRulesKnownBadInputsRuleSet version 1.24+
  • Vercel: Platform-level WAF protections are already deployed
  • Custom WAF rules: Block requests with suspicious RSC headers and Flight payload patterns
  • Reduce exposure: Restrict public access to RSC endpoints via reverse proxy, VPN, or IP allowlist
  • Consider disabling RSC: If feasible, temporarily disable App Router or RSC features on internet-facing deployments

4. Hunt for Compromise

Search logs for:

  • Requests with Next-Action or rsc-action-id headers
  • RSC endpoints returning frequent 500 errors with text/x-component responses
  • Unusual command execution from Node.js processes
  • Attempts to read /etc/passwd or write to /tmp/

If you find evidence of exploitation, treat it as a confirmed breach: isolate workloads, collect forensics, rotate credentials, assess lateral movement.

What React2Shell Tells Us About Modern Vulnerability Response

The speed of exploitation is the story here. Not weeks. Not days. Hours.

This is the reality security teams face: the window between public disclosure and active exploitation has collapsed. State-sponsored groups monitor vulnerability feeds and integrate public PoCs into scanning infrastructure almost immediately. Even broken PoCs get tested against real targets.

Traditional vulnerability management cadences-monthly patch cycles, quarterly assessments-can’t keep pace. By the time a critical CVE appears on a team’s radar through normal channels, exploitation may already be underway.

This is why continuous security validation matters. Point-in-time assessments can’t catch vulnerabilities that emerge between tests. The only defense against hour-scale weaponization is continuous visibility into your attack surface.

React2Shell will likely follow the Log4Shell pattern: initial exploitation by sophisticated groups, followed by broader adoption as working PoCs mature and integrate into commodity tooling. The organizations that patch in the first 48-72 hours will avoid the worst of it. Those that don’t will face an expanding threat.

Resources:

If you’re dealing with React2Shell response and need help assessing your exposure, contact us.

Ready to try autonomous pentesting?

See how Revaizor can transform your security testing.

Request Early Access