CVE-2025-55182 and CVE-2025-66478: Critical RCE in React Server Components and Next.js

Home » Python » CVE-2025-55182 and CVE-2025-66478: Critical RCE in React Server Components and Next.js

The discovery of CVE-2025-55182 in React and its companion CVE-2025-66478 in Next.js has sent a clear warning shot across the modern web development world. These issues expose servers using React Server Components (RSC) and frameworks that implement the RSC “Flight” protocol to unauthenticated remote code execution, even when running with a completely standard, out-of-the-box configuration.

What makes this situation particularly troubling is how little effort an attacker needs to weaponize the flaw: a crafted HTTP request aimed at a vulnerable endpoint can be enough to run arbitrary code on the server. With a large share of cloud environments relying on React and Next.js, the urgency for administrators and developers to patch is hard to overstate.

Understanding CVE-2025-55182 and CVE-2025-66478

CVE-2025-55182 refers to the core bug in the react-server package, the component underpinning React Server Components and their “Flight” protocol. This package is responsible for handling the specialized payloads used when server-rendered components are streamed to the client, a mechanism central to the new React 19 ecosystem.

In parallel, CVE-2025-66478 captures the impact on Next.js, which integrates React Server Components and reuses the same underlying protocol. Because Next.js builds directly on top of this RSC infrastructure, any weakness in the protocol is immediately inherited by typical Next.js applications, including those bootstrapped with tools like create-next-app.

Both identifiers describe critical, unauthenticated remote code execution vulnerabilities. Security teams have rated them with maximum severity scores, reflecting not only their technical impact but also the fact that exploitation is possible in real-world deployment scenarios without complex prerequisites.

Researchers have also noted that the affected behavior is enabled by default in many configurations. That means applications don’t have to use any unusual patterns or add risky options to be exposed; simply adopting current RSC-based stacks can be enough to inherit the vulnerability.

Behind the scenes, the problem stems from the way RSC payloads are accepted and processed by the server-side logic. Instead of thoroughly validating and constraining untrusted input, the deserialization process allows attacker-controlled data to shape execution paths on the server.

How the Flight protocol becomes a path to RCE

The root cause behind CVE-2025-55182 in React Server Components is a logical deserialization flaw in the handling of the RSC “Flight” protocol. RSC uses a specialized wire format to describe component trees, props, and server actions, which the server encodes and the client decodes as part of rendering.

When a server receives a maliciously formed Flight payload, it should treat every piece of that data as untrusted. Instead, the vulnerable implementation processes this input in a way that effectively allows it to influence privileged server-side behavior. The unsafe deserialization step becomes the bridge between hostile data and JavaScript code running with full server privileges.

Security researchers describe this class of issue as insecure deserialization: the application takes complex input structures, reconstructs objects or execution flows from them, and fails to place strong safeguards around what those reconstructed objects are allowed to do. In this case, it opens the door to an attacker steering execution toward arbitrary code paths.

During testing, research teams reported near-perfect reliability when attempting exploitation. Proof-of-concept attacks, although not fully disclosed to limit opportunistic abuse, have been shown to achieve remote code execution with a success rate close to 100%. The only practical requirement is the ability to deliver a crafted HTTP request to an exposed RSC endpoint.

The attack is therefore remote and unauthenticated: no valid session, no leaked token, and no prior foothold are needed. A public-facing Next.js or other RSC-based app that hasn’t been updated can be probed and, if vulnerable, compromised.

Who and what is affected

Because the vulnerability is rooted in the core react-server implementation, its impact extends beyond React itself and Next.js to any framework that bundles or integrates RSC in a similar way. This has made the scope of potential exposure significantly wider than a single library or vendor-maintained product.

Public analyses have highlighted Next.js as the most prominent downstream target, given its popularity and deep RSC integration. Data collected by Wiz Research indicates that a substantial share of cloud environments run React or Next.js versions that fall within the vulnerable range, putting a notable slice of the web’s server-side rendering infrastructure at risk.

Estimates from those assessments suggest that around 39%-40% of cloud environments contain at least one instance of React or Next.js affected by these CVEs. Next.js itself appears in a majority of those environments, and in many cases is powering publicly accessible applications exposed directly to the internet.

Beyond Next.js, any framework or tool that embeds the react-server package or otherwise supports RSC is potentially exposed. Examples that have been flagged include:

• Next.js, in its RSC-enabled versions.
• Vite RSC plugins that provide server components support.
• Parcel RSC plugins with integrated React Server Components.
• React Router RSC previews or experimental releases.
• RedwoodSDK implementations using RSC features.
• Waku and similar emerging RSC-driven frameworks.

Cloud platform vendors have begun to clarify the blast radius from their perspective. For example, Google has indicated that standard public OS images on Google Cloud for Compute Engine do not ship with vulnerable RSC stacks by default. However, once users deploy their own React or Next.js apps on top of those images, the responsibility to patch lies with them.

Why the risk is considered extreme

Several characteristics combine to make CVE-2025-55182 and CVE-2025-66478 especially concerning for defenders. First, the attack surface is woven into how RSC communicates over the network, so it can be reached via ordinary HTTP traffic in many setups. Servers don’t need exotic features enabled to be reachable; a standard deployment is enough.

Second, the default configuration is vulnerable for typical apps using the affected RSC protocol. Developers who relied on recommended, out-of-the-box tooling and best practices may have unknowingly deployed applications that are susceptible without customizing anything at all.

