React2Shell and the npm Supply Chain:

The Web's Foundations Are Shaking

When a single HTTP request can compromise 39% of the planet's cloud environments

The day React became a weapon

On December 3, 2025, a piece of news ripped through the cybersecurity community with the speed of a zero-day: a critical vulnerability with the maximum possible CVSS score of 10.0 had been found in the heart of React Server Components. Not in an obscure plugin. Not in a forgotten third-party npm library. In the framework itself, the one holding up a massive chunk of the modern web.

The vulnerability, christened React2Shell (CVE-2025-55182), allows an attacker to execute arbitrary code on a server through a single HTTP request, with no authentication, and a success rate close to 100%. No stolen credentials needed. No social engineering required. Just one well-crafted POST.

The name is deliberate. "React2Shell" is an explicit callback to Log4Shell (CVE-2021-44228), the vulnerability that threw half the internet into a panic in 2021. And the comparison, unfortunately, holds: same maximum severity, same ease of exploitation, same capillary distribution of vulnerable software.

But there's a difference that makes React2Shell arguably even more insidious: React isn't a logging component running quietly in the background. It's the world's most popular frontend framework, with 55 million weekly npm downloads, adopted by Netflix, Airbnb, and millions of other applications. Striking React means striking the connective tissue of the web.

Part 1: Anatomys of React2Shell

The Flight protocol: where it all begins

To understand React2Shell, you need to understand what React Server Components (RSC) are and the protocol that governs them: Flight.

React 19 introduced an architectural revolution: the ability to run React components directly on the server rather than in the browser. The Flight protocol is the mechanism that serializes and deserializes "component trees", the data structures describing how the UI should be rendered, shuttling them between client and server.

The problem is as simple as it is devastating: the server blindly trusted data arriving from the client.

React's server-side decoder didn't validate the structure of incoming payloads. When a server received a specially malformed RSC payload, it processed the data without checking its integrity. This allowed an attacker to inject arbitrary objects that were deserialized in a privileged context, leading to the execution of JavaScript code with the permissions of the running Node.js process.

In less technical terms: it's as if a restaurant accepted any package from the service door without checking what's inside, and then served the contents directly to customers.

The vulnerability in numbers

The data that emerged in the weeks following disclosure speaks volumes:

• CVSS 10.0: maximum severity, the highest score possible

• 39% of cloud environments monitored by Wiz contained vulnerable React or Next.js instances

• 69% of cloud environments included Next.js somewhere in their stack

• 44% of all cloud environments had publicly exposed Next.js applications

• 968,000+ React/Next.js servers detected by Palo Alto Cortex Xpanse telemetry

• 90,300 instances still vulnerable as of December 31, 2025 (68,400 in the US alone)

• 12 million websites potentially impacted according to early estimates

For context: a standard Next.js app created with create-next-app and built for production was exploitable with zero code changes by the developer. The default configuration was vulnerable.

From disclosure to weaponization: a matter of hours

The React2Shell timeline is a case study in how fast modern cybercrime turns a vulnerability into an operational weapon:

• November 29, 2025: Lachlan Davidson discovers the vulnerability and reports it to the React team through Meta's Bug Bounty program

• December 3, 2025: Coordinated public disclosure. Vercel, Meta, and major cloud providers release patches simultaneously

• December 3, hours later: Amazon's threat intelligence teams detect active exploitation attempts from China state-nexus groups, including Earth Lamia and Jackpot Panda

• December 4, 2025: A working proof-of-concept is published on GitHub by security engineer Moritz Sanft

• December 5, 6:00 AM UTC: Wiz Research identifies multiple compromised victims, primarily Next.js applications and Kubernetes containers

• December 5, 2025: Datadog detects over 80 IP addresses linked to threat actors scanning for the vulnerability

• December 8, 2025: GreyNoise observes exploitation attempts from over 200 IPs in the previous two days

• December 12, 2025: Google Threat Intelligence Group (GTIG) confirms multiple campaigns from Chinese, Iranian, and financially motivated cybercriminal clusters

• December 15, 2025: Microsoft publishes a detailed analysis with hundreds of confirmed compromised machines

• Late December 2025: The RondoDox botnet launches over 40 React2Shell attempts in six days, killing competing miners and masquerading as legitimate system processes

Hours. From patch publication to global-scale weaponization, it took hours. Not days. Not weeks. Hours.

Part 2: Who attacked and how

State actors: China moves first

