Skip to main content

CVE-2025-55182: React Server Components Have RCE CVSS 10.0 Error

· 20 min read
Evan Carter
Evan Carter
Senior frontend

TLDR:

CVE-2025-55182

CVE-2025-55182 exposes a critical CVSS 10.0 remote code execution flaw in React Server Components, affecting React 19 and major frameworks like Next.js. This excerpt highlights the root cause, real-world impact, and essential steps developers must take to detect, patch, and secure their systems immediately.

markdown React-rce-cvss10 is not just another theoretical bug; CVE-2025-55182 is a maximum-severity remote code execution (RCE) vulnerability in React Server Components (RSC) that can let an unauthenticated attacker run arbitrary code on your servers. With a CVSS score of 10.0 and broad impact across frameworks like Next.js, this flaw forces React teams to rethink their security posture, deployment pipelines, and application architecture.

Why CVE-2025-55182 Is a Critical React RCE (CVSS 10.0 Explained)​

When security teams assign a CVSS base score of 10.0, they are effectively saying: “Assume full compromise is possible, at scale, with minimal attacker effort.” That is exactly the case for CVE-2025-55182, a vulnerability in the React Server Components “Flight” protocol implementation that enables unauthenticated remote code execution on affected servers.

oaicite:0

At a high level, the vulnerability arises from unsafe deserialization of attacker-controlled payloads in the React server stack. Applications that support React Server Components, even if they don’t explicitly expose custom Server Function endpoints, may still be exploitable.

oaicite:1

Several factors explain why the risk is rated as critical:

  • Pre-auth, network-exposed attack surface. An attacker can target exposed HTTP endpoints that process RSC payloads without any prior authentication or session.
    oaicite:2
  • Code execution in a highly privileged context. Successfully exploiting the bug allows execution of arbitrary JavaScript in the server runtime, often with access to environment variables, secrets, databases, and internal APIs.
    oaicite:3
  • Ecosystem-wide reach. The vulnerability affects React 19’s server packages and popular frameworks like Next.js, React Router, Expo, Redwood, Waku, and others that rely on the RSC Flight protocol.
    oaicite:4
  • Emerging exploit tooling. Research blogs and proof-of-concept repositories have started to appear, significantly lowering the barrier for attackers to experiment with the bug, even if reliable mass exploitation is still evolving.
    oaicite:5

For security-conscious frontend teams, this is the React equivalent of a “react2shell” moment: a single protocol-level mistake that propagates into every server using that protocol.

What Is CVE-2025-55182? A Plain-Language Overview​

CVE-2025-55182 is an unsafe deserialization vulnerability in the React Server Components implementation. When a server receives a specially crafted RSC “Flight” payload, the deserialization logic fails to properly validate and constrain the data. This allows attacker-controlled structures to influence the execution flow and, in certain configurations, results in remote code execution on the server.

oaicite:6

From an engineering perspective:

  • The RSC protocol sends serialized component trees and server function calls from the client to the server.
  • The server decodes these payloads and maps them to actual functions, components, and internal objects.
  • Due to insufficient validation and trust boundaries, an attacker can craft a payload that tricks the server into loading and executing malicious code paths.

Critically, you do not have to build a custom “unsafe” feature yourself. If your stack relies on affected versions of:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack

then you inherit the vulnerability at the framework level.

oaicite:7

The vulnerability is also tracked in the Next.js ecosystem as CVE-2025-66478, which essentially reflects the same underlying flaw through its integration with the React Flight protocol.

oaicite:8

How React Server Components and the Flight Protocol Work​

To understand why this RCE exists, it helps to briefly recap how React Server Components (RSC) and the Flight protocol operate.

React Server Components

React Server Components in a nutshell​

React Server Components aim to move more work from the browser to the server:

  • Components run on the server, where they can access data sources directly.
  • The server serializes the rendered component tree and sends it to the client over the Flight protocol.
  • On the client, React hydrates these payloads into an interactive UI.

The architecture typically looks like this:

  1. Client sends an HTTP request that represents navigation or a user action.
  2. RSC Server resolves the request, executes server components and server functions, and serializes the result as a Flight response.
  3. Client receives the Flight stream and merges it into the existing React tree.

Because of this model, the RSC server layer often runs close to:

  • Data sources (databases, internal APIs, caches).
  • Secret-bearing configuration (environment variables, API keys).
  • Infrastructure-level capabilities (filesystem access, child processes, cloud SDKs).

