React2Shell CVE-2025-55182 Exploitation update, In-the-Wild Abuse, and the Patch-Again Reality

There are tons of articles that describe CVE-2025-55182 (React2Shell), and we have an analysis of the first attack originally named Freight Night, then followed up on and official name React2Shell. This article focuses on the technical anomalies, how attackers can leverage the vulnerabilities, and how they could combine the follow-on vulnerabilities  (CVE-2025-55184, CVE-2025-67779, CVE-2025-55183).

TL;DR for engineering teams

• What it is: Unauthenticated remote code execution in React Server Components deserialization, tracked as CVE-2025-55182 (React2Shell) with CVSS 10.0.
  
• Where it bites: RSC stacks using the vulnerable packages: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack.
  
• Why it spread quickly: Next.js App Router makes the RSC path widely accessible; defenders saw immediate probing waves after public PoCs circulated.
  
• Patch status (two phases):
  
  • RCE fixed: upgrade to 19.0.1 / 19.1.2 / 19.2.1 for the affected react-server-dom-* packages.
    
  • Follow-ups fixed: upgrade again to 19.0.3 / 19.1.4 / 19.2.3 to cover CVE-2025-55184, CVE-2025-67779, CVE-2025-55183. The interim patch releases were incomplete.

• Duplicate CVE note: CVE-2025-66478 was rejected as a duplicate of CVE-2025-55182. Treat detections as real exposure; it’s the same root cause under a consolidated identifier. 
  
• For Full technical anatomy: https://phoenix.security/react-nextjs-cve-2025-5518/ 
• For Timeline of exploitation: https://phoenix.security/react2shell-cve-2025-55182-explotiation/ 
• Code Scanner:  https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478 
• Web Scanner: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182 
• Exploitation Details: https://phoenix.security/react2shell-cve-2025-55182-explotiation/ 
• Resources: https://phoenix.security/react2shell-resources/ 
• IOC: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182/tree/main/payloads-exploits 

---

Determine if You’re Affected by react2shell CVE-2025-55182

Use this as a fast triage checklist for application security and vulnerability management teams.

1. Do you run React on a server with RSC enabled?
   
   • If you do server-rendered React and RSC is in play, assume yes.
     Search your lockfiles for the vulnerable packages and versions
     – Scan with Phoenix Security Scanner (SCA+SBOM Scanner, or Open Source Scanner), or External Scanner (Phoenix Open Source or Phoenix EASM) 
   • react-server-dom-webpack
     
   • react-server-dom-parcel
     
   • react-server-dom-turbopack
     
2. Confirm whether your framework bundles the server implementation
   
   • Next.js is the obvious one, but RSC-capable stacks and plugins can carry these dependencies indirectly.
     
3. Map exposure
   
   • Identify which services expose RSC-related endpoints externally (this happens automatically with Phoenix-Security)
     
   • Prioritize public-facing workloads, then internal apps reachable from untrusted networks.
     
4. How ASPM can help remediate and identify who owns which vulnerability

• Correlate the vulnerable component to runtime deployments, owners, and routes. If you cannot answer “where is this running,” you are already behind. 
• Attribute the right vulnerability to the right owner 
• Configure a campaign or download one to trace the remediation, prioritize externally exposed systems, and then go to internally exposed systems 

Technical anatomy of react2shell CVE-2025-55182

React Server Components use the Flight protocol to serialize structured data across the client/server boundary. The vulnerable path is the server-side decode step: it accepts attacker-controlled payloads and resolves references in a way that lets a hostile object graph reach runtime primitives that were never meant to be reachable from untrusted input.  

Exploit path in three moves (conceptual)

1. Object-graph injection: the attacker feeds the decoder “chunk-like” structures that resemble internal state and reference each other.
   
2. Thenable coercion: the graph is shaped to trigger Promise-like handling so decoder control flow follows attacker-controlled property resolution.
   