The fastest response came from China-linked actors. Amazon, Google, and Palo Alto Networks all independently confirmed that Chinese state-nexus groups were among the first to exploit React2Shell.

According to AWS, infrastructure associated with Earth Lamia and Jackpot Panda began probing vulnerable systems within hours of disclosure. Google confirmed "distinct campaigns" that leveraged the vulnerability to deploy the MINOCAT tunneler, SNOWLIGHT downloader, HISONIC and COMPOOD backdoors, and the XMRIG cryptocurrency miner.

Palo Alto Networks Unit 42 identified activity attributed to CL-STA-1015, an initial access broker (IAB) with suspected ties to the PRC's Ministry of State Security. The activity involved fileless execution of malicious shell scripts, followed by installation of SNOWLIGHT and VShell trojans.

Iranian actors were also observed exploiting the vulnerability.

The kill chain: from POST to total control

Microsoft detailed the typical attack chain:

1. Exploit: The attacker sends a crafted POST request to a Server Function endpoint. The serialized payload is deserialized by the backend, which executes attacker-provided code under the Node.js runtime.

2. Discovery: Once code execution is achieved, the attacker runs reconnaissance commands: whoami, hostname, environment variable dumps, /etc/passwd enumeration, to profile the host and execution context.

3. Persistence: Attackers install remote management tools like MeshAgent, create malicious users, modify authorized_keys, and enable root login.

4. Payload delivery: Using wget and curl, they download and execute malicious scripts including Mirai loaders, reverse shells to Cobalt Strike servers, and cryptominers.

5. Lateral movement: In more sophisticated compromises, attackers exfiltrate AWS credentials, cloud configuration files, and use Sliver for lateral movement through the infrastructure.

Opportunistic cybercrime: everyone wants a piece

It wasn't only state actors. Ellio's analysis showed that just 2% of React2Shell attacks were limited to reconnaissance. A full 65% attempted to deliver Mirai malware (for building botnets) and cryptominers. The RondoDox botnet stood out for its sophistication: terminating competing miners, removing artifacts from previous attacks, cleaning Docker payloads left by other threat actors, and disguising itself as legitimate system processes like systemd-devd.

Part 3: Incomplete patches: the problem doesn't end

The vulnerability cycle that won't close

If React2Shell had been an isolated vulnerability, fixed with a single patch and forgotten, it would already be serious enough. But reality is worse: the initial disclosure opened a Pandora's box.

After December 3, security researchers did what they always do following a critical vulnerability: they examined the surrounding code looking for variants and bypasses.

December 11, 2025: Two new vulnerabilities emerge: CVE-2025-55184 (Denial of Service, CVSS 7.5) and CVE-2025-55183 (Source Code Exposure, CVSS 5.3). The first allows a single crafted HTTP request to lock the server in an infinite loop, blocking all subsequent requests. Anyone who had just patched for React2Shell needed to patch again.

But it doesn't end there. The fix for CVE-2025-55184 turned out to be incomplete. The React team released a new patch under CVE-2025-67779, acknowledging that the previous correction didn't cover all attack vectors.

January 26, 2026: The final twist. CVE-2026-23864 (CVSS 7.5) reveals that even the previous patches were insufficient. New Denial of Service vectors allow server crashes, out-of-memory exceptions, and excessive CPU usage. Only React versions 19.0.4, 19.1.5, and 19.2.4 are considered safe.

In three months: one critical RCE, three DoS vulnerabilities, one source code exposure, and at least two incomplete patches. The same component, the same Flight protocol, the same fundamental problem: React Server Components' serialization was never designed with untrusted input in mind.

Part 4: Metro4Shell: the other bomb in the React ecosystem

When the dev tool becomes the entry point

While the world's attention was focused on React2Shell, another critical vulnerability was quietly claiming victims across the React ecosystem. And this one strikes where it hurts most: developers' machines.

CVE-2025-11953, renamed Metro4Shell (CVSS 9.8), is a command injection vulnerability in the Metro development server, React Native's default JavaScript bundler, distributed through the @react-native-community/cli npm package.

The flaw resides in Metro's /open-url endpoint, which passes user input directly to the unsafe open() function from the open npm package, without any sanitization. An unauthenticated remote attacker can execute arbitrary OS commands.

There's a detail that makes this even more perverse: Metro binds to all network interfaces (0.0.0.0) by default, despite displaying a misleading "localhost:8081" message. A developer who sees "localhost" thinks they're safe. They're not.

46 days in the dark

