Understanding the React to Shell Vulnerability

On December 3, 2025, a critical vulnerability in React Server Components gave attackers complete server control through a single HTTP request. CVE-2025-55182, dubbed "React2Shell," received a CVSS score of 10.0.

No authentication required, trivial exploitation, full system compromise. Within hours, security firms observed active exploitation by state-sponsored threat groups. Teams running React 19 with Server Components or Next.js 15/16 with App Router faced immediate risk. 

Let’s look at how the vulnerability works, which versions are affected, how to patch it, and how teams have detected exploitation, based on verified reports from AWS, Cloudflare, Wiz, and Palo Alto Unit 42.

What Is the React to Shell Vulnerability?

CVE-2025-55182 is an unsafe deserialization vulnerability in React Server Components. It allows Remote Code Execution (RCE), meaning attackers can run arbitrary commands on your server through a crafted HTTP request. The React Team confirmed that an unauthenticated attacker could send a malicious request to any Server Function endpoint that, when deserialized by React, achieves remote code execution.

Security researchers at Wiz reported near-100% exploitation reliability against default configurations. A blank Next.js application created with create-next-app and built for production could be exploited with no code changes by the developer.

Why It's Considered One of the Most Critical Vulnerabilities Ever

CVSS 10.0 scores are rare. They require network exploitability without authentication, low attack complexity, and maximum impact on confidentiality, integrity, and availability. CVE-2025-55182 met all criteria.

According to HackerOne, this vulnerability became the #1 most exploited CVE across their entire platform within days of disclosure. Wiz data indicates that 39% of cloud environments contain instances of Next.js or React in vulnerable versions. Early estimates suggest more than 12 million websites may be affected.

For comparison, Log4Shell in 2021 also scored CVSS 10.0 and similarly triggered immediate widespread exploitation. React2Shell matches that severity: massive adoption, trivial exploitation, and complete server compromise.

How It Affects Applications Using React Server Components

The vulnerability exists in React Server Components (RSC) and the Flight protocol used for client-server communication. You are affected if you use:

• React 19.0.0, 19.1.0, 19.1.1, or 19.2.0 with Server Components

• Next.js 15.x or 16.x with App Router (which uses RSC by default)

• Next.js canary builds 14.3.0-canary.77 or later

• Other frameworks using RSC: React Router (RSC mode), Waku, RedwoodSDK, Parcel RSC plugin, Vite RSC plugin

You are NOT affected if you use:

• Traditional client-side React without Server Components

• Next.js Pages Router exclusively

• Next.js 13.x or stable 14.x releases (before canary.77)

• Any application not using a framework or bundler that supports React Server Components

How the Vulnerability Worked

The Exploit Surface: React Server Function Endpoints

React Server Components use a serialization protocol called Flight to communicate between client and server. When a client calls a server function, it sends serialized data representing the function call and arguments. The server deserializes this data and executes the function.

The vulnerability existed in how the React Server packages handled HTTP requests for Server Function endpoints. The deserialization flaw allowed attacker-controlled data to influence server-side execution when processing crafted payloads.

Decoding the Payload and Remote Code Execution

The attack chain worked as follows:

1. Attacker sends a crafted HTTP request to an RSC endpoint.

2. The server deserializes the payload using vulnerable React packages.

3. Specially structured data triggers code execution during deserialization.

4. Attacker gains arbitrary code execution with the application's permissions.

Datadog confirmed that exploitation is straightforward, including against blank applications created by create-next-app using default templates. The vulnerability affects applications even without explicit Server Function endpoints.

Anatomy of the Attack: Unsafe Deserialization

The core issue is unsafe deserialization in the RSC Flight protocol. React Server Components expected structured metadata from the client, but vulnerable versions trusted attacker-controlled input without proper validation. This enabled attackers to inject unexpected object types into the deserializer.

The flaw runs deep within the React server runtime. A bypass at this layer means complete application control, including OS-level access in containerized deployments.

Timeline: Discovery and Disclosure

Responsible Disclosure by Lachlan Davidson

Security researcher Lachlan Davidson discovered the vulnerability and reported it privately to the React Team on November 29, 2025. He followed responsible disclosure practices, allowing vendors time to develop patches before public announcement. Davidson later created react2shell.com to provide official information about the vulnerability.

Public Disclosure on December 3, 2025

The React Team and Vercel coordinated the public disclosure on December 3, 2025, simultaneously releasing patches and security advisories. CVE-2025-55182 was assigned to the React vulnerability. Next.js initially tracked the issue as CVE-2025-66478, though the National Vulnerability Database later rejected this as a duplicate.

Within hours of disclosure, working proof-of-concept exploits became public. Lachlan Davidson released an official PoC on December 4, 2025.

