- CVE-2025-55182 in React and CVE-2025-66478 in Next.js allow unauthenticated remote code execution via the React Server Components Flight protocol.
- The flaw stems from unsafe deserialization of RSC payloads, leaving default React and Next.js configurations exposed without any custom code changes.
- Security researchers report near‑100% exploitation reliability and warn that mass attacks are likely as patches are analyzed.
- Immediate upgrades to the hardened React and Next.js releases are the only definitive mitigation, especially in cloud environments where up to ~40% may be vulnerable.
The disclosure of CVE-2025-55182 in React and its twin issue CVE-2025-66478 in Next.js has put a spotlight on how fragile server-side JavaScript stacks can be when low-level protocols go wrong. Instead of being a niche bug, this is a maximum‑severity remote code execution flaw that hits the core of React Server Components and the Flight protocol many modern apps quietly depend on.
What makes this case particularly unsettling is that default setups are exposed. A plain Next.js app generated with create-next-app, built for production and deployed without any unusual options, can be compromised via an unauthenticated HTTP request. No fancy misconfiguration, no exotic plugin — just the standard stack many teams roll out every day.
How CVE-2025-55182 and CVE-2025-66478 were uncovered
The root of the problem lies in the react-server implementation that powers React Server Components (RSC). This package underpins the Flight protocol, which is used to shuttle serialized component data between client and server. When security researcher Lachlan Davidson reported suspicious behavior through Meta’s bug bounty program in late November, it set off a rapid response from the React and Meta teams.
According to public advisories, the vulnerability was disclosed on a Wednesday and emergency patches were shipped within about four days. That is an unusually fast turnaround for an issue affecting such a large ecosystem, and it underscores how severe the flaw is: React’s maintainers rated it with a CVSS score of 10.0, the maximum possible.
In parallel, Vercel — the company behind Next.js — analyzed how the same underlying bug impacted its framework. Because Next.js uses the same RSC Flight protocol on the server, it inherited the weakness and was assigned its own identifier, CVE-2025-66478. Vercel issued an alert and released patches on the same day as the React advisory, aiming to keep the window of opportunity for attackers as short as possible.
Despite the quick reaction, security vendors and researchers started warning that attackers would likely reverse engineer the fixes very quickly, as seen in supply-chain attacks against npm. Once the patched code is public, it becomes much easier to infer where the bug was and to build working exploits.
What exactly is going wrong in the React Flight protocol?
At the technical level, both CVE-2025-55182 and CVE-2025-66478 boil down to unsafe deserialization of attacker-controlled data within the Flight protocol. React Server Components send and receive structured payloads, which the server then decodes and uses to drive execution flow.
The vulnerable logic in the react-server package failed to strictly validate the structure and content of incoming RSC payloads. By sending a deliberately malformed, but carefully crafted, Flight payload to a React Server Function endpoint, an attacker can influence what the server does when it deserializes that data. Instead of simply reconstructing benign component state, the code path can be steered into executing privileged JavaScript on the server.
Because the bug affects how the protocol is decoded, no authentication is required. A remote attacker only needs to be able to send HTTP requests to any reachable RSC or Server Function endpoint. This turns the vulnerability into a straightforward, unauthenticated RCE vector: send a crafted request, wait for the unsafe deserialization, and the payload can end up executing on the backend.
Researchers from Wiz, who independently analyzed the issue, describe it as a logical deserialization vulnerability rather than a simple parsing bug. In their testing, a fully working proof‑of‑concept exploit achieved near‑100% reliability in triggering code execution on vulnerable targets.
Why default React and Next.js deployments are at risk
One of the most worrying aspects of these CVEs is that they affect out‑of‑the‑box configurations. For many security problems, exploitation requires a specific feature flag, a rarely used plugin, or a non‑standard deployment mode. That is not the case here.
React Server Components and their Flight protocol have become integral parts of modern React 19 and Next.js architectures. As a result, a standard production build generated by create-next-app can be exploitable with zero additional code from the application developer. There is no need for the attacker to guess custom routes or business logic; abuse of the generic RSC endpoints is enough.
The flaw is not limited to Next.js itself. Any framework or tool that bundles or re‑implements the RSC Flight protocol on the server may be vulnerable. Public advisories and security write‑ups highlight several affected ecosystems:
- Next.js, the best‑known framework affected downstream
- Vite RSC plugin (
@vitejs/plugin-rsc) - Parcel RSC plugin (
@parcel/rsc) - React Router RSC preview
- RedwoodSDK (often referenced as
rwsdk) - Waku and other RSC‑enabled toolchains
In React itself, the bug impacts versions 19.0, 19.1.0, 19.1.1 and 19.2.0 of the relevant packages. The maintainers state that upgrading to 19.0.1, 19.1.2 or 19.2.1 provides hardened behavior and removes the vulnerability. Next.js has corresponding fixed releases that integrate the patched React server logic.
Some infrastructure providers have clarified the boundaries of impact. For instance, Google has stated that public OS images for Compute Engine are not vulnerable by default, since they do not ship React or Next.js ready‑made; the risk emerges when users deploy affected versions of those frameworks on top of the base images.
How big is the blast radius across the cloud?
The scale of the issue comes into focus when looking at how widely React and Next.js are used in production. React underpins user interfaces for major platforms such as Facebook, Instagram, Netflix, Airbnb, Shopify, Walmart, Asana and many others. On top of that, countless smaller apps and internal dashboards are built with the same components and frameworks.
Threat intelligence teams at Wiz analyzed telemetry from cloud environments and found that about 39-40% of cloud deployments contain vulnerable instances of React or Next.js. For Next.js alone, the framework appears in roughly 69% of surveyed environments, and in about 61% of those, public‑facing applications are running on top of it. When you combine those percentages, it means that roughly 44% of all observed cloud environments host publicly exposed Next.js instances, regardless of the exact framework version.
That overlap between popularity and vulnerability is what alarms defenders. When a widely deployed stack has a maximum‑severity, unauthenticated RCE bug with a reliable exploit path, opportunistic and targeted attacks are almost guaranteed to follow. Even organizations that patch quickly might face a short window where exposed endpoints can be probed and compromised.
At the time of the initial disclosures, no confirmed in‑the‑wild exploitation had been reported publicly. However, multiple security researchers, including experts from Rapid7 and watchTowr, stressed that it is realistic to assume threat actors are already reverse engineering the patches, scanning for unpatched services and building automated attack chains.
What researchers and vendors are saying about exploitation risk
Statements from the security community paint a consistent picture: this is not a theoretical problem, and the barrier to entry for attackers is low. Benjamin Harris, CEO of watchTowr, described the flaw as a major risk to users of one of the world’s most prevalent web frameworks and emphasized that exploitation requires “few prerequisites”.
Researchers at Wiz echoed that assessment after testing both vulnerable and patched versions. Their internal experiments showed that the crafted payloads used to exploit the unsafe deserialization achieved a near‑100% success rate in triggering full remote code execution on affected servers. They also noted that the attack is fully remote and unauthenticated, driven entirely by specially constructed HTTP requests.
From Rapid7’s perspective, the expectation is that technical write‑ups and proof‑of‑concept exploits will appear once enough people have parsed the patches. That, in turn, is likely to fuel broader scanning and mass exploitation attempts, especially against cloud environments with many internet‑facing apps.
Even outside the vendor community, industry media outlets have framed these CVEs as putting a significant slice of the internet at risk. Reporting has highlighted not only the raw severity but also the number of large consumer sites, SaaS platforms and API backends that rely on React and Next.js for their frontends and server‑side rendering.
Mitigation steps: what React and Next.js users should do now
For teams running React or Next.js in production, the guidance from maintainers and researchers converges on a simple point: upgrading to the patched versions is the only definitive fix. There are no configuration toggles or generic WAF rules that can fully solve the underlying unsafe deserialization behavior in the Flight protocol.
The React team recommends that anyone on affected branches moves to the hardened releases 19.0.1, 19.1.2 or 19.2.1, making sure that the react-server package is included in the update. For Next.js, Vercel has published fixed builds that integrate the patched RSC handling. Administrators should consult the official Next.js advisory to determine the minimum safe version for their chosen release line.
Organizations that rely on other RSC‑enabled frameworks — such as Redwood, Waku, React Router’s RSC preview, or Vite and Parcel RSC plugins — are advised to check the corresponding release notes and security channels. In many cases, these projects simply wrap or bundle React’s server components, so updating React itself and then pulling the latest framework revision is required.
Beyond straightforward patching, cloud‑focused tools are being used to hunt for vulnerable instances at scale. Wiz customers, for example, can tap into queries and advisories in the Wiz Threat Center to find where affected versions of React or Next.js are deployed in their environments. Other organizations are using asset inventories, SBOM data and container scanning to achieve similar visibility.
If there is any indication that systems may already have been targeted or compromised via these CVEs, incident response support is recommended. Some vendors specifically invite customers who suspect exploitation of CVE-2025-55182 or CVE-2025-66478 to contact their IR teams for help with triage, containment and forensics.
What this reveals about the JavaScript web ecosystem
Even though the React and Next.js patches close the immediate hole, the incident raises broader questions about how server‑side JavaScript frameworks handle untrusted data. Protocols like Flight sit deep in the stack, hidden behind abstractions that developers rarely inspect directly, which means flaws can have wide‑ranging effects before they’re noticed.
The fact that vulnerable behavior shipped in default, heavily promoted configurations also highlights the tension between developer experience and secure‑by‑default design. Features that make building modern apps easier — like server components and seamless serialization between client and server — can quietly introduce complex attack surfaces.
For security teams, this case is another reminder that framework‑level vulnerabilities can instantly turn into organization‑wide exposure. A single bug in a popular open source component may appear at the heart of dozens of separate applications, microservices and internal tools, especially when containers and templates are reused.
On the positive side, the response from the React maintainers, Meta and Vercel demonstrates that coordinated disclosure and rapid patch development are possible even in large ecosystems. Clear advisories, versioned fixes and coordination with security vendors have helped defenders prioritize this issue amid many competing vulnerabilities.
Looking ahead, many observers expect continued scrutiny of serialization, deserialization and protocol parsing logic in web frameworks. If CVE-2025-55182 and CVE-2025-66478 spur more systematic testing and tighter validation for components like Flight, some long‑term security benefits may emerge from an otherwise serious incident.
For now, teams running React or Next.js stacks are in a race between patch deployment and attacker automation. With a maximum‑severity RCE affecting default configurations, extensive cloud presence and high‑reliability exploitation techniques already demonstrated in research, keeping these environments safe comes down to how quickly organizations can identify where they are exposed and move everything to the hardened releases.