3. Runtime primitive reachability: property resolution reaches a code-construction primitive (the Function constructor class), turning “decoded data” into executable behavior.
   

What to look for in logs (safe, non-PoC)

• Requests that hit Server Functions / Server Actions or RSC endpoints and contain Flight-style reference markers that do not resemble normal app traffic.
  
• Repeated attempts across many hosts sharing the same request template (see the boundary-string pivot in the in-the-wild section).
  

If you want the full gadget-chain mechanics, link out to a deep dive instead of embedding payloads in the post.

React’s advisory calls out the heart of the issue plainly: an attacker can craft a malicious request that, once deserialized, results in unauthenticated RCE, even when the app has no explicit Server Function endpoints, as long as it supports RSC. 

The exploit, being a remote code execution triggers with a minimal payload, below are some examples of attacks (Minimum Viable Exploit)

{ 

  0: {
status: “resolved_model”,
reason: -1,              
_response: {
  _prefix: “console.log(‘RCE’)//”,   
  _formData: { get: “$1:then:constructor” }, 
},
then: “$1:then”,         
value: ‘{“then”:”$B”}’,  
  },
  1: “$@0”,                  
}

Field	Purpose	Junior-Friendly Explanation
status: “resolved_model”	Trigger initialization	“Initialization Trigger”
reason: -1	Prevent crash	Technical workaround to avoid toString() error
_prefix	Malicious code	The actual command that runs on the server
_formData.get	Code execution gadget	Points to Function() so we can create new functions
then	Automatic trigger	Makes JavaScript call our code via await
value	Attack payload	Contains $B which triggers the blob handler
1: “$@0”	Self-reference	Creates the loop that exposes internal objects

There is a significant payload that delivers commands and enables exfiltration left on the servers (sex.sh and variants). 

The attacker’s broader toolset includes this reconnaissance command for target identification, separate from the post-exploitation dropper, sex.sh.”

MD5: ddbbd528c3d0bcdd39617676c85dde33
Active Since: 15th October 2025
IP: 209.141.49.251

Commands

waybackurls $1 | grep “_next/static” | cut -d “/” -f1,2,3 | sort -u | uniq | tee -a next_target.txt

Core behaviours

What the exploit needs

• A reachable endpoint that triggers RSC/Server Function decode logic (framework-managed or custom).
  
• A vulnerable react-server-dom-* package version in the 19.x line listed below.
  

What the exploit does

• Forces the decoder to resolve a chain of attacker-controlled references.
  
• The chain is engineered so that a “getter” becomes a call into Function(…), with the payload providing the JavaScript source to compile and run.
  

Why is the impact maximal

Once arbitrary JavaScript runs inside the Node.js server process, it inherits whatever that process can reach:

• environment variables
  
• filesystem secrets and configs
  
• cloud metadata endpoints
  
• outbound network access to call home or stage tooling
  

Wiz and AWS both documented real post-exploitation that matches that reality: credential harvesting, metadata access attempts, and persistent backdoors in cloud workloads. 

---

Affected Versions

React packages (CVE-2025-55182 RCE)

Vulnerable versions include 19.0, 19.1.0, 19.1.1, 19.2.0 for:

• react-server-dom-webpack
  
• react-server-dom-parcel
  
• react-server-dom-turbopack
  

RCE fixes were introduced in:

• 19.0.1
  
• 19.1.2
  
• 19.2.1
  

Next.js downstream impact

Next.js is impacted when it reaches the vulnerable RSC flow (notably App Router lines referenced in vendor advisories). 

Independent advisory tracking also notes Next.js 13.x / 14.x stable and Pages Router are not affected by the RCE path. 

Scale and install base

This landed hard because React and Next.js sit on a massive distribution base: tens of millions of weekly npm downloads for each were cited in public reporting. Visibility studies also found vulnerable React/Next.js versions present in a large share of cloud environments under observation.

Other Vulnerabilities