Affected Frameworks and Libraries

React Server DOM Packages

The vulnerability affects these React packages in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0:

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

Next.js and Related Toolchains

Next.js versions affected:

• 15.0.0 through 15.5.6

• 16.0.0 through 16.0.6

• Canary builds 14.3.0-canary.77 and later

Next.js 13.x, stable 14.x releases, and Pages Router applications are NOT affected. The Edge Runtime is also not affected.

Other Frameworks and Bundlers

Other affected frameworks and plugins (update to latest versions):

• React Router: Update react, react-dom, react-server-dom-parcel, react-server-dom-webpack, @vitejs/plugin-rsc

• Waku: npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

• RedwoodSDK: Ensure rwsdk>=1.0.0-alpha.0

• @parcel/rsc: Update react-server-dom-parcel to latest

• @vitejs/plugin-rsc: npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

• Expo: See expo.dev/changelog for mitigation steps

React Patched Versions

The React Team released multiple rounds of patches. The current safe versions are:

• React 19.0.3 (or 19.0.1 for initial RCE fix only)

• React 19.1.4 (or 19.1.2 for initial RCE fix only)

• React 19.2.3 (or 19.2.1 for initial RCE fix only)
  

Note: Versions 19.0.2, 19.1.3, and 19.2.2 contained incomplete fixes for related DoS vulnerabilities (CVE-2025-55184, CVE-2025-67779). Update to 19.0.3, 19.1.4, or 19.2.3 for complete protection.

Update commands:

npm install react@19.2.3 react-dom@19.2.3 # or for specific release lines npm install react@19.0.3 react-dom@19.0.3

Next.js Patched Versions

Patched Next.js versions by release line (includes fixes for all related CVEs):

npm install next@14.2.35  npm install next@15.0.7 npm install next@15.1.11 npm install next@15.2.8  npm install next@15.3.8  npm install next@15.4.10 npm install next@15.5.9  npm install next@16.0.10

# for 13.3.x, 13.4.x, 13.5.x, 14.x # for 15.0.x # for 15.1.x### # for 15.2.x # for 15.3.x # for 15.4.x # for 15.5.x # for 16.0.x

If you're on next@14.3.0-canary.77 or later canary, downgrade to stable 14.x:

npm install next@14

WAF Protections from Cloud Providers

Vercel, Cloudflare, AWS, and Google Cloud deployed WAF rules blocking known exploit payloads:

• Vercel: Automatic runtime-level protection for hosted applications

• Cloudflare: Rules in Free Managed Ruleset and Cloudflare Managed Ruleset (default action: Block)

• AWS: WAF AWSManagedRulesKnownBadInputsRuleSet version 1.24+ includes CVE-2025-55182 rules

These protections are stopgaps. Patching remains mandatory.

Real-World Impact

Multiple security firms confirmed active exploitation beginning December 4-5, 2025:

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

• AWS Threat Intelligence: Detected exploitation attempts within hours of disclosure by China state-nexus groups including Earth Lamia and Jackpot Panda.

• Cloudflare: Observed scanning and active exploitation attempts, including traffic from Asian-nexus threat groups.

• Palo Alto Unit 42: Identified activity linked to CL-STA-1015, an initial access broker with suspected ties to PRC's Ministry of State Security.

Similar Severity to Log4Shell

CVE-2025-55182 shares characteristics with Log4Shell (CVE-2021-44228):

• Both scored CVSS 10.0

• Both enabled unauthenticated RCE

• Both affected massive ecosystems

• Both saw exploitation within hours of disclosure

