The React ecosystem is facing a critical security issue: CVE-2025-55182, informally dubbed React2Shell, a 10.0/10 CVSS remote code execution (RCE) vulnerability in React 19 Server Components. The flaw allows an unauthenticated attacker to execute arbitrary JavaScript code on vulnerable servers, posing systemic risk to modern web applications built with React and frameworks such as Next.js.
What is React2Shell and why this React 19 vulnerability is so dangerous
React is one of the most widely used open-source libraries for building user interfaces. The core react npm package is downloaded around 55.8 million times per week, while Next.js—a popular React-based framework—sees roughly 16.7 million weekly downloads. This level of adoption means that any remotely exploitable vulnerability in the server-side React stack can have far‑reaching consequences.
React2Shell specifically targets how React processes data sent to React Server Function endpoints in the context of React Server Components (RSC). An attacker only needs network access to a reachable RSC-enabled endpoint. By sending a specially crafted HTTP request, the attacker can trigger a flaw in the deserialization of the RSC payload, leading to execution of arbitrary JavaScript code on the server.
Crucially, no authentication, tokens, or elevated privileges are required. The attack surface is any exposed RSC endpoint. This makes the vulnerability highly attractive for automated scanning, mass exploitation campaigns, and opportunistic attacks, much like what was observed with incidents such as Log4Shell in the Java ecosystem.
Technical root cause: logically insecure deserialization of RSC streams
Researchers at Endor Labs classify React2Shell as a case of logically insecure deserialization. Unlike classical binary deserialization bugs, the issue here lies in how the React server runtime interprets structured RSC streams.
When a client interacts with React Server Components, the server sends and receives a specialized data stream that encodes component trees and function calls. In vulnerable versions, the server does not sufficiently validate the structure and semantics of incoming RSC data. If an attacker tampers with this stream—modifying types, references, or payload segments—the validation logic can be bypassed.
The result is that parts of the crafted payload are incorrectly treated as trusted JavaScript and executed within the server context. Because this behavior exists in default configurations of affected frameworks, exploitation does not rely on rare or misconfigured options; typical “out‑of‑the‑box” deployments are at risk as soon as they enable React Server Components.
Affected React Server Components and Next.js versions
According to the React maintainers, CVE-2025-55182 affects the following npm packages and versions:
Vulnerable React server packages:
react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack — versions 19.0, 19.1.0, 19.1.1, 19.2.0.
Patched React server versions:
Security fixes have been released in 19.0.1, 19.1.2, 19.2.1. Upgrading to these or later versions is a baseline requirement for any deployment using React Server Components.
The impact extends to Next.js, which integrates React Server Components as a core feature. Vercel attempted to register a separate identifier (CVE-2025-66478), but NIST has classified it as a duplicate of CVE-2025-55182.
Vulnerable Next.js ranges:
— Canary releases from 14.3.0-canary.77 onward;
— All 15.x and 16.x releases prior to the patched builds.
Patched Next.js versions: 16.0.7, 15.5.7, 15.4.8, 15.3.6, 15.2.6, 15.1.9, 15.0.5.
Security researchers also warn of potential exposure in other React Server implementations and integrations, including Vite RSC plugin, Parcel RSC plugin, React Router RSC preview, RedwoodSDK, and Waku. Importantly, an application may remain vulnerable even if it does not explicitly define React Server Function endpoints, as long as RSC support is enabled in the stack.
Scope of exposure and the rise of PoC exploits
Cloud security company Wiz estimates that approximately 39% of all cloud environments contain instances vulnerable to CVE-2025-55182 or its duplicate CVE-2025-66478. Early internet-wide scans have already identified more than 968,000 servers running React, Next.js, or similar stacks that could be affected.
Within 24 hours of public disclosure, at least one proof-of-concept (PoC) exploit was published, and support for detecting the vulnerability was added to multiple security scanners. At the same time, the original discoverer, researcher Lachlan Davidson, reported a wave of fake PoCs using Node.js APIs such as vm.runInThisContext, child_process.exec, and fs.writeFile. These demo exploits do not represent the actual attack vector and, in particular, do not work against Next.js, where those APIs are not available in the runtime.
This situation highlights a recurring challenge in vulnerability response: defenders must quickly distinguish reliable technical information from misleading PoCs while still acting fast enough to reduce exposure.
Defensive strategies and mitigation for React2Shell
Priority one: Patch vulnerable React and Next.js components
The most effective mitigation is to immediately update to patched versions of the affected packages:
— Upgrade React RSC packages to 19.0.1, 19.1.2, 19.2.1 or later;
— Upgrade Next.js to one of the fixed releases: 16.0.7, 15.5.7, 15.4.8, 15.3.6, 15.2.6, 15.1.9, 15.0.5 or newer.
Organizations should use software bills of materials (SBOMs) or dependency scanners to quickly identify where React Server Components are in use across microservices and front‑end backends.
Compensating controls while patches are being deployed
Major cloud and edge providers including Cloudflare, AWS, Akamai, Fastly, and Google Cloud have already introduced WAF signatures to detect and block malicious RSC payloads. Until all systems are patched, recommended measures include:
— Deploy or update WAF rules to filter suspicious React Server Components traffic;
— Monitor HTTP traffic to RSC and Server Function endpoints for anomalies in request patterns, headers, and payload structures;
— Where feasible, restrict network exposure of RSC-enabled services (e.g., via IP allowlists, VPN, or private connectivity);
— Conduct a targeted technology stack audit (including EASM/ASM tools) to discover externally exposed React/Next.js applications using vulnerable RSC components.
Secure development lessons from React2Shell
React2Shell underscores a familiar but often underestimated class of bugs: trusting complex serialized data flows. Just as unsafe deserialization in Java and .NET has led to high‑impact RCE in the past, new server-side UI runtimes introduce similarly complex protocols that must be treated as hostile input.
Teams building with React 19, Next.js, or other RSC-compatible stacks should update their secure coding guidelines to emphasize strict validation of server-bound data, careful handling of internal protocols exposed over HTTP, and routine security reviews whenever experimental or cutting‑edge framework features are enabled.
React2Shell (CVE-2025-55182) is a clear reminder that server-side features in front-end frameworks can quietly expand the attack surface. Organizations that quickly patch vulnerable packages, harden their perimeter with WAF and monitoring, and embed secure design principles into their use of React Server Components will be far better positioned against current and future exploit waves targeting this rapidly evolving ecosystem.
