CVE-2025-55182 in React and CVE-2025-66478 in Next.js: what the new RCE flaws mean for the web

Home » Python » CVE-2025-55182 in React and CVE-2025-66478 in Next.js: what the new RCE flaws mean for the web

Over the past few days, the JavaScript ecosystem has been grappling with a pair of maximum‑severity security vulnerabilities in React and Next.js that open the door to remote code execution on affected servers. The flaws, assigned as CVE-2025-55182 for React and CVE-2025-66478 for Next.js, center on how React Server Components handle specialized network traffic in the so‑called Flight protocol.

Because these issues impact default framework configurations and can be triggered with nothing more than a crafted HTTP request, they have quickly risen to the top of many security teams’ patch lists. Vendors, researchers and cloud providers are now aligned on the same message: patch immediately, assess exposure, and prepare for broad scanning and exploitation attempts.

What CVE-2025-55182 and CVE-2025-66478 actually are

At the heart of the problem is a flaw in the react-server package, the component that powers React Server Components (RSC) and the Flight protocol. In vulnerable versions, the server accepts specially shaped RSC payloads and deserializes them without adequate validation, allowing attacker‑controlled data to interfere with the logic that runs on the server.

This behavior turns what should be structured data into a vehicle for executing privileged JavaScript on the backend. When an HTTP request targets an RSC or Server Function endpoint with a malicious Flight payload, the unsafe deserialization path can be abused to achieve unauthenticated remote code execution (RCE). No prior access, credentials or user interaction are required.

The React side of the issue is tracked as CVE-2025-55182, rated at the top of the scale with a CVSS score of 10.0. Because Next.js implements RSC and the Flight protocol on top of these primitives, it inherits the same core weakness; that downstream impact is assigned CVE-2025-66478 and carries the same severity rating.

Security advisories describe the bug as a logical deserialization vulnerability rather than a classic memory safety problem. The failure is in how payloads are parsed and trusted, not in low‑level buffer handling. Nevertheless, the outcome is just as serious: a remote attacker can steer server‑side execution.

Which React and Next.js setups are vulnerable

The vulnerability impacts React 19’s server‑side stack in several commonly deployed versions. Maintainers have called out releases such as 19.0, 19.1.0, 19.1.1 and 19.2.0 as vulnerable for the react-server package and its Flight protocol implementation. The patched branches are distributed as 19.0.1, 19.1.2 and 19.2.1, which introduce hardened deserialization logic.

On the framework side, Next.js is affected out of the box. A typical application generated with create-next-app, built for production and deployed with default settings, can be exploitable with no extra code added by the developer. Vercel, the company behind Next.js, has therefore issued its own advisory under CVE-2025-66478 and released updated framework versions that consume the fixed React packages.

The impact is not limited to Next.js alone. Any ecosystem component that bundles or plugs into React Server Components and the Flight protocol is likely exposed. This includes, among others, tools and frameworks such as:

• Next.js
• @vitejs/plugin-rsc (Vite RSC plugin)
• @parcel/rsc (Parcel RSC plugin)
• React Router RSC preview
• RedwoodSDK / rwsdk
• Waku

Research teams have emphasized that default configurations are generally at risk. In other words, even if a developer did not intentionally enable any experimental flags or unusual settings, their deployment may still be exploitable if it uses an affected version of React Server Components.

How easy exploitation is and why defenders are worried

What has alarmed the security community is the low barrier to exploitation. Multiple research groups report that attacking these flaws only requires sending a specially crafted HTTP request to a reachable RSC or Server Function endpoint. There is no need for authentication, complex pre‑conditions or user interaction, which makes the scenario particularly attractive for automated attacks.

In controlled testing, teams such as Wiz Research have built working proof‑of‑concept exploits and observed near‑100% reliability in triggering RCE on vulnerable setups. While these full payloads are not being released yet, the consensus is that the underlying behavior is straightforward enough that others can reconstruct working exploits by studying the public patches.

Given the popularity of React and Next.js, several experts believe that mass scanning and weaponization are only a matter of time. There are early comparisons to other high‑impact server‑side flaws where exploitation surged once technical details and example code were circulated in underground communities or public repositories.

Researchers are also highlighting the breadth of potential targets. React underpins sites and apps at large organizations across social media, e‑commerce, streaming, SaaS and more. Frameworks like Next.js are widely used for both internal and customer‑facing applications, meaning that vulnerable instances can appear deep inside corporate networks as well as on public‑facing frontends.

At the time many of the advisories were published, there were no confirmed reports of in‑the‑wild exploitation. However, analysts say it is reasonable to assume that threat actors are already reverse engineering the fixes and mapping out which hosts are reachable and misconfigured.

How widespread the exposure is across cloud environments

Several data points from cloud‑scale scans illustrate the scale of the problem. Threat hunters at Wiz report that around 39% of cloud environments they analyzed contain instances of React or Next.js running versions vulnerable to CVE-2025-55182 and/or CVE-2025-66478. Other breakdowns put the figure closer to 40% when both technologies are counted together.