React2Shell has simpler exploitation (single HTTP request) but narrower scope (only RSC-enabled applications versus Log4Shell's broader Java ecosystem).

Related CVEs

The React Team identified and patched additional vulnerabilities in the same disclosure period:

• CVE-2025-55183: Source Code Exposure (CVSS 5.3) - Medium severity

• CVE-2025-55184: Denial of Service (CVSS 7.5) - High severity

• CVE-2025-67779: Additional DoS case found after initial patches

All should be addressed by updating to the latest patched versions (19.0.3, 19.1.4, 19.2.3).

Lessons Learned and Security Best Practices

Every major vulnerability teaches something. React2Shell reinforced patterns that security teams already know but often deprioritize under shipping pressure. Here's what matters most.

Coordinated Disclosure Works

The React Team, Vercel, and Lachlan Davidson executed coordinated disclosure effectively. Patches were available when the vulnerability became public. This gave defenders a head start, though exploitation still began within hours.

Keeping Dependencies Updated

This vulnerability reinforces the need for rapid dependency updates:

• Configure automated tools like Dependabot or Renovate for security updates.

• Prioritize critical security patches for same-day or next-day deployment.

• Monitor official security advisories from React, Next.js, and your framework vendors.

• Subscribe to security mailing lists for immediate notification.

Defense in Depth

Patches are necessary but insufficient alone. Deploy WAF rules as an additional layer. Use runtime protection tools like Sysdig, Aqua, or Prisma Cloud. Implement network segmentation and least privilege principles. Log RSC endpoint requests and alert on anomalous patterns.

Your Next Move

CVE-2025-55182 hit hard because it combined everything that makes a vulnerability dangerous: trivial exploitation, massive adoption, and full server compromise. If you're running React Server Components, check your versions today. The security community responded well this time. Coordinated disclosure, same-day patches, WAF rules deployed within hours. But the window between patch availability and active exploitation was measured in hours, not days. Organizations that moved fast stayed safe. Those that waited became targets. This won't be the last CVSS 10.0. The teams that survive these events share common habits: they track security advisories, they patch critical vulnerabilities within 24 hours, and they don't rely on any single layer of defense. Build those habits now.

You can also connect with us to review your RSC setup, apply patches correctly, check for compromise, or build secure React and Node.js applications from the ground up.

Frequently Asked Questions

How do I check if my React app is vulnerable?

Check your React version:

Vulnerable versions: 19.0.0, 19.1.0, 19.1.1, 19.2.0 (and intermediate patches 19.0.1, 19.0.2, 19.1.2, 19.1.3, 19.2.1, 19.2.2 for related CVEs).

For Next.js, check if you use App Router (app directory). Pages Router applications are not affected. Client-side-only React without Server Components is not affected.

Which React versions are vulnerable (exact numbers)?

Vulnerable React packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack):

• 19.0.0, 19.1.0, 19.1.1, 19.2.0 (CVE-2025-55182 RCE)

• 19.0.1, 19.0.2, 19.1.2, 19.1.3, 19.2.1, 19.2.2 (still vulnerable to CVE-2025-55184/CVE-2025-67779 DoS)

Safe versions: 19.0.3, 19.1.4, 19.2.3

What are the step-by-step patching instructions for Next.js?

1. Update Next.js to patched version for your release line:

2. Update React packages:

3. Clear build cache:

4. Rebuild and test:

5. Deploy with monitoring enabled6. If on canary 14.3.0-canary.77+, downgrade to stable:

Does this vulnerability affect React apps without Server Components?

No. Traditional client-side React applications are not affected. Next.js Pages Router applications are not affected. The vulnerability exists specifically in React Server Components' Flight protocol deserialization. If your application doesn't use a framework or bundler that supports RSC, you're not affected.

How long does it take to patch this in production?

The npm update takes 5-10 minutes. With build, testing, and staged rollout:

• Simple applications: 30-60 minutes

• Complex applications with extensive test suites: 1-2 hours

• Organizations with formal change management: Follow expedited critical security patch procedures

Given active exploitation, prioritize speed while maintaining basic testing.

What if I can't update immediately?

Temporary mitigations: enable WAF rules from your CDN provider. If on Vercel, runtime protections are automatic. Patch as soon as possible.

Temporary mitigations:

• Enable WAF rules from Cloudflare, AWS, or your CDN provider

• If hosted on Vercel, runtime protections are automatically applied

• Disable Server Components if your application allows (significant code changes)

• Implement network-level blocking of suspicious RSC request patterns

These are stopgaps. Exploitation attempts are ongoing. Patch as soon as possible.

How do I detect if my server was already compromised?

Forensic checklist:

• Review server logs for unusual RSC endpoint requests (look for $ACTION_REF, $ACTION parameters with suspicious payloads)

• Check for unexpected processes (crypto miners, reverse shells)

• Examine outbound network traffic for unknown hosts

• Scan for unauthorized file changes, new user accounts, or SSH keys

• Review cloud metadata access logs

If you suspect compromise, engage incident response specialists.

What AWS/Vercel/Cloudflare configurations help prevent exploitation?

• Vercel: Automatic runtime-level protection deployed for all hosted applications.

• Cloudflare: Enable Cloudflare Managed Ruleset or Free Managed Ruleset (rules enabled by default with Block action).

• AWS: Use AWS WAF with AWSManagedRulesKnownBadInputsRuleSet version 1.24 or higher.

• Google Cloud: Cloud Armor rules available for CVE-2025-55182.

• These complement but do not replace patching.

How does this compare to Log4Shell?

Both scored CVSS 10.0, both enabled unauthenticated RCE, both triggered immediate exploitation. Log4Shell affected broader ecosystem (any Java application using Log4j). React2Shell has simpler exploitation but narrower scope. Both demanded same-day patching.

Are there public exploits available?

Yes. Working PoCs were published within 30 hours of disclosure. Assume attackers have reliable exploit code.