Third, the impact of a successful exploit is about as severe as it gets: full remote code execution on the server. Once an attacker reaches this level, they can usually run arbitrary commands, pivot deeper into the environment, exfiltrate data, or tamper with application logic. In cloud-native environments where services are tightly integrated, that can quickly turn into a wider compromise.

Security researchers have also voiced concern that, now that patches and advisories are public, it’s only a matter of time before adversaries reverse-engineer the changes to build their own exploits, as discussed in guides on npm security.

Lastly, the sheer ubiquity of React and Next.js in production environments amplifies the risk. React is one of the most widely used JavaScript libraries for building interfaces, and Next.js has become a go-to framework for server-rendered and hybrid apps. A bug in a niche component might have stayed relatively contained; a bug in RSC touches a huge portion of the web stack.

Response from vendors and security teams

Once the vulnerability was identified, the disclosure process moved quickly. Security researcher Lachlan Davidson reported the flaw to the React team via Meta’s bug bounty program in late November. This early notification allowed maintainers to study the issue, prepare hardened releases, and coordinate guidance with downstream frameworks such as Next.js.

The React maintainers have since released updated versions of React and the react-server package that address the insecure deserialization behavior in the Flight protocol. These hardened builds are designed to handle RSC payloads more safely, closing the code paths that previously allowed untrusted data to dictate server-side execution.

Vercel and the Next.js team issued their own advisories, detailing which versions are impacted and how users should update. The goal has been to make it as straightforward as possible for teams to identify affected deployments and move to patched releases, including for apps created with common tooling like create-next-app.

On the defensive side, Wiz Research and other security vendors have published analyses, scans and queries to help organizations detect vulnerable instances across their cloud environments. Wiz, for instance, has added pre-built queries and threat center advisories to surface React and Next.js installations that still rely on the flawed RSC implementation.

Experts in the incident response community are also preparing for the likelihood that some organizations will face real-world exploitation attempts. Security firms have encouraged teams who suspect targeted activity involving CVE-2025-55182 or CVE-2025-66478 to engage response specialists quickly, ideally before attackers can deepen their foothold.

Immediate steps for developers and operators

For teams responsible for web applications built on React Server Components, upgrading to hardened releases is the only reliable mitigation. Configuration tweaks alone are unlikely to fully eliminate risk while still preserving normal RSC functionality, because the flaw is embedded in how the protocol itself is processed.

A practical response plan for organizations might look like this:

• Inventory all React and Next.js applications, including internal tools and less visible services, not just flagship public-facing sites.
• Identify which deployments use RSC or rely on versions of React and Next.js flagged as vulnerable by vendor advisories.
• Upgrade React, react-server and Next.js to the hardened versions released by the maintainers, following their version-specific guidance.
• Check other RSC-enabled frameworks such as Redwood, Waku or RSC plugins for Vite and Parcel, and apply updates as soon as maintainers release them.
• Review logging and telemetry around RSC endpoints for unusual, malformed or suspicious requests that might indicate probing or exploitation attempts.

Organizations using cloud security tooling can also leverage vendor-provided detection content to accelerate this process. For example, queries supplied by Wiz can help locate vulnerable packages and frameworks across multi-cloud deployments, reducing the chance that an overlooked service remains exposed.

Where possible, teams might also consider temporarily limiting exposure of RSC endpoints behind additional layers of access control, rate limiting or application firewalls while patches are rolled out. These measures are stopgaps rather than full fixes, but they can help reduce the window of opportunity for attackers.

As with any high-profile RCE, tightening monitoring around critical assets is equally important. Alerting on anomalies in process creation, outbound network connections from application servers and unexpected configuration changes can help detect successful exploitation early.

Longer-term implications for the web ecosystem

The emergence of CVE-2025-55182 in React and CVE-2025-66478 in Next.js is also prompting a broader conversation about how new web platform features are designed and rolled out. Server-side rendering and server components promise performance and developer experience benefits, but they also concentrate a lot of power and complexity in a relatively small set of protocols and libraries.

One lesson from this incident is that serialization and deserialization layers require particular scrutiny. Any mechanism that reconstructs complex objects or interprets structured payloads from untrusted sources is a candidate for severe bugs if validation is incomplete. As more frameworks adopt patterns similar to RSC, code reviewers and security auditors are likely to focus even more heavily on those boundaries.

The scale of potential impact has also highlighted how open source ecosystems depend on rapid, coordinated responses when critical flaws appear. React, Next.js, cloud providers and security vendors all needed to align quickly to publish patches, documentation and detection tools. That coordination can significantly shorten the time between disclosure and remediation, reducing the overall damage.

At the same time, the incident underscores how easily default settings can shape real-world risk. When a powerful feature is enabled by default and widely adopted, any weakness in that feature becomes a systemic issue almost overnight. Future framework designs may put more emphasis on safe-by-default behaviors, opt-in advanced features, or clearer security trade-offs.

Finally, development teams are likely to revisit their own threat modeling for server-driven features. Even in environments that previously felt well defended, the ability for unauthenticated requests to influence server-side rendering paths will push security teams to challenge long-held assumptions and invest in more robust testing.

As the community continues to digest these vulnerabilities, organizations that take swift action to patch, monitor and reassess their RSC usage will be in a stronger position. Addressing CVE-2025-55182 and CVE-2025-66478 isn’t just about fixing one bug; it’s a reminder of how interconnected modern web stacks are, and how crucial it is to keep a close eye on the foundations they rely on.