React2Shell: Inside the Critical CVE-2025-55182 Vulnerability That Has Hackers Exploiting React Apps Within Hours

A deep dive into the CVSS 10.0 vulnerability shaking the JavaScript ecosystem—and how to protect yourself

The Day React Got Owned

On December 3, 2025, the React team dropped a security advisory that sent shockwaves through the web development world. A critical vulnerability—CVE-2025-55182—had been discovered in React Server Components, the cutting-edge feature that powers modern React applications. The vulnerability earned a perfect CVSS score of 10.0, the highest possible severity rating.

React2Shell (CVE-2025-55182): The CVSS 10.0 RCE Shaking the JavaScript Ecosystem

December 6, 2025 | Critical Security Advisory Executive Summary The JavaScript ecosystem is facing one of its most severe security crises in recent memory. CVE-2025-55182, dubbed “React2Shell” by security researchers, is a maximum-severity (CVSS 10.0) remote code execution vulnerability affecting React Server Components that allows unauthenticated attackers to execute arbitrary

Breached CompanyBreached Company

Within hours of public disclosure, Amazon's threat intelligence teams observed active exploitation attempts by multiple China state-nexus threat groups. The vulnerability, dubbed "React2Shell" by security researchers, enables unauthenticated remote code execution—meaning attackers can run arbitrary code on your server without needing any login credentials whatsoever.

If you're running React 19.x or Next.js 15.x/16.x with Server Components, this article is required reading. And yes, this vulnerability is actively being exploited in ransomware campaigns.

What Exactly Is CVE-2025-55182?

The TL;DR

CVE-2025-55182 is an unsafe deserialization vulnerability in React Server Components that allows unauthenticated attackers to achieve remote code execution (RCE) on any vulnerable server. The flaw exists in how React decodes payloads sent to React Server Function endpoints.

The Scary Part

Here's what makes this vulnerability particularly dangerous: your application may be vulnerable even if you don't explicitly use Server Functions. If your app supports React Server Components at all, you could be at risk.

Affected Components

The vulnerability is present in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages:

Vulnerability Details at a Glance

Understanding Deserialization Vulnerabilities: A Beginner's Guide

Before we dive deeper into React2Shell, let's understand what deserialization vulnerabilities are and why they're so dangerous.

What Is Serialization?

When your application needs to send complex data structures (like objects) over a network or store them, it first converts them into a format that can be easily transmitted or stored. This process is called serialization—think of it as packing your belongings into boxes for moving.

Deserialization is the reverse process—unpacking those boxes and reconstructing the original objects.

Why Deserialization Is Dangerous

Here's where things get spicy. When your server deserializes data, it's essentially reconstructing objects based on instructions it receives. If an attacker can control those instructions, they can make the server create malicious objects that execute arbitrary code.

Imagine if the moving company unpacked your boxes and built whatever furniture the label said to build—even if the label said "build a bomb." That's essentially what happens with unsafe deserialization.

The React Server Components Context

React Server Components (RSC) allow developers to run React components on the server, sending only the rendered HTML and minimal JavaScript to the client. When clients interact with Server Functions, they send serialized requests to the server.

In CVE-2025-55182, the way React decodes these incoming payloads is flawed. An attacker can craft a malicious HTTP request that, when deserialized by React, executes arbitrary code on the server.

Technical Analysis: How React2Shell Works

The Attack Flow

1. Reconnaissance: Attacker identifies a target running vulnerable React Server Components
2. Payload Crafting: Attacker creates a malicious serialized payload
3. Delivery: Attacker sends the payload via HTTP POST to a Server Function endpoint
4. Deserialization: The server's React runtime deserializes the malicious payload
5. Code Execution: Arbitrary code executes with server-level privileges
6. Compromise: Attacker gains full control of the application server

Identifying Vulnerable Endpoints

According to AWS threat intelligence, attackers are looking for specific indicators:

HTTP Headers to Watch:

