
Intro
CVE-2025-55182 (“React2Shell”) is a maximum-severity, unauthenticated remote code execution (RCE) issue impacting React Server Components (RSC). Multiple security outlets are warning that exploitation is expected quickly once defenders fall behind on patching, especially for internet-facing Next.js/React deployments.
📌 CVE Context
– Products & versions affected
React RSC server packages including react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack across React versions 19.0, 19.1.0, 19.1.1, and 19.2.0. It also impacts dependent ecosystems such as Next.js deployments using RSC/Flight paths in typical configurations.
– Disclosure timeline
Public disclosure and vendor guidance landed in early December 2025, with patched releases available as 19.0.1, 19.1.2, and 19.2.1.
– Attack vector, auth level, impact
Network-accessible attack surface, no authentication required. The bug resides in React Server Components “Flight” protocol handling, enabling arbitrary server-side code execution when a vulnerable endpoint processes attacker-crafted content.
CVSS Metric Breakdown (v4.0) - CVE-2025-55182 (React2Shell: Unauthenticated RCE in React Server Components/Flight handling)
Attack Vector (AV): Network (N)
Attack Complexity (AC): Low (L)
Privileges Required (PR): None (N)
User Interaction (UI): None (N)
Confidentiality Impact (VC): High (H)
Integrity Impact (VI): High (H)
Availability Impact (VA): High (H)
Scope Changed (SC): Unchanged (N)
Safety Impact (SI): None (N)
Automation (SA): High (H)
Exploit Maturity: Proof-of-concept exists / exploitation expected
Base Score: 10.0 (Critical)
– Exploit tools, payloads observed, confirmed victims, global exposure count if known
Public reporting indicates rapid community attention and expectation of exploitation. Cloud exposure analysis cited by reporting suggests a large portion of cloud environments may have vulnerable React/Next.js footprints (often quoted around ~39% in coverage), meaning this is not a niche edge case.
🎯 EPSS Scoring
EPSS for CVE-2025-55182 is 0.00455 (about 0.46% probability of exploitation in the next 30 days) with a percentile of 0.63035. Translation: EPSS is not currently screaming “guaranteed mass exploitation,” but it also isn’t bottom-of-the-barrel. Combine this with CVSS 10.0, public attention, and your real exposure (internet-facing RSC endpoints) and you still treat this as a patch-now issue.
🔬 Exploitation Detail
– Step-by-step breakdown
1) Attacker identifies an application exposing React Server Components / Flight endpoints (often via Next.js and related stacks).
2) Attacker sends a crafted request that triggers unsafe server-side processing in the RSC Flight protocol implementation.
3) The vulnerable server-side runtime processes attacker-controlled input in a way that results in code execution in the server context.
– Where it lives (heap, parser, macro, etc.)
This sits in server-side request handling and serialization/deserialization logic tied to React Server Components “Flight” protocol processing (application-layer parsing and object handling).
[Sample request shape — illustrative, not a working exploit]
POST /_rsc HTTP/1.1
Host: example.org
Content-Type: application/json
{ "flight": "attacker-controlled-structure", "note": "crafted to abuse server-side processing" }
📎 Attacker Behavior Snapshot
– What the attacker sends
Repeated probing POSTs to RSC/Flight endpoints (commonly /_rsc variants) with unusual payload structures or unexpected content-types for that route.
– What the system does
Parses and processes RSC/Flight data server-side; in vulnerable builds the parsing/processing path can be abused to run attacker-supplied code under the app’s server privileges.
– What leaks back (tokens, stack traces, paths)
Early-stage attempts may produce verbose server errors (stack traces, module paths, runtime banners). Successful exploitation can enable data access, secrets collection, and command output via follow-on actions.
🧩 Why This Matters
This vulnerability highlights how legacy configurations become high-value targets. In practice, “default” server features (like RSC endpoint exposure) become attacker gold when they’re network reachable and tied to complex parsing logic.
Exploitation results in:
– Full command execution on web servers
– Untraceable persistence via web shells or backdoored server modules
– Rapid lateral movement if not detected early
🧩 MITRE ATT&CK Mapping
Initial Access: T1190 – Exploit Public-Facing Application
Execution: T1059.003 – Command Shell
Persistence: T1505.003 – Server Software Component
🧪 Detection Rules
YARA Rule (Memory/Doc/PCAP)
rule CVE_2025_55182_React2Shell_Suspected_Indicators
{
meta:
description = "Heuristic indicators related to React2Shell (CVE-2025-55182) investigations"
author = "SOC/DFIR"
strings:
$p1 = "react-server-dom-webpack" nocase
$p2 = "react-server-dom-turbopack" nocase
$p3 = "react-server-dom-parcel" nocase
$p4 = "Flight" nocase
$p5 = "/_rsc" ascii
condition:
2 of ($p*)
}
Suricata or Zeek (Network)
alert http any any -> any any (msg:"CVE-2025-55182 possible React2Shell probing (RSC endpoint POST)"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/_rsc"; nocase; sid:202555182; rev:1;)
Sigma Rule (SIEM/EDR)
title: Possible React2Shell (CVE-2025-55182) Probing via RSC Endpoint
id: 2b5f4b0a-5518-4282-9d77-202555182001
status: experimental
logsource:
category: webserver
detection:
selection:
cs-method: POST
cs-uri-stem|contains: "/_rsc"
condition: selection
level: high
🔎 Detection Strategies
✅ Network Detection:
– Monitor for repeated HTTP POSTs to RSC/Flight endpoints (commonly /_rsc patterns).
– Flag unusual request bodies to RSC routes (unexpected content types, abnormal sizes, high-entropy blobs, or payloads that don’t match baseline traffic).
– Alert on spikes: single source IP hitting multiple RSC endpoints across hosts (spray-and-pray scanning).
✅ Endpoint Detection:
– Node.js (or the app server process) spawning abnormal child processes or making suspicious outbound connections.
– Unexpected file writes in application directories (new .js/.mjs files, changed server bundles, altered node_modules in production).
– Sudden environment variable access patterns (process reads secrets at unusual times) and new scheduled persistence mechanisms.
⚡ Splunk Query
index=web* sourcetype=*access* OR sourcetype=*nginx* OR sourcetype=*apache*
(method=POST OR http_method=POST)
(uri_path="*/_rsc*" OR url="*/_rsc*")
| stats count min(_time) as first_seen max(_time) as last_seen values(useragent) as useragents by src, dest, host, uri_path
| where count >= 3
🛠️ SOC Detection Strategy
– Triage levels, log sources, alert logic
Treat RSC endpoint POST anomalies as high priority when the destination is internet-facing. Primary log sources: reverse proxy/WAF logs, web access logs, application error logs, runtime telemetry, EDR process + file events.
– How to tune and escalate
Tune by baseline: which apps legitimately receive POST traffic to RSC endpoints and from where. Escalate immediately if you see: repeated POSTs + server errors + new file writes + abnormal outbound traffic.
– What real-world alerts might look like
“Spike in POST /_rsc from single ASN + 5xx responses + Node process abnormal child activity” is a practical composite signal for escalation.
🛠️ Tools & Techniques
Tool | Usage
Sysmon | Detect parent-child anomalies (server runtime spawning shells/tools)
Velociraptor | Endpoint hunting for suspicious process trees and file writes
Zeek | HTTP logging, URI patterns, anomaly detection for RSC endpoints
Sigma/YARA | Detection rules for suspicious artifacts and investigation pivots
🛡️ Mitigation & Response
– Patch info
Upgrade React to patched releases: 19.0.1, 19.1.2, or 19.2.1 (and ensure downstream frameworks pull the fixed dependency chain).
– Temporary mitigations (GPOs, ACLs, WAF)
If you cannot patch immediately: restrict access to RSC endpoints (IP allowlists, auth gating, internal-only), add WAF rules to rate-limit and block anomalous POSTs to /_rsc, and reduce verbose error output in production.
– Config changes, credential rotation, MFA enforcement, registry edits
Rotate secrets (API keys, DB creds) if exploitation is suspected. Enforce least-privilege for app runtime service accounts. Ensure MFA for admin panels and CI/CD. Validate build integrity and lock dependency versions to patched releases.
– Monitor for lateral movement post-compromise
Add targeted detections for new outbound connections, new service accounts, suspicious tokens usage, and unusual internal scanning from the web tier.
📋 Incident Response Snippets
– Log queries (grep, Splunk, KQL)
Hunt for POSTs to /_rsc, surges in 5xx around those routes, and correlated EDR alerts (new files, abnormal child processes, outbound beacons).
– IR questions to ask
Is the host internet-facing? Which React/Next.js build is deployed? Are patched versions deployed everywhere? Any unexplained deploys, dependency refreshes, or container rebuilds? Any new outbound traffic destinations from app servers?
– Cleanup and movement checks
Rebuild from known-good source, redeploy clean images, diff app directories vs golden baseline, rotate secrets, revoke tokens, and inspect CI/CD for tampering.
📚 Suggested Reading & External References
– Vendor advisory and patched versions coverage (CVE-2025-55182 / React2Shell)
– SecurityWeek reporting on expected exploitation and impacted versions
– The Hacker News coverage on React Server Components RCE
– BleepingComputer write-up highlighting Flight protocol attack surface
– CISA KEV catalog (check if it gets added for confirmed exploitation)
🗾️ Final Thoughts
Exploit path: hit an exposed RSC/Flight endpoint with crafted input → trigger unsafe server-side processing → gain server-side execution. The most effective action to take now is patch to the fixed React versions and hunt for /_rsc POST anomalies in your logs. Detection is field work.
Published: 2025-12-04
Leave a comment