That’s why an RCE at this layer is so dangerous: it’s not just “some JavaScript”; it’s code running at the heart of your backend.

Where the Flight protocol fits​

The Flight protocol is essentially a serialization format and protocol for RSC payloads. It is responsible for:

  • Encoding component trees and server function references.
  • Streaming responses in chunks for better performance.
  • Mapping serialized “handles” back to real functions on the server.

CVE-2025-55182 lives precisely in this boundary: insecure handling of attacker-controlled Flight payloads during deserialization and mapping back to server-side behaviors.

oaicite:9

Root Cause: Unsafe Deserialization in the React Server Components Stack​

A key principle in software engineering is that deserialization of untrusted input must be treated as a high-risk operation. CVE-2025-55182 is a textbook case of what happens when that principle is violated.

Based on the public advisories and security research:​

oaicite:10

  • The react-server stack accepts serialized RSC payloads representing component trees, server functions, and values.
  • During decoding, the implementation fails to enforce strict schemas and trust boundaries.
  • This leads to a logic flaw in which attacker-controlled data can influence what code paths are invoked on the server.

In practical terms:

  • The deserializer is too permissive; it doesn’t sufficiently restrict which objects/functions can be reconstructed.
  • It allows the construction or invocation of unexpected “gadgets”: existing code paths that, when given attacker-controlled input, can be chained into an RCE.

This is conceptually similar to classic Java/.NET deserialization vulnerabilities: when you deserialize arbitrary objects with complex graphs and rich behaviors, you risk instantiating something that can be driven into a dangerous state.

In the RSC case, the “objects” are React Flight tokens, component references, and server functions. When coupled with a vulnerable gadget and a convenient HTTP endpoint, that’s enough to reach code execution.

How the React2Shell Exploit Works in Real-World Scenarios​

The vulnerability has been nicknamed React2Shell by some researchers, drawing a deliberate analogy to Log4Shell.

oaicite:11
While exploit details vary by framework and deployment, a typical attack chain might look like this (high level, non-exploit-specific):

React2Shell Exploit

  1. Reconnaissance

    • The attacker discovers that a target website uses React 19 with Server Components or a framework like Next.js App Router.
    • They identify endpoints that accept RSC or multipart/form-data Flight payloads (e.g., navigation, form submissions, or API routes).
      oaicite:12

  2. Payload crafting

    • The attacker crafts a malicious Flight payload that abuses the serialization format.
    • The payload is designed to map to specific server functions and data structures that can be coerced into running attacker-controlled code.

  3. Triggering unsafe deserialization

    • The payload is sent as part of an HTTP request to a vulnerable RSC endpoint.
    • The server decodes the payload and, due to insufficient validation, reconstructs dangerous internal objects.

  4. Achieving RCE

    • By chaining these objects and functions, the attacker reaches a code path that allows command execution, filesystem writes, or arbitrary JavaScript evaluation in the server context.

Public analyses emphasize that exploitation depends on finding suitable gadgets within your application or the surrounding stack. Some advisories also highlight that exploitation against default configurations remains non-trivial, but proof-of-concept tooling already exists, and history shows that exploit reliability tends to improve over time.

oaicite:13

Impact Analysis: Who Is Affected Across the React Ecosystem?​

According to the React team, React 19 RSC packages are directly affected, and multiple advisories confirm that popular frameworks built on top of React are also impacted.

oaicite:14

Directly vulnerable React packages​

The CVE record and official advisories list the following packages and versions as vulnerable:

  • react-server-dom-webpack 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-parcel 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-turbopack 19.0.0, 19.1.0, 19.1.1, 19.2.0
    oaicite:15

Frameworks and services likely affected​

Any framework or platform that:

  • Uses React 19 with RSC enabled, and
  • Relies on the Flight protocol or React Server Functions

may be impacted. Public advisories explicitly call out:

  • Next.js (tracked as CVE-2025-66478, now treated as a duplicate of CVE-2025-55182).
    oaicite:16
  • Other RSC-based frameworks and tooling: React Router, Expo, Redwood, Waku, and more.
    oaicite:17

Security research using Shodan and ecosystem telemetry suggests that hundreds of thousands of publicly accessible servers may be running React/Next.js components, with a non-trivial subset likely within the vulnerable version ranges.

oaicite:18

Who is not affected?​