• POST requests with next-action headers
• Requests containing rsc-action-id headers

Suspicious Payload Patterns:

• Request bodies containing $@ patterns
• Request bodies containing "status":"resolved_model" patterns

What Attackers Are Doing Post-Exploitation

Based on honeypot data from AWS's MadPot infrastructure, here's what threat actors do immediately after gaining access:

# Reconnaissance commands observed
whoami
id
uname -a
cat /etc/passwd

# Persistence attempts
echo "pwned" > /tmp/pwned.txt

One threat cluster was observed spending 52 minutes systematically troubleshooting exploitation attempts, demonstrating that attackers are actively debugging and refining their techniques against live targets.

Who's Exploiting This? Meet Earth Lamia and Jackpot Panda

The Speed of Exploitation

Amazon's threat intelligence teams observed active exploitation within hours of the public disclosure on December 3, 2025. This rapid weaponization isn't unusual for critical vulnerabilities—sophisticated threat actors monitor disclosure channels 24/7 and have infrastructure ready to operationalize exploits immediately.

Identified Threat Groups

Earth Lamia

• China-nexus cyber threat actor
• Known for exploiting web application vulnerabilities
• Targets: Financial services, logistics, retail, IT companies, universities, government organizations
• Geographic focus: Latin America, Middle East, Southeast Asia

Jackpot Panda

• China-nexus cyber threat actor
• Primarily targets entities in East and Southeast Asia
• Activity likely aligned with domestic security and corruption concerns

The Attribution Challenge

AWS noted that definitive attribution is challenging due to shared anonymization infrastructure among Chinese threat groups. Large-scale anonymization networks have become a defining characteristic of Chinese cyber operations, enabling reconnaissance, exploitation, and command-and-control activities while obscuring attribution.

Known Threat Actor Infrastructure

These IP addresses have been linked to CVE-2025-55182 exploitation:

The Ransomware Connection

CISA's Warning

CISA added CVE-2025-55182 to its Known Exploited Vulnerabilities (KEV) catalog on December 5, 2025, just two days after public disclosure. What makes this entry particularly alarming is the explicit note:

"Known To Be Used in Ransomware Campaigns? Known"

This isn't speculation—this vulnerability is actively being used by ransomware operators.

Why React Makes an Attractive Target for Ransomware

1. Ubiquity: React powers millions of web applications worldwide
2. Server Access: Unlike client-side JavaScript vulnerabilities, React2Shell gives attackers server-side access
3. Data Rich Environments: React applications often connect to valuable databases and internal systems
4. Corporate Targets: Next.js and React Server Components are heavily used in enterprise environments

The Federal Mandate

Under CISA's Binding Operational Directive (BOD) 22-01, federal agencies were given until December 12, 2025—just one week—to either apply mitigations, follow applicable guidance for cloud services, or discontinue use of vulnerable products.

This aggressive timeline underscores the severity of the threat.

Affected Frameworks and Bundlers

React Server Components don't exist in isolation—they're typically used through frameworks. Here's what's affected:

Next.js (Most Common)

Next.js is the most popular React framework and heavily utilizes Server Components with App Router. All versions from 13.3.x through 16.x are affected.

Patched Versions:

npm install next@14.2.35  # for 13.3.x, 13.4.x, 13.5.x, 14.x
npm install next@15.0.8   # for 15.0.x
npm install next@15.1.12  # for 15.1.x
npm install next@15.2.9   # for 15.2.x
npm install next@15.3.9   # for 15.3.x
npm install next@15.4.11  # for 15.4.x
npm install next@15.5.10  # for 15.5.x
npm install next@16.0.11  # for 16.0.x
npm install next@16.1.5   # for 16.1.x

React Router

If you're using React Router's unstable RSC APIs, you need to update immediately:

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

Other Affected Tools

