React2Shell is the name commonly used to describe a set of critical vulnerabilities affecting React Server Components (RSC) and frameworks that rely on them, including Next.js. Since disclosure, security teams have observed continued exploitation attempts targeting exposed applications, with attackers abusing the vulnerability to gain unauthorized code execution on affected servers.

Public reporting indicates that some exploitation campaigns have used this access to deploy cryptocurrency miners and additional tooling for persistence and post-exploitation. In several cases, attackers have leveraged compromised systems to install backdoors, tunnelling utilities, or custom implants designed to maintain access or enable further activity. Reported targets span multiple industries, highlighting the broad applicability of the vulnerability rather than a sector-specific issue.

What is React2Shell?

In December 2025, coordinated disclosures identified a critical vulnerability in RSC, tracked as CVE-2025-55182, that allows unauthenticated remote code execution when untrusted input is processed by a vulnerable server.

A second identifier, CVE-2025-66478, was initially issued to track the same issue as it affected Next.js deployments. Following further analysis, NIST’s National Vulnerability Database rejected CVE-2025-66478 as a duplicate, confirming that both identifiers stem from the same underlying flaw in React’s server-side processing logic.

Despite the consolidation of the CVEs, the issue is still commonly referred to as React2Shell in technical advisories and tooling, reflecting its impact across multiple frameworks built on RSC.

Because React and Next.js are widely used in production environments, React2Shell represents a material risk for organizations operating vulnerable versions. This post explains the vulnerability at a high level, outlines how exploitation occurs, and discusses practical approaches for detection, mitigation, and ongoing risk management.

How the RSC flight protocol CVE-2025-55182 exploit works

The RSC model is designed to let servers return rendered UI fragments to clients efficiently. Behind this capability is a serialization and deserialization protocol, often called the Flight protocol that encodes component data and function calls for transport between client and server.

The React2Shell vulnerabilities arise because the deserialization logic in the Flight protocol does not validate untrusted data fully. When a server receives a maliciously crafted Request payload, the decoder may incorporate attacker-controlled values into internal objects and execution paths. This missing validation allows an attacker to control execution flow and trigger arbitrary code execution in the server process context.

Since Next.js builds on the same underlying React RSC infrastructure, applications that include RSC support (especially with the App Router) are also affected unless they have been updated to include the patched React implementation.

Exploitation characteristics

Several factors make React2Shell notable:

• Unauthenticated Remote Code Execution: No login or user privileges are required. An attacker can trigger the flaw by sending a malformed HTTP request to a public endpoint.

• Ease of Exploitation: Because the vulnerability exists in default configurations of the affected software, minimal technical effort is required to craft a working exploit payload.

• Widespread Exposure: Applications built using default React and Next.js setups are likely to expose the vulnerable deserialization path unless they have been patched.

• Broad Ecosystem Impact: Not only React and Next.js are affected; other tools integrating React Server Components may also include vulnerable packages.

Although early reports noted that proof-of-concept exploit code had been published, vendors and researchers have prioritized coordinated disclosure and remediation guidance while keeping specific exploit mechanics limited. 

Affected versions and fixes

RSC: React server packages with the vulnerable implementation include:

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

Affected releases span multiple 19.x versions. The vulnerability has been resolved in later patch releases such as 19.0.1, 19.1.2, and 19.2.1.

Next.js: Next.js versions that use the App Router with embedded RSC support inherit the vulnerability. Patched releases across the 15.x and 16.x branches as well as canary builds have been published to incorporate the updated React code.

Upgrading both React and framework dependencies is necessary; simply addressing one without the other can leave a chain of dependencies vulnerable.

Practical detection and remediation for the React vulnerability

Inventory and version tracking

The first step in remediation is understanding your application portfolio:

• Identify which applications use RSC

• Identify which deployments include vulnerable Next.js versions

• Track transitive dependencies that may embed RSC implementations from build or bundler tools

Maintaining a dependency inventory and version visibility is essential for prioritizing remediation efforts.

• Apply patch releases: Apply the available patched versions for both React and Next.js components. Ensure that all environments, development, staging, and production are upgraded to include fixed versions.

• Scanning and runtime monitoring: Use up-to-date vulnerability scanning tools to detect exposed instances of CVE-2025-55182 and CVE-2025-66478. Scanners should take into account frameworks and bundler plugins that incorporate RSC codepaths.

Implementing runtime monitoring can help detect anomalous requests to server endpoints that normally expect structured RSC payloads. Correlating such traffic with patch timelines assists in post-remediation validation.

Broader risk management implications

React2Shell highlights several recurring challenges in managing risk in modern application environments, particularly where widely adopted frameworks such as RSC are involved. Vulnerabilities at this layer rarely affect a single application in isolation and instead introduce shared risk across multiple services, teams, and environments.

Key risk management considerations include:

• Shared dependency exposure: A flaw in RSC can affect many applications simultaneously, including those owned by different teams or deployed across separate environments.

• Default exposure risk: Applications may be vulnerable through standard RSC configurations, even when server-side functionality was not intentionally exposed.

• Visibility gaps: Identifying where RSC is in use and which instances are internet-facing can be both challenging and time consuming which can significantly delay remediation.

• Time-to-response pressure: When exploitation activity begins shortly after disclosure, delays in detection and response are directly correlated with increased risk and impact.

• Persistence of risk over time: Even after patching, new deployments or updates can reintroduce vulnerable RSC components if monitoring and controls are not continuous.

Taken together, React2Shell demonstrates how modern application risk is increasingly driven by framework-level dependencies, rapid deployment cycles, and incomplete visibility into real-world exposure. Managing this risk effectively requires continuous discovery, validation, and reassessment rather than one-time remediation efforts.

How Outpost24 can help

Addressing vulnerabilities such as React2Shell requires more than applying a patch once and moving on. Organizations need ongoing visibility into which systems are exposed to the internet, what technologies those systems are running, and which vulnerabilities represent real risk. Outpost24 supports this through a combination of attack surface discovery, vulnerability assessment, and continuous risk management –delivered through solutions that can be used independently or together, depending on your organization’s security needs

Outpost24’s External Attack Surface Management (EASM) capabilities help organizations identify and monitor internet-facing applications and services. By continuously discovering exposed assets, EASM makes it easier for security teams to see where frameworks such as RSC, React, and Next.js are deployed and determine which systems are reachable from outside the organization. This external visibility is critical when responding to vulnerabilities that affect widely used frameworks.

Outpost24’s Risk-Based Vulnerability Management (RBVM) helps organizations detect vulnerabilities such as CVE-2025-55182, understand their severity in context, and prioritize remediation. RBVM can provide this visibility independently or in combination with EASM, delivering varying levels of depth, including insight into internal applications and systems. By correlating vulnerability data with exposure and business context, RBVM enables teams to focus first on vulnerabilities that represent the most meaningful risk, rather than treating all findings as equal.

Additionally, Outpost24 can also support organizations through the remediation lifecycle. Vulnerability validation and continuous reassessment help confirm that patches have been applied correctly and that vulnerable components are not reintroduced during future deployments or updates. This is especially important for framework-level issues like React2Shell, where new applications or dependency changes can unintentionally bring vulnerable versions back into the environment.

To discuss how Outpost24 can help you assess exposure to vulnerabilities like React2Shell and build long-term resilience and measurable risk reduction, please contact Outpost24 to speak with a security specialist and receive guidance tailored to your environment.