Metro4Shell's timeline is a case study in how badly the cybersecurity alert system can fail:

• November 2025: JFrog publishes technical details of the vulnerability

• December 21, 2025: VulnCheck detects the first active exploit in its Canary honeypot network

• January 4, 2026: Same payloads observed again

• January 21, 2026: Third wave of attacks with identical payloads, indicating continued operational use

• Late January 2026: EPSS (Exploit Prediction Scoring System) still assigns an exploitation probability of 0.00405, essentially zero

• February 5, 2026: CISA adds CVE-2025-11953 to the KEV catalog

• February 6, 2026: EPSS jumps from 0.4% to 15.6%, not because exploitation changed, but because the official label arrived

46 days. For 46 days, attackers were actively deploying malware on developers' machines while the scoring system many teams rely on to prioritize patches classified the vulnerability as negligible. As Averlon observed: "The model didn't detect the exploitation. It detected the label."

Targeting developers: the new front

Observed payloads reveal a multi-stage attack designed to hit development environments:

1. Defense disabling: Base64-encoded PowerShell scripts adding Microsoft Defender exclusions for the working directory and temp folder

2. C2 connection: Establishing a raw TCP connection to attacker-controlled infrastructure

3. Payload retrieval: Downloading platform-specific payloads (Windows and Linux)

4. Persistence: Installing Rust-based malware, SNOWLIGHT and VShell trojans

The logic is clear: development environments contain source code, credentials, API keys, and access to production infrastructure. Compromising a developer's machine is often the shortest path to the entire organization.

As VulnCheck wrote: "Development infrastructure becomes production infrastructure the moment it is reachable, regardless of intent."

Part 5: The structural problem: npm and the fragility of the modern web

The elephant in the room: dependencies

React2Shell and Metro4Shell are not isolated incidents. They're symptoms of a structural problem the software community has chosen to ignore for years: the npm ecosystem underpinning much of the modern web is an enormous and fragile attack surface.

Some numbers for context:

• npm hosts over 2.5 million packages

• React alone has 55 million weekly downloads

• Next.js has 16.7 million

• 40% of all developers use React

• 18-20% use Next.js, making it the dominant server-side framework in the React ecosystem

Every npm package carries a dependency tree that can reach staggering depth. A single npm install can download hundreds of packages, each written by different developers, with varying levels of security awareness, maintenance commitment, and trustworthiness.

When a critical vulnerability hits a foundational package like react-server, the shockwave propagates instantly to millions of applications. Not because those developers made bad choices, but because they made the standard choice: use the recommended framework, with default configuration, following official documentation.

The broken trust chain

React Server Components introduced a fundamental architectural shift: the separation between client and server became porous. The Flight protocol sends serialized data between client and server assuming a trust relationship that, in a security context, cannot exist.

As Qualys explained: "React's server runtime was never built to handle untrusted input." Traditionally, client input is sanitized and filtered by APIs before any server logic executes. React Server Components blurred that separation, allowing serialized data representing app state to travel directly between client and server.

It's a pattern cybersecurity knows well: architectural convenience becomes vulnerability when security isn't considered as a design requirement from the start.

Part 6: What this means for organizations and for all of us

For security teams: immediate actions

Inventory and patch
Priority zero is knowing where React and Next.js are deployed across your infrastructure. Not just in main web applications: in microservices, internal tools, CI/CD pipelines, containers. A simple npm ls react-server-dom-webpack can reveal hidden dependencies.

Safe versions for React2Shell and all subsequent vulnerabilities are React 19.0.4, 19.1.5, 19.2.4. For Next.js, patches are available across all major versions from 14 to 16.

Post-patch monitoring
Having patched doesn't mean being safe. If the application was exposed during the vulnerability window (December 3-31, 2025), look for indicators of compromise: anomalous processes, connections to suspicious IPs, changes to authorized_keys, recently created users.

Metro4Shell: don't forget development
Update @react-native-community/cli to version 20.0.0 or later. Ensure the Metro server isn't accessible from untrusted networks. Treat developer machines as critical endpoints, not "just workstations."

For decision makers: the strategic picture

React2Shell isn't a problem you fix with a patch and forget. It's a signal of a structural risk that demands strategic responses:

Software Bill of Materials (SBOM): Know exactly which software components are in use across every application. When the next React2Shell arrives, and it will, response speed will depend on dependency inventory visibility.

Intelligence-based vulnerability management: Metro4Shell proved that EPSS can hover near zero for 46 days while attackers are actively operating. Teams that base patching priorities solely on automated scores risk arriving weeks late.