In case you missed patching React components,you’re in “luck” there are more vulnerabilities being disclosed.  The ecosystem got hit with follow-ups right after the RCE fire drill.

• CVE-2025-55184 (High, CVSS 7.5): Denial of Service (reported by RyotaK)
  
• CVE-2025-67779 (High, CVSS 7.5): Denial of Service variant; the first DoS fix missed an edge case (found internally by the React team)
  
• CVE-2025-55183 (Medium, CVSS 5.3): Source code exposure of Server Functions (reported by Andrew MacPherson)
  

React’s follow-up post is blunt on the operational reality: earlier patches are vulnerable, and fixes were backported to 19.0.3 / 19.1.4 / 19.2.3. 

This is a familiar pattern for high-profile issues: once the code path is under a microscope, variants show up fast. React explicitly points to the Log4Shell follow-up wave as the same phenomenon.

Campaign to identify if your libraries are affected by the react2shell CVE-2025-55182, CVE-2025-66478 in Phoenix security ASPM

Leverage the Phoenix Security SCA Scanner to identify the vulnerability blast radius 

Scan with the Git automatic scanner or pull the repo individually (finding can be synced to Phoenix using –enable-phoenix and modifying the config:

• Code Scanner: https://github.com/Security-Phoenix-demo/react2shell-scanner-rce-react-next-CVE-2025-55182-CVE-2025-66478 
• Web scanner and test lab: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182 
• Download Phoenix Security Campaign

Leverage Phoenix Security Filters and the campaign method to update/ retrieve the new vulnerabilities, or import those two files

Check the libraries not affected in the SBOM screen to detect React2Shell (search the following libraries) for CVE-2025-55182, CVE-2025-66478, CVE-2025-55184, CVE-2025-67779, CVE-2025-55183

• React-server-dom-webpack
• webpack
• React-server-dom-parcel
• parcel
• React-server-dom-turbopack
• Turbopack
• react-router
• Next.js
• plugin-rsc
• Waku
• Rwsdk
• rsc
  

Check Vulnerability Screen in Phoenix Security

How threat actors are using CVE-2025-55182 and follow-on variants in an attack 

Attackers don’t need creativity here. They need throughput. And they are collecting evidence of vulnerable system in the following way:

Phase 1: Internet discovery and validation

A crafted request hits the RSC decode surface and yields code execution inside the Node.js process that serves your app. React categorizes this as unauthenticated RCE with maximum severity.  

Phase 2: Initial access inside the app runtime

Once the payload runs, the attacker has a shell-equivalent foothold in the Node process context. AWS and Wiz both observed early-stage commands used for identity, environment, and filesystem discovery in cloud workloads. 

Phase 3: Credential harvesting and cloud pivoting

Attackers harvest:

• env secrets and tokens
  
• cloud credentials via instance metadata access
  
• SSH keys and developer tooling credentials
  
  Then they upload results in bulk to attacker infrastructure. 
  Wiz documented campaigns explicitly targeting this data after exploitation.
  

Phase 4: Monetization or persistence

Observed outcomes include:

• cryptominers dropped into containers and servers
  
• reverse tunnels and backdoors for longer-term control
  
• Sliver implants in more advanced intrusions 
  
  

Phase 5: Variant pressure after patching

Even after you shut down the RCE class, the follow-ups keep the same exposed surface relevant:

• DoS requests that hang the server in a loop and burn CPU 

Crafted requests that cause server functions to return compiled source of other functions, risking exposure of hardcoded secrets and business logic. 

Which threat actors are using CVE-2025-55182 for active exploitation

China-nexus activity (espionage and access tooling)

Google intelligence has identified multiple China-nexus clusters exploiting CVE-2025-55182 globally as of Dec 12, and cites AWS reporting that Earth Lamia and Jackpot Panda are exploiting the bug (GTIG tracks Earth Lamia as UNC5454). 

Key clusters and payload families GTIG calls out:

• UNC6600 → MINOCAT tunneler
  
  Google intelligence observed behavior centers on stealthy foothold hardening: creation of a hidden working directory (for example, $HOME/.systemd-utils), process tampering (killing ntpclient), then persistence via cron, systemd, and shell-profile execution hooks so the tunneler re-launches when a new shell starts. MINOCAT is a Linux ELF with an embedded FRP client used for tunneling.
  
• UNC6586 → SNOWLIGHT downloader (VSHELL ecosystem)
  
  Google intelligence observed retrieval of SNOWLIGHT followed by HTTP GET traffic to C2 and staging infrastructure, including reactcdn.windowserrorapis[.]com as an example domain. Treat this as a clean hunting pivot for outbound connections from a web-server context.
  
• UNC6588 → COMPOOD backdoor
  
  Google intelligence observed COMPOOD being downloaded and executed in a way that masquerades as a legitimate binary (example: “vim” naming). GTIG did not observe heavy follow-on in those incidents, and the motivation remains unclear.
  
• UNC6603 → HISONIC backdoor (cloud-service blending)
  
  Google intelligence reports HISONIC retrieving encrypted configuration via legitimate cloud services (Cloudflare Pages, GitLab) to blend into expected traffic. They also note marker strings delimiting an XOR-encoded config blob and targeting focus on AWS and Alibaba Cloud in APAC.
  

Financially motivated activity (throughput first, mining second)

GTIG observed multiple incidents starting Dec 5 where actors used CVE-2025-55182 to deploy XMRig for illicit cryptomining. One observed chain downloads a script named sex.sh, pulls XMRig from GitHub, then adds persistence via a systemd service named system-update-service. 

Operational takeaway: even if you patch quickly, treat “unexpected miner symptoms” (CPU spikes, new system services, outbound pool traffic) as a compromise triage trigger, not as an infra hiccup.

Defender notes: what to hunt for (actionable without handing attackers a recipe)

• Outbound web-server initiated fetches (wget/curl behavior) to known staging/C2 IOCs and newly registered lookalike domains.
  
• Filesystem and persistence artifacts: hidden working directories, unexpected cron entries, new systemd units tied to the web workload user, shell-profile modifications.
  

Tunneling and proxy tooling (FRP-style behavior) and reverse proxy patterns in egress logs.  

Evidence of exploitation 

A researcher under the name of Krishnan has identified a treasure trove of targets that are being collected for further exploitation

• Exploited Victims: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182/blob/main/payloads-exploits/CVE-2025-55182%20react2shell%20iocs%20victim%20ip_enriched.csv
• Victim Domains: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182/blob/main/payloads-exploits/CVE-2025-55182%20react2shell%20iocs%20victim%20domains.csv 
• Targeted Next Domains: https://github.com/Security-Phoenix-demo/react2shell-scanner-CVE-2025-55182/blob/main/payloads-exploits/CVE-2025-55182%20react2shell%20iocs%20victim%20domains.csv 

1) “Open dir” staging looks like pre-ops for mass exploitation