Looking specifically at Next.js, the framework itself shows up in roughly 69% of environments in their dataset. Of those, a significant majority host publicly accessible applications built on Next.js. Put differently, their telemetry suggests that about 44% of all cloud environments have at least one internet‑exposed Next.js instance, regardless of whether it is currently patched.

This combination of high deployment density and public exposure is exactly what attackers look for when choosing which vulnerabilities to invest effort into. A single exploit chain can be reused at scale against many targets with similar setups, and automated tools can sweep entire IP ranges to find unpatched servers.

Some providers are working to narrow the blast radius. For example, Google has indicated that default public OS images used on Google Cloud’s Compute Engine are not vulnerable out of the box, though customers still need to audit and patch any applications they deploy on top of those images.

Vendors offering Web Application Firewalls (WAFs) are also entering the discussion. Cloudflare, for instance, has suggested that its WAF can help shield some React applications from exploit attempts when traffic is fully routed through the service, though such protections are best viewed as an extra layer rather than a replacement for updating the underlying software.

Timeline, discovery and vendor response

The chain of events around CVE-2025-55182 and CVE-2025-66478 unfolded quickly. Security researcher Lachlan Davidson identified the issue in the way React decodes payloads bound for React Server Function endpoints and reported it through Meta’s bug bounty program at the end of November.

React, originally developed at Meta and now a cornerstone of many modern web stacks, moved fast once the report was confirmed. Within roughly four days, the React team, in coordination with Meta, issued emergency updates to the affected 19.x lines, along with a security advisory urging immediate upgrades.

On the same day, Vercel announced its own advisory for Next.js under CVE-2025-66478. The framework maintainers published patched releases, guidance for users, and details on how the RSC implementation in Next.js inherits the vulnerable behavior from React’s server libraries.

Many of the public write‑ups intentionally omit step‑by‑step exploit details for now. Instead, they focus on explaining the risk, listing affected components and versions, and directing users to updated builds. The goal is to give defenders time to deploy fixes while slowing down less sophisticated attackers.

Industry voices, including researchers at companies like watchTowr and Rapid7, have echoed the message that this is a high‑priority issue for anyone running React or Next.js in production, and that the window before exploits surface publicly may be short.

What teams should do right now

For organizations using React Server Components, Next.js or any of the RSC‑enabled plugins and frameworks, the clearest guidance is that upgrading to hardened versions is the only complete mitigation. There is no configuration toggle that safely neutralizes the bug while staying on vulnerable releases.

On the React side, that means moving from affected 19.x builds such as 19.0, 19.1.0, 19.1.1 and 19.2.0 to 19.0.1, 19.1.2 or 19.2.1, depending on which branch a project is pinned to. These versions incorporate stricter checks around Flight protocol payloads and close off the unsafe deserialization behavior.

For Next.js users, the recommendation is to update to the patched framework releases announced in Vercel’s advisory, ensuring that the dependency tree pulls in the fixed React server packages. Even projects that do not explicitly use RSC in their own code may still be exposed if the framework enables server components under the hood.

Teams that rely on other RSC‑enabled stacks — including Redwood, Waku, the React Router RSC preview, and RSC plugins for Vite and Parcel — should monitor official channels from those projects. Many of them bundle their own copies of the React server runtime, so their maintainers are publishing specific update instructions and version numbers to look for.

For organizations with large cloud footprints, it can be difficult to know where all the vulnerable pieces live. Some security vendors, such as Wiz, are offering pre‑built queries and advisories within their platforms to help customers identify affected React and Next.js instances across environments. Others are making detection logic and scanning rules available for internal security teams to adapt.

What this means for the broader web ecosystem

The emergence of CVE-2025-55182 and CVE-2025-66478 is prompting a wider discussion about how server‑side JavaScript frameworks handle complex serialization formats. RSC and the Flight protocol are powerful tools for building modern applications, but the same flexibility that enables advanced features can also introduce subtle attack surfaces if parsing logic is not carefully locked down.

For developers, this episode is a reminder that relying on default framework behavior does not guarantee safety and the importance of protecting against supply‑chain attacks against npm. In this case, ordinary, boilerplate setups were enough to expose an application to unauthenticated RCE. Keeping up with security advisories, pinning dependencies, and applying updates quickly are becoming non‑negotiable tasks for teams that ship React‑ or Next.js‑based services.

From a defensive standpoint, organizations are using this event to review their layered protection strategies. Patching is front and center, but many are also looking at tightening access controls to administrative or internal endpoints, deploying WAF rules to spot suspicious Flight protocol traffic, and improving observability around server‑side errors that might indicate exploit attempts.

The situation also highlights how much of the internet now depends on a relatively small set of shared open source components. A single bug in a widely adopted library can ripple through cloud providers, SaaS platforms and enterprise environments in just a few days. Coordinated disclosure, rapid vendor response and clear communication become critical when so many organizations are affected at once.

For now, the focus is on getting vulnerable React and Next.js installations onto fixed releases before exploitation becomes routine. With researchers reporting near‑perfect exploit reliability, default configurations being vulnerable, and a substantial portion of cloud environments running affected versions, these CVEs have quickly gone from obscure protocol detail to a pressing operational concern for teams maintaining modern JavaScript applications.