• Waku: Lightweight React framework with RSC support
• @parcel/rsc: Parcel bundler's RSC integration
• @vitejs/plugin-rsc: Vite's RSC plugin
• rwsdk (Redwood SDK): Redwood framework's SDK

How to Protect Yourself: Step-by-Step Mitigation

Immediate Actions (Do These Right Now)

1. Check If You're Affected

Run this command in your project directory:

npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

If you see versions 19.0.0, 19.1.0, 19.1.1, or 19.2.0, you're vulnerable.

2. Update Your Dependencies

For the core React packages:

npm install react@latest react-dom@latest
npm install react-server-dom-webpack@latest  # if using webpack
npm install react-server-dom-parcel@latest   # if using parcel
npm install react-server-dom-turbopack@latest # if using turbopack

3. Verify the Fix

After updating, confirm you're on patched versions:

• 19.0.1 or later
• 19.1.2 or later
• 19.2.1 or later

WAF Protection (Defense in Depth)

If you're using AWS WAF, ensure you have the AWSManagedRulesKnownBadInputsRuleSet version 1.24 or higher enabled.

For custom WAF rules, look for:

• POST requests with next-action or rsc-action-id headers
• Request bodies containing $@ patterns

Network-Level Detection

If you're using AWS Network Firewall, consider this custom rule to detect post-exploitation behavior:

reject http $HOME_NET any -> any !80 (
  http.host; 
  content:"."; 
  pcre:"/^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$/"; 
  msg:"Direct to IP HTTP on non-standard port"; 
  flow:to_server; 
  sid:2025121801;
)

This blocks HTTP connections made directly to IP addresses on non-standard ports—a common pattern in post-exploitation malware downloads.

Detection: How to Know If You've Been Compromised

Log Analysis

Check your web server and application logs for:

Suspicious HTTP Patterns:

• High volume of POST requests to your application endpoints
• Requests with unusual next-action or rsc-action-id header values
• Request bodies containing the $@ pattern or "status":"resolved_model"

Host-Based Indicators of Compromise (IOCs)

Look for these on your application servers:

Reconnaissance Activity:

• Unexpected execution of whoami, id, uname commands
• Attempts to read /etc/passwd
• Process tree showing commands spawned from Node.js processes

Persistence Attempts:

• New files in /tmp/ directory (especially pwned.txt or similar test files)
• Unexpected cron jobs or systemd services
• Modified SSH authorized_keys files

Forensic Commands

# Check for suspicious processes spawned by Node
ps aux | grep node

# Look for recently modified files in temp directories
find /tmp -mtime -1 -type f

# Check for unauthorized SSH keys
cat ~/.ssh/authorized_keys
cat /root/.ssh/authorized_keys

# Review recent command history (if available)
last
lastlog

The Bigger Picture: Why This Matters

The JavaScript Ecosystem's Growing Attack Surface

React Server Components represent a fundamental shift in how React applications work. Instead of all JavaScript running in the browser, critical logic now executes on the server. This paradigm shift creates new attack surfaces that the security community is still learning to defend.

Consider the evolution:

• Before RSC: JavaScript vulnerabilities mostly meant XSS and client-side attacks. The worst that could happen was stealing cookies or defacing a page.
• After RSC: JavaScript vulnerabilities can now mean full server compromise. Attackers can access databases, steal API keys, pivot to internal networks, and deploy ransomware.

This isn't just a React problem—it's a fundamental shift in the JavaScript security model. The language that was once "sandboxed" in browsers is now running on servers with access to everything.

Supply Chain Implications

React is one of the most used JavaScript libraries globally. According to npm, react has over 25 million weekly downloads. When a vulnerability this critical hits React, the blast radius is enormous:

• Fortune 500 companies running customer-facing applications
• Government agencies with citizen-facing portals
• Healthcare systems with patient data
• Financial institutions processing transactions
• E-commerce platforms handling payment information
• Startups building on Next.js (the most popular React framework)

Consider this: if just 1% of React applications using Server Components were vulnerable and exploited, we're talking about potentially tens of thousands of compromised servers.