You are likely not affected if:

  • You do not use React Server Components or any framework with RSC support.
  • Your React use is strictly client-side (e.g., classic SPA with CSR only).
  • Your server-side rendering is implemented with older, non-RSC React versions or different SSR pipelines that do not integrate the Flight protocol.
    oaicite:19

Still, many modern production stacks have quietly adopted RSC through framework defaults, so you should never assume you’re safe without explicit verification.

Affected Versions, Frameworks, and Patch Availability​

The best source of truth for versions is always the official advisories. High-level, we know the following from Meta/React, Next.js, and major cloud vendors:​

oaicite:20

React Server Components fixed versions​

The React team has released patched versions of the affected RSC packages:

  • react-server-dom-webpack: 19.0.1, 19.1.2, 19.2.1
  • react-server-dom-parcel: 19.0.1, 19.1.2, 19.2.1
  • react-server-dom-turbopack: 19.0.1, 19.1.2, 19.2.1
    oaicite:21

Vercel’s advisory and follow-up analysis indicate that:​

oaicite:22

  • Vulnerable: Next.js 15.x and 16.x, and some 14.3.0-canary versions using the App Router.
  • Fixed Next.js versions include (at time of writing):
    • 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 (and later releases).
      oaicite:23

Other vendors (AWS, Google Cloud, Cloudflare, etc.) are actively publishing guidance and, where applicable, managed mitigations such as WAF rules and automatic protections for hosted environments.

oaicite:24

Detection: How to Check Whether Your React or Next.js App Is Vulnerable​

Leading architects suggest teams treat CVE-2025-55182 like an incident response drill: you need clear, repeatable checks to determine exposure and track remediation.

1. Inventory your applications and frameworks​

Start by answering:

  • Do you use React 19 with Server Components?
  • Are you running Next.js 15/16 or recent canary builds with App Router?
  • Do any other services embed RSC via frameworks like React Router, Expo, Redwood, or Waku?

You can often detect this by inspecting:

  • package.json and lockfiles (pnpm-lock.yaml, yarn.lock, package-lock.json) for the exact versions of react, react-server-dom-*, next, etc.
  • Docker images or build artifacts to ensure the production image matches your patched versions, not just local dev.

2. Check package versions against advisories​

Compare your discovered versions with the vulnerable and fixed ranges from official advisories and the CVE record.

oaicite:25

  • If you’re running any of the listed vulnerable versions and RSC is enabled, treat your app as vulnerable.
  • If you’re on a non-listed version but using custom RSC integrations, track your framework’s advisory channel.

3. Identify RSC/Server Function endpoints​

Next, map your incoming HTTP routes to RSC behavior:

  • Next.js App Router routes that use server actions or server components.
  • Custom RSC endpoints that accept Flight payloads or multipart/form-data requests tied to RSC rendering.

Even if exploitation requires specific gadgets, treat any RSC endpoint as a potential attack surface.

4. Review logs and telemetry​

Security vendors and cloud providers recommend:​

oaicite:26

  • Searching for anomalous error patterns around RSC deserialization.
  • Looking for unusual multipart/form-data requests, strange Flight payload shapes, or spikes in 4xx/5xx rates on RSC routes.
  • Correlating suspicious traffic with IP reputation and geolocation.

At the time of writing, some advisories report no confirmed widespread exploitation, but emphasize that exploitation is considered imminent.

oaicite:27

Exploitation Vectors in SSR, Streaming, and Edge Deployments​

CVE-2025-55182 is especially concerning because it intersects with modern deployment patterns that React teams have been embracing:

  1. Traditional SSR (Node.js servers)

    • Node-based servers that render RSC on-demand are directly exposed.
    • Multi-tenant hosting environments (e.g., PaaS) can amplify impact if isolation is weak.

  2. Streaming and incremental rendering

    • The Flight protocol’s streaming model means the server may process partial payloads over time.
    • Complex streaming pipelines increase the surface area for malformed or out-of-order data.

  3. Edge runtimes (e.g., Vercel Edge, Cloudflare Workers, other edge platforms)

    • Some frameworks support RSC rendering or server actions on edge runtimes.
    • While sandboxed, these environments may still have access to secrets, internal APIs, and sensitive data.

  4. Serverless functions and micro-frontends

    • In a micro-frontend or serverless architecture, multiple RSC-enabled entry points can exist across services, increasing the likelihood of misconfigured endpoints and inconsistent patch levels.

