A comprehensive deep dive into React2Shell (CVE-2025-55182)

If you already spend your days juggling cloud pentests, CI/CD breakages, and “can we patch after Black Friday?” conversations, React2Shell probably feels like déjà vu after Log4Shell.

CVE-2025-55182 (a.k.a. React2Shell) is a critical, unauthenticated remote code execution (RCE) bug in React Server Components (RSC) with a CVSS score of 10.0. It affects modern stacks running React 19 and frameworks like Next.js App Router, React Router, Waku, and others that implement the same protocol.

This CVSS 10.0 pre-auth remote code execution vulnerability in React Server Components (RSC) was disclosed on December 3, 2025 – and China-nexus threat actors started exploiting it within hours. It hits modern web stacks hard: Wiz estimates that 39% of cloud environments include vulnerable instances.

Within days of disclosure, researchers saw opportunistic mass scanning, cryptomining, credential theft, and state-linked threat activity targeting internet-facing Next.js apps and other RSC workloads.

The flaw is a deterministic logic bug in the Flight protocol: a single crafted HTTP POST to a server function endpoint can reliably achieve code execution, with no authentication, no user interaction, and default framework settings.

For you, as a penetration tester or security engineer, this raises very practical questions:

• Which of my apps are actually exposed?

• How do I detect exploitation quickly without drowning in noise?

• What’s the realistic business impact if one RSC endpoint gets popped?
  
  

This article walks you through those answers from a practitioner’s angle:

• Clear version and exposure mapping (React, Next.js, and other frameworks).

• A deep dive into the Flight protocol bug and why exploitation is so reliable.

• What threat intel shows right now about in-the-wild attacks.

• Practical detection and mitigation steps you can apply in real environments.

• How to validate exposure and exploitability with Pentest-Tools.com.

Let’s get into it!

React2Shell – what CVE-2025-55182 is and why it matters

On December 3, 2025, the React team disclosed the critical security issue in React Server Components’ Flight protocol, tracked as CVE-2025-55182 and quickly nicknamed React2Shell.

Key facts:

• Type: Unsafe deserialization / logic flaw in the RSC “Flight” protocol.

• Impact: Pre-auth remote code execution on the server (source).

• CVSS: 10.0 (maximum severity).

• Scope: React 19 server-side packages and downstream frameworks that implement RSC, notably Next.js App Router.

• KEV: CISA added CVE-2025-55182 to its Known Exploited Vulnerabilities catalog shortly after disclosure (source).
  
  

From a risk-scoring perspective, React2Shell is just as scary:

• Our Vulnerability & Exploit Database lists CVSSv3 10.0, EPSS ≈ 0.28, EPSS percentile ≈ 0.97 (as December 9,2025), highlighting both severity and likelihood of exploitation.

• Wiz’s cloud telemetry shows 39% of cloud environments include vulnerable React/Next.js combinations, with 44% of all cloud environments exposing Next.js apps publicly (source).
  
  

In other words: this isn’t a niche bug in an obscure framework. It’s a critical RCE sitting at the intersection of modern front-ends and cloud-native backends.

Where React2Shell lives - attack surface and affected versions

Affected React packages

React2Shell sits inside the React Server Components Flight protocol, which several npm packages implement. The React team confirmed the vulnerability in the following server-side packages and versions:

• react-server-dom-webpack – 19.0.0, 19.1.0, 19.1.1, 19.2.0

• react-server-dom-parcel – 19.0.0, 19.1.0, 19.1.1, 19.2.0

• react-server-dom-turbopack – 19.0.0, 19.1.0, 19.1.1, 19.2.0
  
  

These are the components that decode and process RSC payloads on the server. 

If your app:

• Renders React exclusively on the client; or

• Doesn’t use a framework/bundler that supports React Server Components
  
  

… then you’re outside this vulnerability’s scope (lucky you!).

Affected Next.js versions

Because Next.js bundles a hardened copy of the RSC implementation, it gets its own advisory (CVE-2025-66478), which was later marked as a duplicate of CVE-2025-55182. The root cause is still React2Shell; the CVE ID just converged.

Per the Next.js security advisory, applications using the App Router with React Server Components are vulnerable when running:

• Next.js 15.x (pre-15.5.7)

• Next.js 16.x (pre-16.0.7)

