A maximum-severity remote code execution flaw in React Server Components—CVE-2025-55182, scored CVSS 10.0— now threatens an estimated 39% of cloud environments. Disclosed on December 3, 2025, this vulnerability allows unauthenticated attackers to execute arbitrary code on servers running React 19’s Server Components feature, and active exploitation by nation-state threat groups began within hours. Organizations using Next.js 15.x or 16.x with App Router, or any framework implementing React Server Components, must patch immediately.
The vulnerability, nicknamed “React2Shell” by the security community, represents the most severe security incident to hit the React ecosystem since the framework’s creation. Security researchers at Wiz have confirmed near-100% exploitation reliability in testing, while AWS threat intelligence teams observed Chinese state-nexus actors weaponizing the flaw against production systems by December 5. Patched versions are available for all affected React and Next.js releases.
How React Server Components Became the Attack Surface for React2Shell
React Server Components (RSC), introduced as a stable feature in React 19, fundamentally changed how React applications render content. Traditional React runs entirely in the browser—JavaScript downloads, executes, and builds the user interface on the client’s device. RSC moves this rendering to the server, streaming components directly to browsers without shipping their JavaScript payload.
The architecture relies on a lightweight transport mechanism called the React Flight protocol. When a user interacts with a server-enabled component, the client sends a serialized request to the server describing what data or action it needs. The server deserializes this “Flight payload,” processes the request, and streams back rendered components. This approach dramatically improves performance and SEO while reducing JavaScript bundle sizes—compelling benefits that drove rapid adoption across the React ecosystem.
Next.js integrated RSC deeply into its App Router starting with version 13, and by late 2025, the feature had become foundational to modern React development. Major frameworks including React Router, Waku, RedwoodSDK, and plugins for Vite and Parcel all implemented RSC support. This widespread adoption created a vast attack surface that went undetected until security researcher Lachlan Davidson discovered the flaw on November 29, 2025.
Inside the React2Shell RCE: How CVE-2025-55182 Allows Arbitrary Code Execution
CVE-2025-55182 is a classic deserialization-of-untrusted-data vulnerability—the same category that produced Log4Shell in 2021. The flaw resides in how React’s server-side RSC engine processes incoming Flight payloads without adequate validation.
The vulnerability operates through a specific mechanism in the react-server-dom-webpack package. When the server receives a Flight payload, the requireModule function maps client-side references to server-side code using a module_id#export_name syntax. Critically, this function failed to validate that incoming references pointed to legitimate exports. An attacker could craft payloads targeting internal JavaScript properties—like constructor—instead of actual module exports.
This creates what security researchers call a gadget chain. Standard Node.js modules provide “gadgets” that, when chained together, enable arbitrary code execution. For example, targeting vm#runInThisContext allows execution of attacker-controlled JavaScript. The deserialization mechanism also proved susceptible to prototype pollution, enabling attackers to modify object prototypes and manipulate execution paths throughout the application.
Palo Alto Networks Unit 42 characterized the exploit as uniquely dangerous: “This is a deterministic logic flaw rather than a probabilistic error. Unlike memory corruption bugs that may fail, this flaw guarantees execution, transforming it into a reliable system-wide bypass.”
How Threat Actors Weaponize React2Shell in Real-World Attacks
Exploitation requires nothing more than sending a malicious HTTP POST request to any React Server Function endpoint. No authentication, no special access, no user interaction— just a carefully crafted multipart request containing a weaponized Flight payload.
The attack works because exploitation occurs before any authentication or routing logic executes. When the server receives the request, it immediately attempts to deserialize the Flight payload to understand what the client wants. The malicious payload triggers code execution during this deserialization step, meaning security middleware, authentication checks, and access controls never have a chance to intervene.
Applications are vulnerable in default configurations. Standard Next.js deployments created with create-next-app expose RSC endpoints publicly without modification. Even applications that don’t explicitly implement Server Functions remain vulnerable if their framework supports RSC— the vulnerable code path exists regardless of whether developers actively use it.
Security researcher @maple3142 published a working proof-of-concept approximately 30 hours after disclosure, demonstrating exploitation through manipulation of the Chunk.prototype.then resolution pathway during Blob deserialization. Wiz Research subsequently confirmed their own PoC achieved “near-100% reliability” across tested environments.
How Widespread Is React2Shell? Assessing the Global Impact
The vulnerability affects a staggering portion of the modern web. According to Wiz Research, 39% of cloud environments contain at least one vulnerable React or Next.js instance. Palo Alto Networks identified over 968,000 publicly exposed React and Next.js servers, while Shodan scans detected 571,249 servers running React components and 444,043 running Next.js.
The affected software spans the React ecosystem:
- React packages: Versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of
react-server-dom-webpack,react-server-dom-parcel, andreact-server-dom-turbopack - Next.js: All 15.x and 16.x versions using App Router, plus canary releases from 14.3.0-canary.77 onward
- Other frameworks: React Router (RSC mode), Waku, RedwoodSDK, and RSC plugins for Vite and Parcel
Applications remain safe if they run React 18 or earlier, use only client-side rendering, or implement Next.js exclusively with Pages Router. Edge Runtime deployments and Cloudflare Workers are also immune due to their execution model.
React2Shell Exploitation Timeline: Nation-State Actors Move Within Hours
The theoretical threat became reality almost immediately. AWS threat intelligence teams reported observing exploitation attempts by multiple China state-nexus threat groups—including Earth Lamia and Jackpot Panda—within hours of the December 3 public disclosure. GreyNoise identified 95+ IP addresses conducting automated scanning for vulnerable systems.
Amazon CISO CJ Moses issued a stark warning: “This demonstrates a systematic approach: threat actors monitor for new vulnerability disclosures, rapidly integrate public exploits into their scanning infrastructure, and conduct broad campaigns across multiple CVEs simultaneously.”
Wiz Research documented post-exploitation activity including AWS credential harvesting, cloud credential exfiltration via base64 encoding, Sliver malware framework installation, and cryptocurrency mining operations using XMRig. Kaspersky observed reconnaissance activities and web shell installations on compromised servers.
The speed of weaponization reflects the vulnerability’s low barrier to exploitation. Unlike complex attack chains requiring specialized knowledge, React2Shell enables reliable remote code execution with minimal sophistication—a characteristic that makes it attractive to both nation-state actors and financially motivated cybercriminals.
How the React and Next.js Teams Responded to React2Shell
The React team and affected framework maintainers executed an unusually swift response, compressing the typical vulnerability lifecycle into just four days. Lachlan Davidson reported the flaw through Meta’s Bug Bounty program on November 29. By November 30, Meta security researchers had confirmed the issue and begun collaborating with the React team on a fix.
The patch was ready by December 1, triggering coordination with hosting providers and open-source projects. Cloudflare deployed WAF protection rules on December 2—a day before public disclosure. On December 3, patches hit npm simultaneously with the public advisory, giving defenders and attackers equal notice but ensuring fixes were immediately available.
The React team’s official advisory was direct: “There is an unauthenticated remote code execution vulnerability in React Server Components. We recommend upgrading immediately.” Vercel’s Sebastian Markbåge and Josh Story authored the Next.js advisory, emphasizing that the upstream React flaw affected all downstream implementations.
Vercel deployed automatic WAF protection for all projects hosted on their platform at no cost, while emphasizing that “you should not rely on the WAF for full protection—immediate upgrades to a patched version are required.” AWS updated its managed WAF rules, Google Cloud released Cloud Armor protections, and Akamai and Fastly pushed emergency rule updates to their customers.
How to Identify Whether Your React Apps Are Vulnerable to React2Shell
Detection begins with dependency auditing. Check your installed versions using:
npm list react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next
Any React 19 server-dom package at version 19.0.0, 19.1.0, 19.1.1, or 19.2.0 is vulnerable. For Next.js, any 15.x or 16.x version before the patched releases (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7) requires immediate updating.
Security firm Assetnote released an open-source scanner at github.com/assetnote/react2shell-scanner for bulk detection across infrastructure. Manual testing involves sending a specifically crafted multipart POST request to your application—vulnerable servers return HTTP 500 errors with E{"digest" patterns in text/x-component responses, while patched servers handle the malformed input gracefully.
Standard vulnerability scanning tools have updated their databases. Running npm audit or npx snyk test will now flag affected packages.
How to Patch CVE-2025-55182 and Secure React Server Components
Patching is the only complete remediation. For React packages, update to versions 19.0.1, 19.1.2, or 19.2.1:
npm install [email protected] react-dom@latest react-server-dom-webpack@latest
For Next.js, install the patched version corresponding to your release line. Version 15.5.x users should update to 15.5.7, version 16.x users to 16.0.7, and so forth. Organizations using canary releases since 14.3.0-canary.77 should either downgrade to stable 14.x or update to 15.6.0-canary.58.
After updating dependencies, rebuild all Docker images and serverless bundles—the vulnerable code may be cached in deployment artifacts even after npm packages update. Verify that CI/CD pipelines pull fresh dependencies rather than using cached builds.
WAF protection provides defense-in-depth but cannot substitute for patching. Vercel customers receive automatic protection, Cloudflare WAF covers all tiers including free accounts, and AWS WAF customers should ensure they’re running AWSManagedRulesKnownBadInputsRuleSet version 1.24 or later. There is no configuration option to disable the vulnerable code path without patching.
Why React2Shell Changes the Security Model for Modern JavaScript Frameworks
Security researchers immediately drew comparisons to Log4Shell, the 2021 vulnerability that devastated Java environments. Both share the same weakness classification—CWE-502, deserialization of untrusted data—and both achieve maximum CVSS severity through unauthenticated remote code execution. Sonatype noted that “like Log4Shell, early indications show scanning activity beginning quickly.”
The parallel is imperfect. Log4j had accumulated across decades of Java applications, embedded in countless dependencies in ways organizations often couldn’t identify. React Server Components, by contrast, represent a relatively new feature adopted primarily in modern greenfield development. The blast radius, while enormous, is somewhat more contained.
Yet React2Shell exposes systemic risks in modern full-stack JavaScript development. Snyk’s analysis identified the core problem: “Highly dynamic serialization mechanisms can become powerful RCE vectors when insufficient validation is applied. Because React Server Components are rapidly becoming foundational across frameworks, the blast radius of this vulnerability is unusually wide.”
The incident underscores how architectural optimizations that move logic server-side simultaneously move attack surfaces closer to sensitive data and systems. As Unit 42 observed, “While React Server Components optimize data fetching and SEO by moving logic closer to the source, they simultaneously move the attack surface closer to organizations’ most sensitive and valuable data.”
Key Security Lessons React2Shell Exposes for Engineering Teams
React2Shell delivers several urgent lessons. First, dependency management is security management. Organizations must maintain real-time visibility into their JavaScript supply chains, with automated alerting for critical CVEs. The four-day window between discovery and disclosure demonstrates that rapid patching capability isn’t optional—it’s essential.
Second, defense-in-depth matters. Organizations with WAF protection in place before disclosure had automatic mitigation, buying time for proper patching even as nation-state actors began exploitation campaigns. WAF, runtime protection, and network segmentation all reduce exposure when zero-days emerge.
Third, server-side JavaScript requires server-side security thinking. Traditional React applications ran entirely client-side, limiting their security exposure to XSS and similar browser-context vulnerabilities. RSC fundamentally changes the threat model, making React applications susceptible to the same classes of server-side attacks that have historically plagued Java, PHP, and other backend technologies.
For security teams, CVE-2025-55182 should trigger immediate asset inventory efforts to identify all RSC-enabled applications. For engineering leadership, it warrants review of dependency update policies and incident response procedures. The vulnerability’s speed of exploitation—hours, not days—means organizations need processes capable of emergency patching within that timeframe.
The Future After React2Shell: Strengthening JavaScript Supply Chain Security
CISA added CVE-2025-55182 to its Known Exploited Vulnerabilities catalog on December 5, establishing a federal remediation deadline and signaling the government’s assessment of the threat’s severity. With 82% of JavaScript developers using React and the framework powering significant portions of the modern web, the vulnerability’s full impact will unfold over weeks and months as organizations race to patch.
The React team’s rapid response and coordinated disclosure process demonstrated security maturity, but the existence of such a fundamental flaw in a framework at this scale raises questions about security review processes for complex serialization mechanisms. The security community will likely scrutinize similar patterns in other frameworks.
For now, the priority is clear: identify affected applications, apply patches immediately, enable WAF protection as an additional layer, and monitor for indicators of compromise. React2Shell is actively exploited, highly reliable, and trivially weaponized. The window for proactive defense is narrowing.