Executive summary

CVE-2025-55182 (“React2Shell”) is a CVSS 10.0 unauthenticated remote code execution vulnerability in React Server Components (RSC) that enables arbitrary code execution on affected servers via a single crafted HTTP request to a Server Function endpoint. Widespread adoption of RSC-capable frameworks such as Next.js, combined with active exploitation by state-sponsored and opportunistic actors, elevates this to a high-likelihood, high-impact event that requires immediate patching and broad attack-surface reduction.​

Technical overview

The vulnerability stems from unsafe deserialization in the RSC “Flight” protocol, where attacker-controlled JSON payloads sent to Server Function endpoints are decoded and executed without sufficient validation. A remote, unauthenticated adversary can achieve full server-side RCE by sending a malicious HTTP request to any reachable RSC Server Function endpoint, even in otherwise standard configurations.​

Threat activity

Threat intelligence teams have reported rapid weaponization of React2Shell, with China-aligned groups including Earth Lamia and Jackpot Panda observed exploiting the bug within 24 hours of disclosure against cloud-hosted RSC workloads and deploying web shells, backdoors, and tunneling implants post-compromise. CISA has added CVE-2025-55182 to the Known Exploited Vulnerabilities catalog, and sensors such as CyRisk are recording opportunistic exploit traffic at scale against exposed RSC and Next.js surfaces.​

Affected components

The issue affects React 19 server-side packages react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0, as well as ecosystems that embed these components. Confirmed affected frameworks include Next.js App Router (notably 15.x and 16.x series and 14.3.0-canary.77 and later canaries), React Router RSC preview, Waku, Vite and Parcel RSC plugins, and RedwoodSDK where RSC support is enabled.​

Impacted and non-impacted use cases

Server-side applications built on React 19.x that implement or support RSC should be treated as exposed until dependency versions are verified and patched, even if explicit Server Function endpoints are not present in application code. Pure client-side React applications and React deployments that neither use RSC nor rely on RSC-capable frameworks are not affected by this vulnerability.​

Detection and attack surface mapping

Large-scale internet scans have identified millions of internet-facing services that may be running RSC-capable stacks such as Next.js, Waku, React Router, or RedwoodSDK, although not all instances necessarily run vulnerable versions. Exposed assets can be surfaced using fingerprints such as HTTP headers indicating “Content-Type: text/x-component” or “Vary: RSC,” references to RSC-specific markers in response bodies (for example Waku and Vite RSC identifiers), generator meta tags for Waku, and known favicon hashes for affected frameworks.​

Exploit and PoC landscape

Multiple proof-of-concept exploits for React2Shell are publicly available and have been integrated into scanners and offensive tooling, but several circulating PoCs are either non-functional or contain embedded malware, increasing operational risk for defenders testing them. Exploitation flow is straightforward: locate an RSC endpoint, send a crafted serialized payload to a Server Function endpoint, and leverage unsafe deserialization to obtain shell access and deploy further persistence mechanisms.​

Mitigations and patch status

Patched versions
React and ecosystem maintainers have shipped fixed releases for the vulnerable RSC packages and key frameworks:

• React RSC packages (react-server-dom-*): 19.0.1, 19.1.2, 19.2.1.​

• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 and associated patched canary lines.​

Compensating controls
Major WAF providers, including AWS and Cloudflare, have deployed managed rules targeting React2Shell exploitation patterns, offering a useful but partial mitigation layer for applications fronted by these services. However, public PoCs demonstrate WAF-evasion techniques, and configuration gaps or custom routes can still expose RSC endpoints, so WAF policies must be treated as a defense-in-depth measure rather than a primary control.​

Recommended actions

1. Asset inventory and exposure analysis

• Enumerate all internet-accessible and internal services using React 19, Next.js App Router, React Router RSC preview, Waku, RedwoodSDK, and Vite/Parcel RSC plugins, with emphasis on workloads that terminate HTTP(S) traffic.​

• Use known RSC fingerprints (RSC-specific response headers, body markers, and Waku meta tags) to locate potentially affected services across external attack surface management platforms and internal discovery tools.​

2. Patching and hardening

• Upgrade react-server-dom-* dependencies to a patched 19.x release and rebuild affected services, ensuring lockfiles and transitive dependencies are refreshed.​

• For Next.js, move to one of the patched 15.x or 16.x versions (or a non-RSC configuration) and re-deploy all production workloads; automated utilities such as the official fix-react2shell-next tool can streamline this process.​

• Where RSC functionality is not strictly required, temporarily disable RSC or Server Function endpoints to remove the vulnerable attack surface while upgrades are validated.​

3. Detection, response, and monitoring

• Hunt for suspicious HTTP traffic targeting RSC endpoints, including anomalous serialized payloads, atypical POST requests to RSC routes, and sudden spikes in error or deserialization logs around disclosure dates.​

• Conduct compromise assessments on previously exposed assets to detect web shells, unapproved backdoors, tunneling utilities, and unexpected system-level child processes originating from application runtimes.​

• Integrate vendor IoCs and behavioral analytics for React2Shell into SIEM, IDS/IPS, and EDR tooling to improve ongoing detection of attempted and successful exploitation.​

Clarifications for stakeholders

Organizations running only pre-19 React without RSC support, or purely client-rendered React front-ends backed by non-RSC APIs, are out of scope for this vulnerability. Given the criticality and active exploitation, any internet-facing service using RSC-capable stacks should be treated as compromised by default until patched, reviewed for indicators of exploitation, and brought under continuous monitoring for follow-on activity.​