• Next.js 14.3.0-canary.77 and later canary releases
  
  

Not affected:

• Next.js 13.x,

• Next.js 14.x stable,

• Pages Router apps,

• The Edge Runtime.
  
  

Other frameworks that React2Shell impacts

This vulnerability is not just about Next.js. Because the flaw lives in the RSC Flight protocol, any framework that embeds or wraps the vulnerable packages is potentially affected. Public advisories mention:

• React Router (server components)

• Waku

• @parcel/rsc

• @vitejs/plugin-rsc

• Other “native” RSC server implementations that call the vulnerable decoder directly.
  
  

As a pentester or any other member of the security team, this means you shouldn’t stop at “we don’t run Next.js” – you need to look for any RSC-aware bundler or framework.

Exposure on the public internet

Early telemetry makes it clear this isn’t a low-volume curiosity:

• BleepingComputer reports that tens of thousands of IPs are visible on the internet with behavior consistent with React2Shell scanning and exploitation, and notes that more than 30 organizations have already been compromised.

• GreyNoise observed widespread automated probing for CVE-2025-55182, with attackers re-using and adapting public PoCs in botnet campaigns.

• AWS and multiple vendors link China-nexus threat groups to early exploitation waves.
  
  

On top of that, CVE-2025-55182 is now in CISA’s KEV, which usually correlates with sustained exploitation and mandatory patch deadlines for federal agencies.

For anyone running internet-facing React/Next.js workloads, this is high-priority patching territory, not “we’ll batch it in the next sprint.” 

How the React2Shell exploit works in the Flight protocol

Quick refresher: Flight and React Server Components

React Server Components (RSC) introduce a server-driven rendering model where:

• The server serializes component trees and streams them to the client.

• The client uses the Flight protocol to receive this serialized UI state.

• A reply flow lets the client send data back for Server Actions – essentially remote function calls exposed by RSC.
  
  

React2Shell lives entirely in this client-to-server reply flow. The server:

1. Accepts a serialized payload containing metadata about a server function, plus arguments.

2. Deserializes it into JavaScript objects.

3. Resolves the indicated module + export and calls it.
   
   

The vulnerability comes from how that resolution logic navigates object properties.

The core deserialization flaw

At the heart of the bug is a helper like requireModule in the react-server-dom-* packages. It receives module metadata (module id, export name) and resolves the export with roughly this pattern:

const exports = moduleTable[id];
const fn = exports[name];    // bracket notation, no validation

Two key issues collide here:

1. Bracket notation walks the prototype chain
   In JavaScript, obj[key] doesn’t stop at obj’s own properties; it walks up the prototype chain. So if an attacker can influence name, they can reach properties on Object.prototype, arrays, or other constructors.

2. No hasOwnProperty or export allow-list
   The code assumes the metadata always points to a legitimate export. There’s no Object.hasOwn or similar check to block inherited or poisoned properties.

Combine this with unsafe deserialization – where arbitrary keys in the Flight payload become object properties – and you get server-side prototype pollution: attackers can inject keys that resolve to powerful constructors and runtime primitives.

The React2Shell exploit chain: from prototype pollution to RCE

Several research teams and the original discoverer have documented essentially the same chain.

You can think about it in four steps.

Step 1 – Create a gadget pointing to the Function constructor

The attacker crafts a Flight payload with a reference such as:

• An array stored at position "3": [].

• A server reference that points to $3:constructor:constructor.

Resolution goes:

1. $3 → the array object.

2. .constructor → the Array constructor.

3. .constructor again → the Function constructor.
   
   

Function() in Node.js is essentially eval with a different interface. Once you can invoke Function("code"), you can run arbitrary JS in the server process.

Step 2 – Smuggle code via polluted properties

The payload then:

• Places arbitrary JavaScript code in a field like _prefix.

• Points another property (for example _formData.get) to the Function gadget.

During deserialization, the server trusts these properties and later calls them as if they were safe helpers – but they now point to the Function constructor.

Step 3 – Abuse promise resolution and custom .then()

Flight supports asynchronous values via a $@ notation that signals promises or lazy values. By marking specific chunks as $@3 etc., the attacker forces the server to treat them as promises and call a custom .then() on them.

The polluted object’s .then() eventually triggers the chain that calls the Function gadget with _prefix as the body.

Step 4 – Execute arbitrary server-side code:

The end result at runtime is effectively: Function("malicious_code_here")();executed inside your server’s Node.js process under the same permissions as the app.

Alternative gadget: Node’s vm.runInThisContext

Even if you block or detect Function usage, the same primitive can reach the Node.js vm module:

• Request vm#runInThisContext as the target export.

• The RSC loader imports vm, returns runInThisContext.

• The attacker sends a string payload that runInThisContext executes in the current context.

Why React2Shell exploitation is so reliable

React2Shell is particularly nasty because there is very little “luck” involved:

In practice, this behaves much more like a “Log4Shell-style” bug than a tricky 1-shot exploit: once a scanner finds a vulnerable endpoint, RCE is extremely likely.

React2Shell exploitation in the wild - what we know so far

Timeline and scale

Putting multiple vendors’ telemetry together gives you a realistic picture of how fast things evolved:

Key exposure stats across vendors include:

• 39% of cloud environments observed by Wiz include at least one vulnerable instance.

• Palo Alto Cortex Xpanse has seen >968,000 React/Next.js instances in its attack surface telemetry.

• Shadowserver’s early scans saw tens of thousands of internet-exposed vulnerable IPs, dropping quickly as emergency patching ramped up.

• Censys and other attack surface management vendors report millions of potentially affected services when widening the lens to all frameworks using React 19 RSC.

In-the-wild exploitation and threat intelligence for CVE-2025-55182

Active exploitation began within hours of public disclosure on December 3, 2025. Bleeping Computer writes that Amazon's Sonaris threat detection system and MadPot honeypot infrastructure observed China-nexus threat actors targeting vulnerable systems immediately after the CVE was published.

Identified threat actor groups

China-nexus actors:

• Earth Lamia: Targets financial services, logistics, retail, IT, universities, and government sectors in Latin America, Middle East, and Southeast Asia.

• Jackpot Panda: Focuses on East and Southeast Asian entities, collecting intelligence on domestic security and corruption matters (Bleeping Computer).

• UNC5174 (CL-STA-1015): Initial access broker with suspected ties to China's Ministry of State Security.

Attribution remains challenging because multiple groups share anonymization infrastructure. The majority of ASNs for unattributed activity trace to Chinese infrastructure.

Attack types the community has observed in the wild

Cryptomining deployments:

• UPX-packed XMRig variants

• Scripts from c3pool with Monero wallets

• Persistence via nohup /var/tmp/crond

• Kill commands targeting competing miners

Backdoors and remote access:

• Sliver implants (64-bit ELF binaries) with dedicated TLS C2

• Cobalt Strike beacons

• VShell backdoor for lateral movement

• SNOWLIGHT malware dropper

• MeshAgent remote control software

• Mirai and RondoDox botnet integration

Credential harvesting:

• AWS credentials from environment variables

• Cloud metadata service access (169.254.169.254)

• Scraping of npm, Docker, Git, and SSH keys

Targeting .aws/credentials, .kube, .config/gcloud, and cryptocurrency wallets

Indicators of compromise (IOCs)

Network indicators:

• HTTP POST requests with next-action or rsc-action-id headers

• Request bodies containing $@ patterns

• Request bodies containing "status":"resolved_model" patterns

Malicious infrastructure (partial):

Malicious domains:

• anywherehost[.]site

• inerna1[.]site

• keep.camdvr[.]org (Sliver)

• ax29g9q123.anondns[.]net (Loader)

• tr.earn[.]top (Beacon)

Monero wallet addresses:

42NTfUjbU3Gj536zubU7vpjfC7X9DPECciwbCXrrjBk5KqkJS1Xq4saVgQLP1yqUYHKzn7apt1p3W6mDWm87n3nwDEmWeSh

44VvVLU2Vmja6gTMbhNHAzc7heYTiT7VmQEXkjdaYo6K41WqH8qWw1CL8wKAAgz5xLYT3XL3pb9KCUZS7PPZbzUGCCpZ9Ee

Affected frameworks beyond Next.js

CVE-2025-55182 affects any framework that bundles the vulnerable React Server Components implementation, not only Next.js.

Not affected:

• Client-side-only React apps (no RSC).

• Apps pinned to React ≤18 or 19 without RSC enabled.
  
  

For real-world asset mapping, SBOMs and package-lock scanning are your friends: look specifically for the vulnerable react-server-dom-* versions.

