What is React2Shell and how it impacts Next.js and React ecosystem

The React ecosystem just experienced its most severe security incident in years.

On December 4th, 2025, publicly available exploits emerged for React2Shell—a critical vulnerability in React Server Components that allows attackers to execute arbitrary code on your server. If you’re running Next.js 15 or 16, your application may be at risk right now. This is a 10.0/10.0 CVE that demands immediate action.

Initial discovery, disclosure, and impact

Security researcher Lachlan Davidson discovered a fundamental flaw in how React’s Flight protocol handles incoming data. After 100 hours of painstaking research, he found a way to trick React into executing malicious code by exploiting JavaScript’s inherently dynamic nature.

The vulnerability affects React 19 and any framework using React Server Components, most notably Next.js versions 15.0.0 through 16.0.6. Within 30 hours of the initial patch appearing on GitHub, other researchers had already reverse-engineered working exploits. The window for attackers was wide open.

React2Shell Vulnerability Class

React Server Components (RSC) represent a fundamental shift in how React applications work. They blur the line between client and server, streaming complex data structures to build UIs as fast as possible. This power comes with responsibility, and in this case, that responsibility was overlooked.

The Flight protocol is what makes RSC tick. Think of it as a specialised communication format that can represent not just static data, but promises, references, and other JavaScript constructs. It’s like JSON on steroids. And that power became its weakness.

The core problem is deceptively simple: React trusted user input too much.

When parsing incoming Flight data, React failed to distinguish between legitimate user objects and its own internal state structures. An attacker could craft a malicious payload that looked like React’s internal bookkeeping, gaining access to mechanisms that should never be exposed.

The Technical Heart of the Exploit

JavaScript has a feature called “duck typing”; if something looks like a duck and quacks like a duck, JavaScript treats it as a duck. If an object has a then method, JavaScript considers it a Promise. This seemingly innocent language feature became the entry point for the attack.

The exploit works by chaining together several JavaScript quirks:

Promise Confusion: By including a then property in malicious data, attackers could make React treat their payload as a Promise and call .then() on it.
Reference Hijacking: Flight uses a colon syntax ($1:then) to reference objects. This was intended for user data only, but attackers used it to access JavaScript’s internal machinery—including the constructor property that gives access to the Function constructor.
Code Execution: Once attackers reached Function.constructor, they could create and execute arbitrary JavaScript on your server. Game over.

The payload that achieves all this is disturbingly compact - just a few lines of JSON-like structure that, when processed by a vulnerable server, gives attackers complete control.

The CVE Landscape

This incident spawned multiple related vulnerabilities:

CVE-2025-55182 — The original React2Shell vulnerability. Critical severity (10.0/10.0). Enables remote code execution through maliciously crafted HTTP requests to any App Router endpoint.

CVE-2025-66478 — The corresponding Next.js vulnerability. Same critical severity and impact.

CVE-2025-55184 — A follow-up Denial of Service vulnerability discovered after the initial disclosure. High severity. Malicious requests can cause server processes to hang and consume CPU.

CVE-2025-55183 — Source code exposure vulnerability. Medium severity. Attackers can retrieve compiled source code of Server Actions, potentially revealing business logic.

CVE-2025-67779 — Found when the initial DoS fix proved incomplete. Everyone must update to the latest patched versions.

This cascade of related vulnerabilities illustrates a crucial point: critical CVEs often lead to follow-ups. Once researchers know where to look, they find more problems. The security community’s continued testing has strengthened the ecosystem, but it also means you need to stay current with patches.

Immediate Actions Required

If you’re running Next.js 15.0.0 through 16.0.6, stop reading and upgrade now.

Here’s what you need to do:

1. Check Your Version

Run next.version in your browser console or check your package.json. If you’re in the vulnerable range, you’re at risk.

2. Upgrade Immediately

Vulnerable Version	Patched Release
Next.js 15.0.x	15.0.7
Next.js 15.1.x	15.1.11
Next.js 15.2.x	15.2.8
Next.js 15.3.x	15.3.8
Next.js 15.4.x	15.4.10
Next.js 15.5.x	15.5.9
Next.js 16.0.x	16.0.10

You can use Vercel’s automated tool:

npx fix-react2shell-next

3. Deploy Immediately

Don’t wait for your next sprint. Don’t bundle it with other changes. Deploy the security patch now.

4. Rotate Your Secrets

If your application was online and unpatched between December 4th and when you applied the fix, assume compromise. Rotate all environment variables and secrets, starting with the most critical ones.

5. Protect Preview Deployments

Even if your production app is patched, older preview deployments could still be vulnerable. Enable deployment protection for all non-production environments.

Best Practices for the Future

This vulnerability reinforces timeless security principles:

Never trust user input. This applies even when that input is being parsed by battle-tested libraries. The Flight protocol assumed incoming data would be well-formed user objects. It wasn’t.

Keep dependencies updated. The fix was available before the exploits went public. Teams that had good update hygiene were protected. Those that didn’t were vulnerable.

Implement defence in depth. Vercel’s WAF rules blocked known exploit patterns even before patches were applied. While WAF rules cannot guarantee protection against all variants, they provide a crucial additional layer.

Treat security as ongoing. The follow-up CVEs prove that one patch isn’t enough. Security is a continuous process of monitoring, updating, and adapting.

The Broader Lesson

React Server Components represent a powerful paradigm shift, but they also introduce new attack surfaces. When you blur the boundary between client and server, you must be extraordinarily careful about what crosses that boundary.

This vulnerability wasn’t the result of sloppy coding. It emerged from the intersection of JavaScript’s dynamic nature and a sophisticated protocol designed for performance. The lesson isn’t that RSC is bad; it’s that power features require proportionally robust security measures.

The React and Vercel teams responded swiftly, collaborating with security researchers and deploying protections across the ecosystem. But the initial oversight is a reminder: security must be designed in from the start, not bolted on after.

Sources:

How LiberateWeb Can Help

Navigating security incidents like React2Shell requires experience and attention to detail. At LiberateWeb, we specialise in modern web development with React, Next.js, and TypeScript—the very technologies at the centre of this vulnerability.

We can help you:

Audit your existing applications for vulnerability exposure and patch status
Implement security best practices across your codebase
Upgrade your Next.js applications safely without breaking changes
Set up proper CI/CD pipelines that catch security issues before deployment
Establish monitoring and alerting for future security bulletins

Don’t wait for the next critical CVE to catch you off guard. Whether you need a quick security audit or ongoing development support, we’re here to help businesses build secure, performant web applications.

Book a free consultation to discuss your application’s security posture.