From a Feature-Sliced Design perspective, this illustrates why clear boundaries, explicit APIs, and controlled integration points are so important. When your architecture explicitly models “server-facing” features and isolates them behind well-defined interfaces, it becomes easier to:

  • Locate and patch vulnerable entry points quickly.
  • Wrap risky behavior (like deserialization) behind hardened, shared modules.
  • Apply cross-cutting protections (e.g., schema validation, logging) consistently, rather than ad hoc.

While patching is non-negotiable, a robust response goes beyond bumping versions. It’s about integrating security by design into your frontend architecture.

The single most important step is to:

  • Upgrade to React RSC server packages 19.0.1 / 19.1.2 / 19.2.1 or newer.
    oaicite:28
  • Upgrade Next.js and other frameworks to the patched versions recommended in their advisories.
    oaicite:29

2. Harden RSC endpoints​

Architecturally, treat RSC endpoints as high-risk API surfaces:

  • Enforce strict schema validation for incoming requests (e.g., with Zod, Joi, or runtime type systems).
  • Avoid mixing RSC endpoints with unrelated responsibilities—this reduces gadget discovery and complexity.
  • Apply rate limiting, IP reputation checks, and WAF rules where possible. Cloudflare, Google Cloud, and other providers have already shipped targeted protections for CVE-2025-55182.
    oaicite:30

3. Align your codebase around features and domains (FSD mindset)​

As demonstrated by projects using Feature-Sliced Design, organizing your frontend around features, entities, and shared layers helps keep server logic contained and auditable:

  • Server-specific logic and RSC entry points live in clearly scoped features.
  • Shared infrastructure (validation, logging, error handling) is centralized in the shared layer.
  • High-risk operations (like deserialization or dynamic code execution) are wrapped in single-responsibility modules with strong tests.

This means that when a new CVE like this lands, you don’t have to spelunk through randomly placed server utilities: you know exactly where your RSC integration resides and which features depend on it.

4. Limit privileges and secrets​

Regardless of architecture, least privilege still applies:

  • Minimize environment variables available in RSC runtimes.
  • Avoid embedding long-lived secrets directly into RSC contexts.
  • Use separate service accounts and credentials for different services or features, so a compromise in one area does not cascade across the system.

Patch Playbook: Checklist for Developers and DevOps Teams​

To make this actionable, here is a high-level, architecture-aware checklist. You can adapt it to your specific CI/CD and infra stack.

  1. Discovery

    • Enumerate all services using React 19 and frameworks with RSC support.
    • Identify production, staging, and internal tools that may be indirectly impacted.

  2. Version audit

    • Extract dependency versions from lockfiles and images.
    • Flag instances running vulnerable versions of react-server-dom-* and Next.js.
      oaicite:31

  3. Prioritization

    • Prioritize externally reachable services, especially those handling sensitive data or high-value workloads.
    • Include edge and serverless deployments in your inventory.

  4. Patch and deploy

    • Bump React and framework versions to patched releases.
    • Run automated test suites plus targeted smoke tests for RSC-heavy routes.
    • Roll out changes in stages, monitoring error rates and performance.

  5. Middleware and WAF defenses

    • Apply vendor-provided WAF rules or security policies specifically targeting CVE-2025-55182 / React RSC anomalies.
      oaicite:32
    • Enhance logging around RSC endpoints to capture malformed payloads.

  6. Refactoring for long-term resilience

    • Move RSC integration behind feature-oriented boundaries (e.g., FSD features and entities).
    • Introduce centralized validation and serialization utilities in the shared layer.
    • Add regression tests that simulate hostile payloads at the serialization boundary.

This is exactly where Feature-Sliced Design shines: by enforcing modularity, cohesive features, and clear public APIs, it lets teams implement security controls once and reuse them consistently across the codebase.

Security Lessons for the React Ecosystem and Library Authors​

CVE-2025-55182 is not just a bug in one library; it is a design lesson for all of us building complex frontend systems that blur the line between client and server.

Key takeaways for React teams and library authors:

  • Serialization formats are part of your threat model. If your protocol lets untrusted clients reference server functions and components, you must treat it with the same paranoia as a JSON API or RPC scheme.
    oaicite:33
  • Unsafe deserialization is still a top-tier risk. Even in JavaScript ecosystems, where the classic Java deserialization tricks don’t apply directly, complex object graphs and dynamic evaluation can be abused.
  • Coupling frontends and backends via rich protocols is powerful but dangerous. RSC and server functions promise ergonomic DX, but their attack surface is larger than traditional REST/GraphQL endpoints.