Detection strategies for security teams

React2Shell lands right on top of several recurring pain points: limited testing windows, fragile production stacks, and too many false positives. This section focuses on practical checks you can apply without breaking everything.

Inventory and exposure mapping for CVE-2025-55182

1. Package-level search:

   • Scan package.json + lock files for:

     • react-server-dom-webpack@19.0.0/19.1.0/19.1.1/19.2.0

     • react-server-dom-parcel@…

     • react-server-dom-turbopack@…

   • Include indirect dependencies via SBOM tools (Syft, Trivy, etc.).
     
     

2. Framework & version checks:

   • Identify:

     • Next.js 15.x / 16.x with App Router,

     • Waku, React Router RSC previews,

     • Parcel or Vite RSC plugins,

     • RedwoodSDK, Expo RSC.

   • Confirm the running version from container images or runtime introspection (don’t trust only the repo).
     
     

3. Internet exposure:

   • ASM tools (Censys, Shodan, Pentest-Tools.com, Xpanse, CyCognito) to locate internet-facing Next.js / React RSC endpoints.

   • Internal ASM for staging / “temporary” infra (where dangerous defaults often survive longest).

Network-level detection

Look for:

• Endpoints: POSTs to /_next/, /api/, or RSC-specific paths that carry multipart or JSON Flight payloads.

• Headers: next-action, rsc-action-id, and unusual Content-Type combinations.

Payload markers: $@ tokens, references to constructor, __proto__, prototype, and _response in serialized structures.

For WAFs / IDS:

• Create signatures for common Flight-payload artefacts plus suspicious keys like constructor, __proto__, vm, runInThisContext.

• Rate-limit or block automated requests that trigger repeated HTTP 500s on RSC endpoints.

Log and host-level detection

Application logs:

• Sudden spikes in 500/502 errors on RSC or Next.js App Router endpoints.

• Stack traces referencing Flight, react-server-dom-*, or server action resolution failures.
  
  

System / EDR telemetry:

• New processes spawned by Node.js parents (node, next-server, vite, etc.).

• Shell commands executed shortly after receiving suspicious RSC requests.

• Archive/packers (UPX) and miner signatures in temp directories.
  
  

Cloud audit trails:

• Access to metadata URLs from web app instances.

• Unusual IAM calls following suspected exploitation (e.g., listing keys, creating new roles).

• Storage or secrets manager accesses from IPs / processes not previously seen.

Public scanners and tooling

Several high-quality tools already help you map exposure:

Be cautious with PoCs from random repositories; several have already been caught bundling malware or “extras” you don’t want in your test network.

Detect CVE-2025-55182 with Pentest-Tools.com

From a pentesting or vulnerability management perspective, you also want a way to quickly validate whether your real, deployed targets are vulnerable – not just dev dependencies.

Our team at Pentest-Tools.com provides a dedicated entry in the Vulnerability & Exploit Database for:

React Server Components – Remote Code Execution (CVE-2025-55182), severity: Critical (10.0), with EPSS scoring and scan coverage via our highly accurate Network Vulnerability Scanner.

In practice, you can:

• Run the Network Vulnerability Scanner against your exposed apps to:\

  • Detect vulnerable RSC / Next.js versions, and

  • Confirm whether a payload reaches the Flight reply flow in a way that matches React2Shell.

• Use Sniper: Auto-Exploiter (when available for this CVE) to:

  • Safely validate exploitability in controlled environments,

  • Capture evidence (HTTP traces, screenshots, process listings) for prioritization and reporting.

This helps you prioritize real risk over “theoretical” exposure – especially useful when developers or management push back against emergency changes.

Business impact - the 3 attack scenarios that actually matter

Technical RCE is only half the story. For your clients (or your own org), React2Shell’s major risk lies in what it enables.

Next.js front-end to cloud control plane compromise

Many teams deploy Next.js front-ends that:

• Run in containers or serverless platforms.

• Hold API keys, JWT secrets, database credentials, and cloud roles in environment variables.
  
  

If an attacker exploits React2Shell on such a workload, they can:

• Exfiltrate secrets from env vars and config files.

• Enumerate cloud metadata endpoints for temporary IAM credentials.