Zero Trust for code too: Trusting a framework simply because it's popular or maintained by Meta isn't enough. Every dependency is a potential entry point, and default configuration doesn't equal security.

Conclusion: the foundations we take for granted

React2Shell and Metro4Shell tell an uncomfortable story about the web we use every day.

Billions of people interact daily with applications built on React. They do it when booking a flight, checking their bank balance, reading the news. Most have no idea what React is, what npm is, what a serialization protocol is. Nor should they need to.

But those who build and maintain these infrastructures, developers, architects, security teams, decision makers, have a duty to know. A duty to ask: what happens when the foundations shake?

December 2025's answer was clear: when the foundations shake, 39% of the world's cloud environments become vulnerable to a single HTTP request. State actors weaponize the exploit in hours. Patches turn out to be incomplete. And developers discover that the tool they used every day was an entry point for malware.

The modern web is a miracle of collaborative engineering. But it's also a house of cards where each card blindly trusts the others. React2Shell showed what happens when one of those cards turns out to be defective: the entire structure wobbles.

The solution isn't to stop using React or npm. It's to stop taking the security of our foundations for granted. It's to invest in supply chain security not as a compliance checkbox, but as a strategic priority. It's to treat every dependency as a potential attack surface, and every default configuration as a potential vulnerability.

As Aaron Swartz, quoted on Network Caffè's homepage, wrote: "Information is power." But code is infrastructure. And when the infrastructure underpinning the web is compromised, power shifts to those who know how to exploit its weaknesses.

The question isn't whether the next React2Shell will come. The question is: will we be ready this time?

Bibliography:

1. React Team (2025). "Critical Security Vulnerability in React Server Components". react.dev, December 3, 2025

2. React Team (2026). "Denial of Service and Source Code Exposure in React Server Components". react.dev, updated January 26, 2026

3. Wiz Research (2025). "React2Shell (CVE-2025-55182): Critical React Vulnerability". wiz.io, December 3, 2025

4. Wiz Research (2025). "React2Shell Deep Dive: CVE-2025-55182 Exploit Mechanics". wiz.io, December 8, 2025

5. Amazon Web Services (2025). "China-nexus cyber threat groups rapidly exploit React2Shell vulnerability". aws.amazon.com, December 4, 2025

6. Google Threat Intelligence Group (2025). "Multiple Threat Actors Exploit React2Shell (CVE-2025-55182)". cloud.google.com, December 13, 2025

7. Microsoft Security Blog (2025). "Defending against CVE-2025-55182 (React2Shell)". microsoft.com, December 15, 2025

8. Palo Alto Networks Unit 42 (2025). "Exploitation of Critical Vulnerability in React Server Components". unit42.paloaltonetworks.com, December 12, 2025

9. Datadog Security Labs (2025). "CVE-2025-55182 (React2Shell): Remote code execution in React Server Components". securitylabs.datadoghq.com, December 4, 2025

10. Rapid7 (2025). "React2Shell, Critical unauthenticated RCE affecting React Server Components". rapid7.com, December 4, 2025

11. Qualys (2025). "React2Shell: Decoding CVE-2025-55182". blog.qualys.com, December 10, 2025

12. VulnCheck (2026). "Metro4Shell: Exploitation of React Native's Metro Server in the Wild". vulncheck.com, February 2026

13. The Hacker News (2026). "Hackers Exploit Metro4Shell RCE Flaw in React Native CLI npm Package". thehackernews.com, February 2026

14. BleepingComputer (2026). "Hackers exploit critical React Native Metro bug to breach dev systems". bleepingcomputer.com, February 2026

15. Vercel (2026). "Summary of CVE-2026-23864". vercel.com, January 26, 2026

16. Akamai (2026). "CVE-2026-23864: React and Next.js Denial of Service via Memory Exhaustion". akamai.com, January 2026

17. Endor Labs (2025). "Critical Remote Code Execution Vulnerabilities in React and Next.js". endorlabs.com, December 3, 2025

18. SecurityWeek (2025). "Exploitation of React2Shell Surges". securityweek.com, December 8, 2025

19. Recorded Future (2025). "Critical React2Shell Vulnerability Under Active Exploitation by Chinese Threat Actors". recordedfuture.com, December 2025

20. Averlon (2026). "CVE-2025-11953 Analysis: React Native Metro Dev Server Command Injection". averlon.ai, February 2026s