Krishnan found an exposed directory hosting React2Shell tooling and target material: a YAML PoC file, domain lists, and scripts, all sitting in the open. Inside it, two files stand out: a “Domains” list with 35,423 domains, and a “Next Target” list with 596 URLs that include well-known brands. Treat that list as intent, not proof of compromise. It still tells you what attackers think is worth scanning at scale. 

Even better: one of the scripts uses a Wayback Machine harvesting one-liner to fingerprint Next.js by searching for /_next/static paths, then writing candidates into a next_target.txt style list. That’s not sophisticated, it’s efficient, and it scales. 

2) A reusable multipart boundary string is showing up as a “campaign fingerprint.”

One detail is unusually operational: the boundary string WebKitFormBoundaryx8jO2oVc6SWP3Sad appears inside the YAML PoC and then shows up across large numbers of hosts in external search results (FOFA and Censys results in the post). A normal browser generates fresh boundaries; a hardcoded boundary points to automation and replay. Krishnan reports seeing it across 708 unique hosts in FOFA results and notes a pattern where many identified victims advertise Server: ZK Web Server. 

Translation for defenders: even when payload shapes evolve, lazy operators keep reusing “working” request templates. That boundary is a clean hunting pivot in WAF, reverse proxy, and application logs.

3) Post-exploitation is frequently crypto-mining, delivered by a familiar script name

