A pair of newly disclosed vulnerabilities in React and Next.js has opened the door to unauthenticated remote code execution (RCE) across millions of web applications with no special configuration or user interaction required.
The flaws stem from a defect in React Server Components (RSC) that researchers warn could enable full server takeover in default installations.
“React2Shell is a clear example of how AI-generated ‘slop’ PoCs can flood GitHub and social feeds with non-functional exploits at the same time real functional exploits are being developed behind the scenes,” said Itai Goldman, CTO and Co-Founder at Miggo Security.
He added, “My concern is that this noise gives a false sense of comfort. If the public PoCs look broken, defenders start to assume the vulnerability is overblown — even when the underlying bug is real, broadly weaponizable, and sitting in a huge install base.”
Inside the Vulnerabilities
The root cause (CVE-2025-55182) lies in a prototype pollution flaw in React Server Components’ Flight protocol deserialization logic.
The protocol streams React component data between server and client, and if attackers inject malicious serialized data into this stream, they can manipulate JavaScript prototypes and escalate from data tampering to full remote code execution.
Both vulnerabilities carry CVSS 10.0 scores due to unauthenticated exploitation, an HTTP-accessible remote attack surface, default vulnerability with no special configuration required, and full server compromise potential.
The vulnerability affects React’s server-side packages in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0, including:
- react-server-dom-webpack
- react-server-dom-turbopack
- react-server-dom-parcel
Downstream, CVE-2025-66478 affects Next.js, which embeds the vulnerable RSC packages in its App Router architecture.
Ecosystems affected by the vulnerability include:
- Next.js 14.3.0-canary.77+, all 15.x and 16.x
- React Router RSC-enabled releases
- Vite and Parcel RSC plugins
- Waku, RedwoodJS, and other server component frameworks
Although proof-of-concept details are not yet publicly released due to severity, exploitation is expected to be simple once attack methods circulate.
Protecting Your Pipeline From React2Shell Exploits
Security teams should harden their CI/CD pipelines, tighten access controls, and improve monitoring across runtime environments.
- Patch React, RSC packages, and all dependent frameworks to the latest fixed versions and use dependency pinning to prevent reintroduction of vulnerable releases.
- Apply temporary protections such as WAF rules, increased monitoring of RSC Flight payloads, and enhanced observability around server-side rendering endpoints.
- Enforce strict least-privilege access for service accounts, minimize exposed secrets, and rotate credentials after patching.
- Validate and sanitize all serialized or user-supplied input, and review deserialization pathways as part of DevSecOps best practices.
- Monitor and log runtime behavior for anomalies, including unexpected command execution, file modifications, or unusual API calls — using CI/CD gatekeeping and automated vulnerability scanning.
- Segment RSC services from high-value systems and apply zero-trust principles to limit blast radius if exploitation occurs.
These measures help reduce the risk of RCE attacks and prevent vulnerable React Server Component workflows from becoming entry points for broader compromises.
Modern JS Frameworks Are Expanding the Attack Surface
React2Shell is a reminder that server-side JavaScript frameworks have become an attack vector in today’s global software supply chain.
As the industry shifts toward server-rendered components and serialization-heavy communication models, deserialization flaws — once associated primarily with older languages like Java and PHP — are now emerging at scale within modern JS ecosystems.
The growing adoption of React Server Components amplifies this risk, underscoring the need for rigorous hardening of server-side JavaScript and vigilant dependency monitoring.
These trends highlight why software supply chain security must evolve to address vulnerabilities emerging from deep within modern development frameworks.