React2Shell (CVE-2025-55182) is a critical RCE vulnerability in React Server Components (RSC) that allows attackers to deliver malicious Flight payloads and gain unauthenticated code execution on vulnerable servers. Any application running React 19.x with Server Components—including frameworks like Next.js (App Router), Vite RSC, Waku, or custom SSR setups—is exposed, making this one of the most impactful issues in the React ecosystem since Log4Shell.
While several RSC-related vulnerabilities surfaced around the same time, including the Next.js App Router issue (CVE-2025-66478), React2Shell remains the core upstream flaw and the primary vector seen in real-world exploitation. Framework-specific bugs may widen exposure, but they are not required for attackers to successfully compromise systems.
The severity of the flaw became apparent almost instantly—not only because of its zero-auth RCE potential, but also because Cloudflare reported service instability tied to emergency mitigations deployed in response to the vulnerability. When a core internet provider feels the impact of a React exploit, the rest of the ecosystem takes notice.
CVE Summary
With CVE-2025-55182 now listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog and actively exploited across the internet, organizations should treat any unpatched RSC-enabled environment as being at significant risk of compromise.
CVSS & Impact Summary
| CVSS Score | Severity | Version | Vector String |
|---|---|---|---|
| 10.0 | Critical | 3.1 | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
Affected Products
| Package | Library | Vulnerable Versions | Patched Versions |
|---|---|---|---|
| React | react-server-dom-parcel, react-server-dom-webpack, react-server-dom-turbopack |
19.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
React2Shell is not a theoretical risk or a niche research flaw—it moved straight into active exploitation within days of disclosure. The entire attack chain became public almost immediately, dramatically accelerating the threat landscape.
Multiple proof-of-concept exploits appeared immediatley, and they continue to surface “like mushrooms,” each demonstrating slightly different ways to trigger the RCE condition. Some rely on malformed Flight payload sequencing, others use variant chunk structures, and several implement automated exploitation flows. A Metasploit module quickly followed, along with numerous GitHub scripts and high-fidelity scanners released by security vendors. This rapid and diverse tooling ecosystem has made it trivial for attackers—and defenders—to probe for vulnerable RSC endpoints at scale.
The scale of exposure quickly became clear.
Early measurements by the Shadowserver Foundation reported 77,664 internet-exposed IPs vulnerable to the React Server Components RCE (CVE-2025-55182), based on scanning methodology published by Assetnote as of December 5. Around the same time, Palo Alto confirmed that more than 30 organizations across multiple sectors had already been compromised, underscoring how quickly attackers moved to exploit the flaw. Together, these findings highlight one of the largest and fastest-forming attack surfaces seen in a modern web framework vulnerability.
Nation-state activity rapidly entered the picture.
AWS’ MadPot telemetry observed China-linked threat groups—specifically “Earth Lamia” and “Jackpot Panda”—actively exploiting React2Shell within hours of public disclosure. Additional reporting from multiple outlets, including The Hacker News and SecurityWeek, corroborated widespread exploitation by state-aligned actors, clearly signaling that this vulnerability had moved into high-value targeting campaigns.
Regulatory confirmation followed shortly after.
CISA officially added CVE-2025-55182 to its Known Exploited Vulnerabilities (KEV) catalog, mandating patching across federal and critical infrastructure environments and formally acknowledging ongoing exploitation in the wild.
Even Cloudflare acknowledged that emergency mitigations deployed in response to this vulnerability contributed to service instability, highlighting how React2Shell forced rapid defensive actions across the internet’s core infrastructure. Together, the combination of a CVSS 10.0 RCE, immediate PoC availability, widespread internet exposure, active nation-state exploitation, and KEV inclusion places React2Shell firmly in “assume breach” territory for any unpatched RSC-enabled deployment.
At Logpoint, we have closely monitored the evolution of React2Shell and the broader exploitation activity surrounding RSC-based attacks. While the initial access vector in this case is tied to the React Server Components vulnerability, the subsequent attack phases—such as establishing persistence, impairing defenses, moving laterally, and attempting impact—follow patterns consistent with many other web-to-shell intrusions. Customers using Logpoint SIEM already benefit from detection coverage and behavioral analytics that align with these post-exploitation techniques, enabling faster identification and response as threat actors exploit React2Shell in the wild.
Windows
Process creation with command-line auditing should be enabled
Registry Auditing should be enabled
Windows Sysmon
To get started, you can use our sysmon baseline configuration.
IDS, IPS & WAF
Once the vulnerability is exploited, adversaries typically begin with lightweight reconnaissance or spawn downstream processes to prepare and run their payload. For threat hunters, the most reliable early signal is abnormal child process activity—especially processes launched with suspicious command-line arguments. The following query lists the overall child processes spawned by the Node.
From the query results, analysts can drill into the child processes spawned by node.exe. This initial hunt is intentionally broad—it surfaces any child process activity for further inspection. If the results show suspicious or unexpected processes being launched by node.exe, analysts can pivot into those events and use Logpoint’s process tree view to investigate the full parent–child relationship. This helps confirm whether the activity aligns with normal application behavior or indicates post-exploitation actions.
In addition to process-based hunting, analysts should verify whether any systems in the environment have communicated with known malicious IPs or infrastructure linked to scanning or exploiting this vulnerability. Reviewing inbound and outbound network logs for these IOCs can reveal early reconnaissance attempts or signs of successful exploitation. To support this, you can compile a list of malicious IPs from your TI source or shared by the community —such as from Datadog, GreyNoise, or other threat intelligence reports—and use them directly for IOC-based searches, as demonstrated in the example query below:
In addition to the hunting queries provided above, the following Logpoint alerts are strongly recommended for detecting a wide range of post-exploitation techniques commonly observed following React2Shell compromise scenarios. These alerts are not specific to React2Shell—rather, they are designed to capture behaviors frequently used across many threat actors once initial access is gained. Enabling these alerts will significantly improve visibility and accelerate response during similar web-to-shell intrusions.
Usage of Web Request Command
Detects execution of binaries or command-line tools used to perform web requests or file downloads, such as wget, curl, or PowerShell web request cmdlets.
Suspicious PowerShell Parameter Substring Detected
Detects PowerShell execution containing suspicious or high-risk parameters commonly leveraged by threat actors and malware, including those observed in the process tree above.
Reconnaissance Using Windows Binaries Detected
Detects the use of built-in Windows utilities typically abused for reconnaissance activities, such as gathering system, network, or domain information.
File Dropped in Suspicious Location
Detects events where files are created or downloaded into directories frequently misused by threat actors or malware for staging, execution, or persistence.
Process Execution from Suspicious Location
Detects processes launched from directories known to be abused for malicious activity, often used by threat actors to bypass controls or evade traditional monitoring.
Firewall Disabled via Netsh Detected
Detects attempts to disable or modify the Windows Firewall using netsh.exe.
Microsoft Defender Disabling Attempt via PowerShell
Flags suspicious PowerShell script blocks attempting to disable Microsoft Defender.
Suspicious Windows Defender Registry Keys Modification
Monitors sensitive registry changes that could weaken or disable Defender protections.
Process Execution from Suspicious Location
Detects when executables are run from commonly abused locations like C:\ProgramData.
Windows User Account Created or Removed
Detects creation or deletion of local or domain user accounts (Event ID 4720).
Windows User Added or Removed from Group
Identifies when users are added to or removed from privileged groups (Event ID 4728).
Browser Credential Files Accessed
Flags access to browser credential stores, such as Chrome or Edge login data files.
File Dropped in Suspicious Location
Detects when files are created in directories frequently abused by attackers, including C:\ProgramData.
Suspicious Eventlog Clear or Configuration Using Wevtutil Detected
Detects when event logs are cleared via wevtutil.exe
Possible Modification of Boot Configuration
Detects when boot configurations are modified to prevent recovery and safe mode boot.
High Number of Process Terminations
Detects when a high number of processes are terminated—commonly observed as a preparatory step before ransomware deployment to reduce errors and interference.
Suspicious Scheduled Task Creation
Detects the creation of suspicious scheduled tasks commonly used by adversaries to maintain persistence or trigger payload execution.
Autorun Keys Modification Detected
Detects modifications to registry keys responsible for launching applications during system startup—often leveraged for persistence.
1. Patch Immediately and Verify Exposure
Upgrade React and RSC packages to the patched versions (19.0.1, 19.1.2, 19.2.1) across all environments.
Update frameworks that bundle RSC logic (e.g., Next.js App Router, Vite RSC, Waku) to their fixed builds.
Identify all workloads running vulnerable RSC versions—serverless functions, container images, monoliths, and edge deployments—and rebuild from patched images.
End existing Node.js or Next.js processes after patching to flush malicious state or in-memory implants.
2. Reduce Attack Surface for RSC Endpoints
Restrict access to public-facing RSC/Flight endpoints using IP allowlists or API gateways where possible.
Disable unused RSC features or experimental flags not required by the application.
Avoid exposing server-rendered component endpoints directly to the internet without WAF inspection or rate-limiting.
Ensure reverse proxies (NGINX, HAProxy, ALB/ELB) enforce strict request-size limits and drop malformed or oversized POST bodies.
3. Strengthen Credential & Secrets Hygiene
Rotate all environment variables containing secrets (.env files), API keys, database passwords, or cloud tokens.
Reissue JWT signing keys, session secrets, or OAuth client secrets stored within application configs.
Rotate IAM credentials for service roles attached to compromised hosts or containers.
Enforce MFA and remove unused accounts from cloud control planes.
4. Enhance Logging, Telemetry & Runtime Visibility
Enable detailed process, file, and network telemetry for Node.js workloads (Sysmon for Linux, eBPF, EDR agents).
Ensure logging includes:
Process execution (especially shells spawned by Node.js)
File creation in /tmp, /dev/shm, and application directories
Outbound connections from Node.js to unknown hosts
Access to cloud metadata services (AWS/Azure IMDS)
Enable full application logs where feasible, focusing on error traces, unexpected serialization failures, and abnormal Flight responses.
5. Strengthen Environment & Deployment Security
Rebuild compromised workloads from clean images, not from modified hosts.
Implement least-privilege IAM roles for application services.
Use runtime restrictions (seccomp, SELinux/AppArmor, container isolation) to limit what Node.js can execute.
Harden systems by removing unnecessary OS tools or enforcing application control on high-risk utilities frequently abused by attackers, such as curl, wget, compilers, and interactive shells.
6. Proactive Threat Hunting for Post-Compromise Activity
Regularly review newly published IOCs, artifacts, and TTPs from vendors, researchers, and cloud providers.
Monitor community and industry threat-intel feeds for emerging exploit variants or post-exploitation behaviors.
Update your hunting queries and detections as new indicators become available.
Perform ongoing retrospective hunts across logs for anomalies, persistence attempts, or suspicious RSC-related activity.
Stay aligned with CISA KEV, vendor advisories, and security press releases to ensure you are tracking the latest findings and recommendations.
7. Improve Incident Response Preparedness
Force reauthentication for all users served by affected applications.
Rotate all secrets stored in build systems, CI/CD pipelines, and deployment scripts.
Conduct tabletop exercises covering web-to-shell intrusions and cloud escalation paths.
Maintain clear escalation paths for responding to confirmed RCE events in production.
React2Shell is now a KEV-listed, actively exploited RCE, and organizations must treat it with the highest urgency. The most effective defensive approach is to patch immediately, limit exposure of RSC-enabled services, and focus on post-compromise detection across host, application, and cloud environments. Rapid threat hunting, credential rotation, and verification of potentially affected systems are essential steps. Any previously exposed, unpatched RSC deployment should be considered at risk and reviewed accordingly before returning to production.