Krishnan tracks a recurring file name, sex.sh, tied to cryptomining deployments (XMRig) alongside React2Shell activity. The post lists multiple IPs hosting that script and provides one sample hash and timeline details. 

This lines up with broader reporting that active React2Shell exploitation has been used to deliver XMRig, with sex.sh specifically called out as a Bash script that pulls XMRig 6.24.0 and sets up persistence via a systemd service. 

Practical IOCs you can operationalize today

Use these as detection pivots, not as a checklist to “block one string and declare victory”:

• Inbound: multipart/form-data requests carrying boundary WebKitFormBoundaryx8jO2oVc6SWP3Sad in proximity to Server Actions / RSC endpoints.
  
• Hunting pivot: repeat appearances of that exact boundary across unrelated requests (high confidence automation).
  
• Recon artifact: requests and tooling patterns that enumerate /_next/static paths (candidate Next.js discovery).
  
• Host signals: presence of sex.sh style droppers, XMRig fetches, and suspicious systemd service persistence patterns consistent with miner deployment. 
  

Exploited and exploitable: internet-scale exposure signals react2shell CVE-2025-55182

React System in Shodan	Next.js systems in Shodan
From The Shadowserver Foundation: More than 120,725 internet-exposed IP addresses are running vulnerable code as of December 11, 2025. Of these, over 82,100 instances are located in the U.S., followed by Germany (8.8K), France (4.5K) and more
Fastly Increase exploitation from 9M on December 4 2026

We are tracking the incident write-ups that describe rapid PoC churn and active exploitation attempts shortly after disclosure. 

Attack surface counts (as reported in the provided campaign analysis):

• React systems in Shodan: 584,086
• Next.js technologies in Shodan: 754,139 
• Fastly Detection of attacks on the 5th 
• Datadog has provided detailed exploitation IoC tracking the various exploit-poc

Datadog  detection of the exploit activity after PoC on the 5th December disclosure

Graynoise and Cloudflare saw continuous probing and a surge of detections. Cloudflare, which is also tracking ongoing exploitation activity, said threat actors have conducted searches using internet-wide scanning and asset discovery platforms to find exposed systems running React and Next.js applications.

Datadog Exploitation over time of PoC	Cloudflare exploitation over time
Graynoise Exploitation over time with increase from Dec 04

How Phoenix Security angle can help in this multi-stage attack: catching the attack and the owner at the same time

This is where ASPM stops being a dashboard and becomes a response tool.

Phoenix Security can connect the dots across:

• External Attack Surface
  
  Identify internet-exposed applications and endpoints that match RSC/Next.js patterns, then track exposure drift (new subdomains, new routes, new gateways). When React2Shell scanning ramps up, leveraging the External Attack surface (signatures for the CVE-2025-55182 are already available)
  
• Correlation across runtime exposure, packages, and code
  
  React2Shell is not “a React problem.” It’s a reachable deserialization path plus a specific react-server-dom-* dependency version. Correlation means you can answer fast:
  
  • Which exposed apps route traffic into Server Actions/RSC decode
    
  • Which repos actually pull the vulnerable libraries
    
  • Which builds and deployments still carry those versions

Phoenix Security Correlate your external attack surface with internal applications and react to applications that are vulnerable. Phoenix Security also deduplicates code and cloud to enable you to focus on the vulnerabilities that really matter and where they should be fixed.

