A critical RCE vulnerability dropped this week for React Server Components and Next.js. CVE-2025-55182 and CVE-2025-66478 scored a perfect 10.0, which should tell you everything you need to know about severity. But here’s the part that should really wake you up: default configurations are vulnerable.
You didn’t misconfigure anything. You didn’t make a mistake. You just spun up a standard Next.js app with create-next-app, built it for production, and congratulations—you’re exploitable. No authentication required. Just a crafted HTTP request. 🎯
Welcome to React2Shell.
The Vulnerability That Shouldn’t Exist
The flaw stems from insecure deserialization in the RSC payload handling logic in the React Server Components “Flight” protocol. When your server receives a specially crafted RSC payload, it fails to validate the structure properly. This allows attacker-controlled data to influence server-side execution logic, which is a fancy way of saying: remote code execution with near 100% reliability.
The technical details are being withheld for now (smart move), but what we know is bad enough. The genuine vulnerability affects the core library’s request parsing and does not require manual exposures. This isn’t about you doing something wrong. This is about the framework doing something dangerous by default.
Let’s be clear about what “insecure deserialization” means in practice: your application trusts data it receives from clients. It takes serialized objects from HTTP requests and reconstructs them server-side without proper validation. An attacker sends a malicious payload, your server deserializes it, and suddenly they’re executing arbitrary JavaScript on your server.
This is a fundamental trust boundary violation in the core request handling logic. And it exists in every default deployment.
The Scale of the Problem
Wiz data indicates that 39% of cloud environments contain instances of Next.js or React in versions vulnerable to CVE-2025-55182 and/or CVE-2025-66478. Let that sink in. Nearly 40% of cloud environments.
It gets worse. Next.js is present in 69% of environments, with 61% of those having public applications running Next.js—meaning 44% of all cloud environments have publicly exposed Next.js instances. That’s not counting version specifics. That’s just presence.
More than 968,000 servers running modern frameworks like React and Next.js have been identified, and a significant portion are running vulnerable versions. That’s a massive attack surface that went from “pretty secure” to “remotely exploitable” overnight. ⚠️
Who’s Actually Affected
If you’re running React 19 (versions 19.0.0, 19.1.0, 19.1.1, or 19.2.0) with Server Components, you’re vulnerable. If you’re running Next.js with App Router (versions 14.3.0-canary and up, all of 15.x, all of 16.x), you’re vulnerable.
But it’s not just React and Next.js. Any framework or library bundling the react-server implementation is likely affected, including Vite RSC plugin, Parcel RSC plugin, React Router RSC preview, RedwoodJS, and Waku.
The key phrase here is “React Server Components.” If you’re using RSC—which is the default for Next.js App Router—you’re exposed. Even if your app does not implement any React Server Function endpoints, it may still be vulnerable if your app supports React Server Components.
Translation: you don’t have to be doing anything fancy. Standard setup, default config, you’re exploitable.
Exploitation Is Trivial
No special setup required. No authentication needed. No complex chain of exploitation. An attacker needs only network access to send a crafted HTTP request to any Server Function endpoint.
During testing, researchers achieved near 100% exploit reliability. This isn’t a theoretical vulnerability that’s hard to weaponize. This is point-and-shoot RCE against default configurations. The kind of vulnerability that gets added to automated scanning tools within days.
And make no mistake—it’s already happening. At the time of writing, there were no confirmed public PoC exploits that work against default configs. But that protection window is measured in days, not weeks. Multiple security firms have working exploits. Some are being responsible and withholding details. Others? Well, GitHub already has repositories claiming to be PoCs.
Threat actors are actively seeding repositories with fake PoC scripts that contain malicious payloads. So if you’re thinking about testing this yourself by grabbing a random exploit off GitHub—don’t. You’re more likely to compromise yourself than validate your security posture.
The Problem with Modern Frameworks
Modern JavaScript frameworks have gotten so complex that security vulnerabilities in the core request handling logic can go unnoticed until they’re everywhere.
React Server Components were introduced to improve performance and developer experience. They let you run server-side rendering seamlessly. They handle the complex serialization and deserialization of data between client and server. They abstract away the hard parts.
But that abstraction came with a cost: complex data structures must be converted into a stream of text that can travel over HTTP (serialization), and when the server receives a reply or request, it must reconstruct these objects from the text stream (deserialization).
And apparently, nobody properly validated that the deserialization process was safe. The “Flight” protocol—React’s mechanism for communicating between server and client components—trusted data it shouldn’t have trusted. The vulnerability fundamentally resides in the react-server package and its handling of the RSC “Flight” protocol.
This is a logic flaw. Not a buffer overflow. Not a memory corruption bug. A fundamental design issue in how the framework handles client data.
What You Need to Do Right Now 🔥
Patch immediately. This isn’t a “schedule it for next sprint” situation. This is a “patch in the next 24 hours” situation.
For React, upgrade to version 19.2.1. For Next.js, upgrade to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7 depending on your minor version. For other RSC-enabled frameworks, check their official channels for patched versions and update immediately.
If you can’t patch right away:
Deploy WAF rules if you have them. Cloudflare, AWS, Google Cloud, Akamai, and Fastly have all deployed protections. If your traffic goes through any of these, you have some breathing room—but you still need to patch.
Monitor HTTP traffic to Server Function endpoints for suspicious or malformed requests. Look for unusual POST requests with multipart data. Watch for 500 errors with specific error signatures.
Consider temporarily restricting network access to affected applications if they’re not public-facing critical services. Sometimes the best defense is not being reachable.
Don’t try to verify the vulnerability yourself with random GitHub exploits. The original author of this vulnerability confirms that PoCs on GitHub are not the same exploit that was shared with React and Next.js maintainers. Some are fake, some are incomplete, and some are actively malicious.
The Bigger Picture
This vulnerability is a wake-up call about framework security. We’ve gotten comfortable trusting that popular, widely-used frameworks have been thoroughly vetted. That Facebook (Meta) maintains React, so it must be secure. That millions of developers use Next.js, so surely someone would have noticed a critical RCE in the default configuration.
But here we are. CVSS 10.0. Default vulnerable. Nearly 40% of cloud environments exposed. Almost a million servers at risk.
The modern web development ecosystem moves fast. New features get added. Abstractions get layered on top of abstractions. Server-side rendering, client-side hydration, server components, server actions—each new feature increases complexity and expands the attack surface.
And security review? That struggles to keep pace. In 2024, according to the State of JavaScript survey, React was used by 82% of respondents. When a framework is that ubiquitous, a single vulnerability becomes an ecosystem-wide crisis.
What Attackers Are Thinking
If you’re an attacker right now, you’re salivating. Nearly a million servers, 40% of cloud environments, default vulnerable configurations, no authentication required, 100% exploit reliability. This is the kind of vulnerability that turns into widespread exploitation campaigns.
The race is on: security teams scrambling to patch versus attackers scrambling to exploit before patches are applied. Mass scanning is probably already underway. Exploit code will be refined and released publicly. Botnets will add it to their arsenal.
Within a week, maybe two, this becomes just another vulnerability that automated tools check for. The question is: will your applications still be vulnerable when that happens?
How Did This Happen?
How did a CVSS 10.0 RCE make it into React Server Components? How did it ship in default configurations? How many security reviews happened before React 19 was released? How long was this vulnerability present before Lachlan Davidson found it and responsibly disclosed it on November 29th?
We don’t have good answers. And honestly, we probably won’t get them. What we have is a reminder that no framework is bulletproof. No library is too popular to have critical vulnerabilities. No default configuration is guaranteed to be secure.
Your security posture is only as strong as your ability to respond when the next CVSS 10.0 drops. And it will drop again. Different framework, different vulnerability, same urgency.
Bottom Line
React2Shell is a perfect 10.0 for a reason. Unauthenticated RCE. Default vulnerable. Widespread deployment. Easy exploitation. This checks every box for “patch immediately or suffer the consequences.”
If you’re running React Server Components or Next.js with App Router, you need to patch. Not next week. Not after the next sprint planning. Today. Right now. Stop reading this and go check your versions.
Because the attackers aren’t waiting. The exploit code is coming. And when it drops, every unpatched instance becomes low-hanging fruit.
Don’t be low-hanging fruit.
If you need help assessing whether your applications are vulnerable, validating patches, or responding to potential exploitation, that’s exactly the kind of rapid incident response work I do. Time matters with vulnerabilities like this—let’s not waste it.