Why This Will Happen Again

CVE-2025-55182 won't be the last critical vulnerability in server-side JavaScript. Here's why:

1. Complexity Breeds Bugs
React Server Components involve complex serialization between client and server. The more complex the data handling, the more opportunities for vulnerabilities.

2. New Territory
Server-side React is still relatively new. Unlike Node.js (which has been battle-tested for over a decade), RSC patterns are still evolving—and so is the security research around them.

3. Speed Over Security
The JavaScript ecosystem moves fast. New features ship quickly, and security reviews can't always keep pace. The rush to adopt exciting new patterns like Server Components means organizations deploy before security implications are fully understood.

The Patching Race

The timeline of this vulnerability illustrates the modern security challenge:

• November 29: Vulnerability reported to Meta
• November 30: Confirmed and fix work begins
• December 1: Fix created, coordinated with hosting providers
• December 3: Public disclosure
• December 3 (within hours): Active exploitation begins
• December 5: CISA adds to KEV
• December 12: Federal compliance deadline

Defenders have days—or hours—to patch before attackers are already inside. This timeline is becoming the norm, not the exception.

Lessons for JavaScript Developers

1. Treat Server-Side JS Like Any Other Backend
Just because it's JavaScript doesn't mean it gets a pass on security. Apply the same rigor you would to Java, Python, or Go backends: input validation, secure deserialization, principle of least privilege.

2. Monitor Your Dependencies
Use tools like npm audit, Snyk, or Dependabot. Subscribe to security advisories for your frameworks. The React team published their advisory within days—but you need to be watching for it.

3. Defense in Depth
WAF rules, network segmentation, and monitoring aren't optional. Even if you patch immediately, having multiple layers of defense buys you time when the next zero-day drops.

4. Have an Incident Response Plan
If you woke up on December 4th and realized you were vulnerable, did you know what to do? Who to call? How to assess impact? The time to figure this out is before the breach, not during.

Related Vulnerability: CVE-2025-66478

You may see references to CVE-2025-66478 in relation to this vulnerability. According to CISA and the NVD, CVE-2025-66478 has been rejected but is associated with CVE-2025-55182.

This sometimes happens when:

• Duplicate CVE IDs are assigned to the same vulnerability
• A CVE is initially assigned but later merged with another
• Additional research shows the vulnerability is the same root cause

For practical purposes, focus on CVE-2025-55182—it's the canonical identifier for this vulnerability.

Key Takeaways

For Developers

1. Update immediately if you're running any React Server Components packages
2. Don't assume you're safe just because you don't use Server Functions explicitly
3. Enable security scanning in your CI/CD pipeline to catch vulnerable dependencies
4. Monitor the React security blog for future advisories

For Security Teams

1. Inventory all React applications in your organization
2. Prioritize patching based on internet exposure and data sensitivity
3. Implement WAF rules as a defense-in-depth measure
4. Hunt for IOCs in your logs—exploitation may have already occurred

For Everyone

This vulnerability is a reminder that:

• Server-side JavaScript is now part of the threat landscape
• Deserialization vulnerabilities remain extremely dangerous
• The time between disclosure and exploitation is shrinking
• Framework popularity creates attractive targets for attackers

Resources

Official Advisories:

• React Team Security Advisory
• CISA KEV Entry
• NVD Entry
• AWS Security Blog: Threat Intelligence

Framework-Specific Updates:

• Next.js Security Update
• Expo Mitigation Guide
• Waku Announcement

Learn More About Deserialization Vulnerabilities:

• OWASP: Deserialization Cheat Sheet
• CWE-502: Deserialization of Untrusted Data

Timeline

Credits

This vulnerability was discovered and responsibly disclosed by Lachlan Davidson via Meta's Bug Bounty program. Security researcher attribution matters—responsible disclosure helps keep the entire ecosystem safer.

Stay safe out there. Patch your React apps.