• Code scanning and library lineage
  Pinpoint the exact dependency chain that introduced react-server-dom-webpack (direct, transitive, monorepo hoist, framework peer dep). Pair that with where it runs: cluster, namespace, service, ingress, or domain.
  
• Attribution and ownership
  The fix is simple on paper: upgrade and redeploy. The failure mode is human: “nobody owns the frontend runtime.” Attribution ties the vulnerable runtime surface back to the team and the repo that can ship the patch. That keeps React2Shell from becoming a week-long blame relay.
  
• Exploitation-aware prioritization
  
  When active campaigns are public and growing (scanners, miners, backdoors), a critical RCE on an exposed RSC stack is not a backlog item. It’s a production incident until proven otherwise. Public intel on in-the-wild exploitation, plus your own exposure evidence, is how you justify the escalation. 

• New Phoenix Security Automatic Remediation: With prioritization and attribution Phoenix Security also proposes the remediation (upgrades) that maximize achieving a safe environment directly in your code

Phoenix Security Remediation screen helps you to focus on the remediation that matters in the asset that needs the specific fix (build file, library or base image).

---

Discovery and Disclosure Timeline

• Nov 29, 2025: vulnerability reported to the React team.
  
• Dec 3, 2025: React publishes the critical advisory and fixes for CVE-2025-55182.
  
• Dec 11, 2025: React publishes follow-up advisory covering CVE-2025-55184, CVE-2025-67779, CVE-2025-55183 and states that earlier follow-up patch releases were incomplete.
  
• Dec 11, 2025: Next.js publishes its security update aligned to the follow-up CVEs.
  
• Dec 12, 2025: Raven File documents open-directory staging and targeting workflows connected to in-the-wild activity.  

---

Temporary Protections

Patching is the fix. Temporary protections buy minutes and hours.

• WAF rules and managed protections
  
  Multiple providers shipped emergency detections and managed rules while patching rolled out; AWS also documented managed rule updates and interim WAF guidance. 
• Full list of WAF rules: https://phoenix.security/react2shell-resources/
  
• Rate limiting and burst control on Server Action/RSC endpoints
  
  This matters even more after the DoS CVEs; the follow-up DoS hangs server processes by driving the vulnerable deserialization into an infinite loop.
  
• Segmentation of build and runtime secrets
  
  Wiz observed broad secret harvesting and metadata access attempts after initial code execution. Reduce what the frontend runtime can reach.
  

Hunt and verify

AWS published concrete indicators: suspicious headers, $@ markers, resolved_model patterns, unexpected command execution patterns, and file activity driven by Node/React processes.

Reference Links

https://securitylabs.datadoghq.com/articles/cve-2025-55182-react2shell-remote-code-execution-react-server-components

https://www.fastly.com/blog/fastlys-proactive-protection-critical-react-rce-cve-2025-55182

https://www.greynoise.io/blog/cve-2025-55182-react2shell-opportunistic-exploitation-in-the-wild-what-the-greynoise-observation-grid-is-seeing-so-far

https://vercel.com/kb/bulletin/security-bulletin-cve-2025-55184-and-cve-2025-55183

https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

https://nextjs.org/blog/CVE-2025-66478
https://x.com/stdoutput
https://x.com/stdoutput/status/199669…
https://github.com/msanft/CVE-2025-55182
https://x.com/maple3142
https://x.com/maple3142/status/199668…
https://gist.github.com/maple3142/48b…
https://github.com/facebook/react/sec…
https://x.com/swithak/status/19965841…
https://gist.github.com/SwitHak/53766…
https://github.com/assetnote/react2sh…
https://slcyber.io/research-center/hi…
https://gist.github.com/joe-desimone/…
https://x.com/rauchg/status/199670143…

How Phoenix Security Can Help

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis and an innovative Threat Centric approach. This innovative approach correlates runtime data with code analysis and leverages the threats that are more likely to lead to zero day attacks and ransomware to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerability’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.