- CVE-2025-55182 in React and CVE-2025-66478 in Next.js enable unauthenticated remote code execution via the React Server Components “Flight” protocol.
- The bug arises from unsafe deserialization of crafted RSC payloads and impacts many frameworks in their default configuration.
- Researchers observed near‑100% exploit reliability and estimate that roughly 39–40% of cloud environments run vulnerable React/Next.js instances.
- Immediate upgrades to the hardened React and Next.js releases are the only definitive mitigation, with vendors already shipping patches and guidance.
Over the past few days, security teams across the globe have been scrambling to assess a pair of newly disclosed bugs in the React ecosystem: CVE-2025-55182 in React Server Components and CVE-2025-66478 in Next.js. These flaws open the door to full remote code execution on servers and have raised alarm because they can be triggered without authentication and with very little effort from an attacker.
The issue cuts right through the core of modern JavaScript infrastructure. React and Next.js power everything from small side projects to platforms used by major enterprises, and a sizeable slice of cloud workloads rely on them. With researchers warning of imminent mass exploitation and almost perfect exploit reliability, development and operations teams are being urged to move patching to the top of their task lists.
What CVE-2025-55182 and CVE-2025-66478 actually are
At the heart of the problem lies the React Server Components (RSC) “Flight” protocol, a mechanism introduced to handle server-driven rendering flows. CVE-2025-55182 is the identifier assigned to the vulnerability in React’s own react-server package, while CVE-2025-66478 covers the corresponding flaw in Next.js, which embeds and extends this protocol.
The vulnerability is essentially a logical deserialization bug in the way RSC payloads are processed. When a server receives a specially crafted, malformed Flight payload, the implementation fails to thoroughly validate the structure before acting on it. That oversight lets attacker-controlled data slip into places where it can influence server-side execution.
In practical terms, this means an attacker can send a single crafted HTTP request to a React Server Function or RSC endpoint. When the server deserializes that payload, it can be coerced into running arbitrary JavaScript code with the privileges of the server process, turning a simple request into a full-blown remote code execution (RCE).
Security teams and vendors describe both CVEs as having a maximum CVSS score of 10.0, the highest possible rating. That reflects the combination of remote reachability, lack of authentication requirements, and the potential for complete compromise of the affected environment.
Why default configurations are exposed
One detail that has raised particular concern is that these bugs affect standard setups with no unusual configuration. A typical Next.js application generated with create-next-app, compiled for production, and deployed with default options can be vulnerable straight out of the box.
The same is true for many other RSC-enabled frameworks and tooling that bundle the react-server implementation. Because they adopted the Flight protocol as React designed it, they inherited the unsafe deserialization behavior. Developers do not need to add any exotic features or custom parsing logic for the flaw to be exploitable.
This default exposure raises the risk that attackers can scan the internet for RSC or Server Function endpoints and quickly stumble onto viable targets. There is no need for stolen credentials or pre-existing access: if the relevant endpoints are reachable from the public internet and run vulnerable versions, they are in the danger zone.
Security researchers stress that even organizations with mature security programs may be impacted because RSC is often enabled implicitly through framework updates and templates, and some teams might not realize they are using it in production.
Scope of impact across React and Next.js ecosystems
Multiple analyses converge on the same takeaway: the scale of the potential blast radius is unusually large. Data from Wiz Research suggests that around 39% to 40% of cloud environments contain React or Next.js instances vulnerable to CVE-2025-55182 and/or CVE-2025-66478. That is a significant chunk of the public internet’s application layer.
The problem is not limited to standalone React installations. Next.js, in particular, is extremely widespread: it appears in close to 69% of observed environments in some datasets, and a majority of those run public-facing Next.js apps. That combination means that a substantial fraction of cloud estates expose vulnerable endpoints directly to untrusted traffic.
In terms of specific components, the issue affects React 19.0, 19.1.0, 19.1.1, and 19.2.0 series that include the flawed react-server implementation. On the framework side, several popular tools that integrate RSC are also implicated. While the exact impact varies, the list of technologies associated with the vulnerable protocol includes:
- Next.js
- Vite RSC plugin (
@vitejs/plugin-rsc) - Parcel RSC plugin (
@parcel/rsc) - React Router RSC preview
- RedwoodSDK
- Waku
Researchers emphasize that any framework or library bundling the affected react-server implementation is likely to be in scope, even if it is not explicitly listed in early advisories. Organizations are being advised to inventory their use of RSC across build tools, previews, and pilot projects, not just high-traffic production apps.
Cloud providers have started to react as well. For instance, one vendor noted that its default public OS images for virtual machines do not ship with vulnerable React components enabled by default, although that does not shield workloads where customers install and configure React or Next.js themselves.
How exploitation works and why reliability is so high
While vendors are deliberately holding back some of the low-level exploitation details to give defenders time to patch, the broad outline is public. At a high level, an attacker only needs to craft an HTTP request that carries a specific malformed RSC payload aimed at a server endpoint that parses React Flight data.
Because the vulnerable code path is part of the standard deserialization logic, there is no requirement for a victim to click on anything, log in, or perform a multi-step workflow. As long as the attacker can reach a Server Function or RSC endpoint, they can try to trigger the unsafe deserialization and steer execution toward their own payload.
In testing, security teams reported that exploitation showed “high fidelity”, with success rates approaching 100% once the target’s configuration was understood. That kind of reliability is uncommon for remote exploits and raises the odds that attackers can automate scanning and compromise at scale.
Experts also warn that now-public patches and advisories effectively serve as a roadmap for reverse engineering. Even if exploit code has not yet been released widely, threat actors can study the differences between vulnerable and fixed versions to reconstruct the vulnerable logic and weaponize it, un riesgo similar a la cadena de suministro de npm.
As of the latest reports, there were no confirmed cases of widespread in-the-wild exploitation, but multiple security vendors and researchers expect that to change quickly as attackers race to take advantage of unpatched systems before organizations complete their remediation efforts.
Vendor responses and available patches
The discovery of CVE-2025-55182 is credited to security researcher Lachlan Davidson, who reported the issue through Meta’s bug bounty program. From initial disclosure to the release of patches, the turnaround was unusually fast, reflecting the severity of the bug and its reach across the web ecosystem.
The React team has shipped hardened versions of the affected packages. For the core library, maintainers point to updates such as React 19.0.1, 19.1.2, and 19.2.1 and equivalent patched variants of related components as closing the specific deserialization hole in the Flight protocol.
On the framework side, Vercel, which maintains Next.js, assigned CVE-2025-66478 to the downstream impact of the same RSC flaw and has released updated Next.js versions that incorporate the fixed React Server Components behavior. Their security advisory explains that the vulnerability stems from the way React decodes payloads bound for Server Function endpoints and that the patch tightens those decoding routines.
Other frameworks and plugin authors that rely on RSC—such as the maintainers of Redwood, Waku, and RSC plugins for Vite and Parcel—have started issuing their own guidance and version updates aligned with the patched react-server code. Users are being directed to follow project-specific announcements and upgrade instructions.
Several commercial security providers have also responded. For example, Wiz has published a pre-built query and advisory in its Threat Center so customers can detect vulnerable instances in their environments, while other vendors claim that certain web application firewalls may block some exploit attempts if React traffic is correctly routed through them. Nonetheless, maintainers are clear that configuration tweaks or WAF rules are no substitute for proper patching.
Risk assessment: who should be worried most?
The short answer is that any organization running React 19 or RSC-dependent frameworks in production should take this seriously, but some deployment patterns stand out as particularly exposed. Public-facing Next.js applications, for instance, present a tempting target because they often sit directly on the internet and have RSC features enabled by default.
Organizations that make heavy use of Server Functions, server-driven routing, previews, or experimental RSC-based features are especially at risk. In these setups, Flight payloads are more likely to be processed frequently, giving adversaries many opportunities to test payloads and refine exploits.
Shared or multi-tenant environments raise additional concerns. If a vulnerable React service runs with broad access to internal resources, a successful RCE could become a pivot point for lateral movement deeper into the network or across customer boundaries.
Analysts also point out that the breadth of React’s adoption—by companies such as Meta, Netflix, Airbnb, Shopify, Walmart and many others—means that the real-world impact is not limited to purely technical risk calculations. A compromise in a major application stack can have ripple effects across users, partners, and downstream ecosystems.
Finally, even teams that believe they do not rely heavily on RSC should verify that assumption. Because tooling and boilerplates can quietly enable RSC features, some projects may be more exposed than their maintainers realize at first glance.
Practical mitigation steps for React and Next.js users
Across advisories, one point is repeated consistently: upgrading to patched versions is the only definitive fix. There is no configuration flag or minor tweak that fully neutralizes the underlying unsafe deserialization behavior without updating the affected packages.
For organizations using React directly, maintainers recommend moving to the hardened releases—such as 19.0.1, 19.1.2, 19.2.1 or newer—along with updated react-server and related RSC packages. Teams should consult the official React security advisory to confirm the exact versions that address CVE-2025-55182 in their dependency tree.
Next.js projects should similarly upgrade to the patched framework versions that include the fix for CVE-2025-66478. Because a default Next.js build is enough to be impacted, even small sites and internal dashboards deserve attention, not just flagship applications.
For environments using other RSC-capable frameworks—such as Redwood, Waku, or RSC plugins for bundlers like Vite and Parcel—the advice is to track vendor announcements closely and deploy any updates that bundle the hardened react-server implementation as soon as they are available. Where possible, staging environments should be used to validate application behavior before rolling fixes into production y aplicar prácticas como la gestión segura de secretos en GitHub Actions.
In parallel with patching, security teams can scan for vulnerable versions and exposed endpoints. Tools from vendors like Wiz can help identify where susceptible React or Next.js instances are running, while web security scanners and asset inventories can map which services are reachable from the internet versus being confined to internal networks.
What defenders should watch for in the near term
The disclosure of CVE-2025-55182 and CVE-2025-66478 illustrates a familiar pattern: a critical bug in a widely used component surfaces, patches land quickly, and then a race begins between defenders and attackers. In this case, the combination of a 10.0 CVSS score, unauthenticated RCE, and default exposure makes that race particularly intense.
Security researchers anticipate that the next phase will involve rapid reverse engineering of the patches by threat actors. Even without detailed proof-of-concept code being released, comparing old and new versions provides enough clues for skilled attackers to reconstruct the vulnerable logic.
Organizations should expect an uptick in scanning for React and Next.js endpoints, as well as more probing HTTP requests aimed at Server Function and RSC URLs. Logging and monitoring systems can play a role here: anomalous or malformed Flight payloads, unexpected errors during deserialization, and spikes in requests to specific endpoints may be early indicators of attempted exploitation, y las herramientas de prueba como Burp Collaborator pueden ayudar a reproducir vectores.
Some defenders are also revisiting defense-in-depth controls around their React deployments. That may include routing traffic through web application firewalls, tightening network exposure of internal services, and enforcing stricter least-privilege configurations for application runtime permissions so that a compromise does not automatically grant broad access.
Incident response teams are being advised to prepare for potential investigations involving these CVEs. That can involve updating playbooks, ensuring relevant logs are retained for long enough to analyze suspicious behavior, and establishing contacts with service providers or security vendors who can assist if a compromise is suspected.
Across the board, the message from researchers, vendors, and cloud providers is consistent: while no widespread exploitation has been publicly confirmed yet, the technical conditions make this an attractive target, and waiting to patch significantly increases the risk window.
With critical remote code execution bugs like CVE-2025-55182 in React and CVE-2025-66478 in Next.js, the practical takeaway is straightforward: assume that vulnerable RSC endpoints will be probed, prioritize upgrades to hardened versions, and use available tooling to locate and protect exposed instances. For a web stack that leans heavily on React and its surrounding frameworks, timely remediation now is likely to pay off in fewer emergencies later.