• Use those credentials to pivot into:

  • S3 / object storage,

  • Databases,

  • CI/CD systems and artifact registries,

  • Other internal services.

From a business angle, a “front-end bug” becomes a cloud account breach, with impact ranging from data theft to full environment compromise.

The React2Shell blast radius in multi-tenant SaaS companies

If your organization operates a SaaS platform where:

• A handful of shared React/Next.js front-ends serve many tenants, and

• Those front-ends talk to multi-tenant APIs or queues,

…then React2Shell can serve as a tenant-to-tenant pivot.

A single exploited Next.js instance can allow attackers to:

• Extract data belonging to multiple customers.

• Abuse shared credentials or message queues.

• Insert malicious responses into a common microservice that other tenants consume.
  
  

That’s a supply-chain breach: one bug in your stack impacting many customers at once.

Compliance failures, outages, and incident response pain

React2Shell also carries classic “paperwork” problems:

• Regulatory risk: if a compromised app leaks personal data, you may be in violation of GDPR, HIPAA, PCI-DSS, or contractual security requirements (source).

• Operational fallout: emergency WAF rules and patches can themselves be disruptive. Cloudflare, for example, reported a significant outage tied to rushed React2Shell mitigations in their WAF.

• Incident response complexity: untangling “where React2Shell was exploited, which secrets were exposed, and what lateral movement occurred” across microservices and serverless functions is not trivial.

For pentesters, mapping these scenarios explicitly in reports makes it easier for non-technical stakeholders to understand why React2Shell must jump to the top of the backlog.

To justify emergency fixes and maintenance windows, you often need to translate all this technical detail into business impact.

• 39% of environments they scanned had at least one vulnerable instance.

• 69% of environments included Next.js somewhere in the stack.

• 61% of those had public-facing Next.js apps.

• Overall, 44% of all environments had publicly-exposed Next.js apps.

Combine that with the nature of the bug (pre-auth RCE, default configs) and you get a vulnerability that cuts across business sizes and industries.

Third-party attack surface management providers see exposed assets across:

• Media and content platforms (~40% of exposed assets),

• Manufacturing and industrial,

• Professional services,

• Public sector and education,

• Finance, healthcare, retail, and hospitality.

Many of these sectors already operate under strict compliance regimes (PCI DSS, HIPAA, GDPR, sector-specific regs). A pre-auth RCE on an internet-facing app that processes PII or payments is an obvious compliance and reporting nightmare.

Cloudflare’s outage as a risk signal

When a provider like Cloudflare intentionally tightens WAF rules and ends up taking out 28% of their HTTP traffic for 25 minutes, it’s not just a funny war story – it shows how seriously the ecosystem is treating React2Shell.

For your stakeholders, this is a simple narrative:

“Cloudflare was willing to risk a global outage to get ahead of React2Shell. That’s how much they feared automated exploitation. We should be at least as proactive internally.”

Turning emergency into playbook - mitigation summary 

React2Shell is a textbook example of how developer-friendly abstractions can morph into high-impact security issues once they reach production scale. A serialization detail in a UI framework turned into a pre-auth RCE that:

• Cuts across frameworks and cloud providers,

• Can be exploited with a single HTTP request,

• And has already been used in multi-stage attacks by capable threat actors.
  
  

If you’re responsible for pentests, vulnerability management, or securing web stacks built on React and Next.js, this isn’t just “another critical CVE” you can park behind a backlog ticket. It’s an opportunity to:

• Tighten your SBOM and dependency tracking,

• Stress-test your detection pipelines for modern application-layer exploits,

• And demonstrate to stakeholders how quickly coordinated response (patching + WAF + targeted scanning) can reduce real risk.
  
  

Your next steps:

1. Map and patch all RSC / Next.js App Router deployments in your environment.

2. Validate exposure with targeted scanning and controlled exploitation – including the Pentest-Tools.com Network Vulnerability Scanner and Sniper: Auto-Exploiter.

3. Rotate secrets and hunt for IOCs if you had unpatched, internet-exposed React 19 RSC deployments after public disclosure.

4. Capture the story – use React2Shell as a concrete case study to improve your internal playbooks for the next framework-level vulnerability.
   
   

Some attackers have already moved on from React2Shell. The sooner you turn this from an emergency into a closed incident with clear lessons learned, the more resilient your web stack will be for whatever comes next.

Until then, we have your back!