From a methodology perspective, Feature-Sliced Design encourages:

  • Explicitly modeling risky boundaries (e.g., “this feature owns server-side rendering for checkout”).
  • Isolating infrastructure concerns into shared modules that can be hardened and audited.
  • Maintaining a clear dependency direction, so high-level features cannot arbitrarily reach into low-level infrastructure in surprising ways.

These principles don’t eliminate CVEs in upstream libraries, but they dramatically improve your ability to respond when they occur.

How This Compares With Previous JavaScript and Web RCE Incidents​

While React2Shell is unique to the React Server Components era, it shares DNA with several past incidents:

  • Log4Shell (CVE-2021-44228) – a Java RCE in a logging library, triggered via attacker-controlled input passed into JNDI lookups. Similar in impact and ubiquity, though different in technical details.
  • Prototype pollution and supply-chain RCEs in npm packages – where untrusted input modified internal objects and eventually reached code execution.
  • Template injection in server-side rendering engines – where templating logic treated user input as template code.

In each case, we see the same pattern:

  1. A widely used library exposes a powerful dynamic feature.
  2. The feature is not designed with strict enough boundaries or input validation.
  3. An attacker finds a way to cross from data into behavior.

What’s different with CVE-2025-55182 is the modern frontend context:

  • RSC blurs classic frontend–backend lines, pushing React deeper into server territory.
  • Edge computing and serverless architectures multiply the number of entry points.
  • The performance benefits of streaming and Flight-based rendering increase protocol complexity.

This reinforces why architectural discipline—such as the kind promoted by Feature-Sliced Design and DDD-inspired frontends—is so important. Good structure doesn’t just help readability; it directly affects how quickly and reliably you can respond to vulnerabilities.

What Enterprises Should Do in the Next 24–72 Hours​

Security advisories from governments and major vendors are clear: act now.

oaicite:34
For enterprise teams, a pragmatic plan over the next 1–3 days might look like:

  1. Trigger a coordinated response.

    • Treat this as an incident-level event, with clear ownership across security, platform, and application teams.

  2. Complete inventory and version checks.

    • Identify all services using React 19 and RSC-enabled frameworks.
    • Confirm whether each is running vulnerable or patched versions.

  3. Patch critical systems first.

    • Prioritize Internet-facing apps handling sensitive data or authentication flows.
    • Use canary deployments and staged rollouts, but do not let “perfect” block “patched”.

  4. Turn on vendor protections.

    • Enable or tighten WAF rules against suspicious RSC payloads.
    • Follow specific guidance from providers like AWS, Google Cloud, Cloudflare, and others.
      oaicite:35

  5. Plan architectural follow-ups.

    • Use this event as a driver to refactor towards a feature-oriented, domain-aligned architecture such as Feature-Sliced Design.
    • Document where RSC is used, why, and how it is isolated.

By treating CVE-2025-55182 as both a short-term incident and a long-term architectural signal, enterprises can significantly improve their resilience to future zero-days.

Conclusion: React Security Outlook and the Case for Structured Frontend Architecture​

CVE-2025-55182 is a wake-up call for every team using React Server Components, Next.js, and the broader React ecosystem. A single, deeply embedded flaw in the Flight protocol has resulted in a CVSS 10.0, unauthenticated RCE affecting potentially hundreds of thousands of servers worldwide. The immediate path forward is clear: patch, harden, and monitor.

But the deeper lesson goes beyond a single CVE. As frontend and backend responsibilities continue to converge, your UI layer is no longer “just presentation.” It’s a distributed system with complex protocols, privileged server runtimes, and powerful abstractions like RSC. In that world, adopting a structured architecture like Feature-Sliced Design is not an optional nicety; it’s a long-term investment in code quality, security, and team productivity. By organizing your application around features, entities, and shared infrastructure—each with clear public APIs—you make it far easier to reason about where vulnerabilities live and how to contain them.

Ready to build scalable and maintainable frontend projects that can better withstand vulnerabilities like CVE-2025-55182? Dive into the official Feature-Sliced Design Documentation to get started.

Have questions or want to share your experience handling this React RCE? Join our active developer community on Website!

Disclaimer: The architectural patterns discussed in this article are based on the Feature-Sliced Design methodology. For detailed implementation guides and the latest updates, please refer to the official documentation.