React2Shell: How a Deserialization Flaw in React and Next.js Exposed Millions to Remote Code Execution

React2Shell: How a Deserialization Flaw in React and Next.js Exposed Millions to Remote Code Execution

Alex Cipher's Profile Pictire Alex Cipher 9 min read

A single flaw in a widely used JavaScript framework can ripple across the internet, putting millions of applications at risk. The React2Shell vulnerability is a prime example: a critical bug in React and Next.js that lets attackers execute arbitrary code on servers—no password required. At its core, React2Shell exploits a weak spot in the deserialization process of the React Server Components (RSC) “Flight” protocol. This protocol, designed to shuttle component data between client and server, failed to validate incoming payloads, opening the door for attackers to send malicious data that the server would unwittingly execute (BleepingComputer).

The scale of the problem is staggering: React is downloaded over 55 million times per week, and Next.js clocks in at nearly 17 million. According to Wiz researchers, nearly 39% of cloud environments they monitor are running vulnerable versions. The attack is as simple as sending a crafted HTTP request—no authentication needed. This makes React2Shell not just a technical curiosity, but a real-world threat with the potential for mass exploitation. The flaw has already prompted urgent patching efforts and a broader re-examination of how JavaScript frameworks handle serialization and deserialization (BleepingComputer). For ongoing updates, the React2Shell website is tracking developments.

How the React2Shell Vulnerability Works: Breaking Down the Technical Details

Insecure Deserialization in the Flight Protocol

The React2Shell vulnerability is rooted in a logically insecure deserialization process within the React Server Components (RSC) “Flight” protocol. The protocol is responsible for transmitting component payloads between the client and server. In affected versions, the server fails to adequately validate the structure and content of incoming RSC payloads. This oversight allows attackers to craft malicious payloads that, when deserialized, result in the execution of arbitrary JavaScript code on the server (BleepingComputer).

The vulnerability is particularly severe because the deserialization logic does not enforce strict schema validation or type checking. As a result, malformed or malicious data can traverse the deserialization process unchecked, enabling attackers to inject executable code. The attack surface is broad, as the flaw exists in the default configuration of several widely used packages, including react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack.

Attack Vector: Exploiting Server Function Endpoints

Attackers can exploit the React2Shell vulnerability by sending specially crafted HTTP requests to endpoints that handle React Server Functions. These endpoints are designed to process serialized component data sent from the client. When an attacker submits a malicious payload, the vulnerable server-side deserialization logic interprets the data as legitimate, leading to the execution of attacker-supplied JavaScript code within the server context (BleepingComputer).

Notably, the attack does not require authentication, meaning that any external actor can attempt exploitation if the vulnerable endpoints are exposed to the internet. This dramatically increases the risk profile for affected applications, as remote code execution (RCE) can be achieved without prior access or credentials. The vulnerability is further exacerbated by the fact that even applications not explicitly implementing React Server Function endpoints may be at risk if they support React Server Components.

Privilege Context and Code Execution Scope

The code execution enabled by React2Shell occurs within the server’s JavaScript runtime environment. This context typically has access to sensitive resources, including file systems, environment variables, and network interfaces. The vulnerability allows attackers to run arbitrary JavaScript code with the same privileges as the server process. This can result in data exfiltration, lateral movement within the infrastructure, or the deployment of additional malware (BleepingComputer).

Researchers have observed that proof-of-concept (PoC) exploits for React2Shell do not need to invoke dangerous Node.js modules such as vm#runInThisContext, child_process#exec, or fs#writeFile directly. In fact, legitimate exploitation leverages the deserialization flaw itself, rather than relying on explicit calls to these modules. This distinction is important, as some fake PoCs have attempted to demonstrate exploitation using these modules, but such approaches would only succeed if the application was already configured to allow such dangerous operations.

Affected Packages and Inheritance of Vulnerability

The React2Shell vulnerability is present in React versions 19.0, 19.1.0, 19.1.1, and 19.2.0, as well as in Next.js canary releases starting with 14.3.0-canary.77 and all 15.x and 16.x releases below their respective patched versions (BleepingComputer). The root cause lies in the react-server package, which is used by React Server Components. Next.js inherits the vulnerability through its implementation of the RSC “Flight” protocol.

Beyond React and Next.js, the same insecure deserialization logic is likely present in other libraries that implement React Server, including the Vite RSC plugin, Parcel RSC plugin, React Router RSC preview, RedwoodSDK, and Waku. This broadens the potential impact, as organizations using these alternative implementations may also be exposed to remote code execution risks.

Wiz researchers have estimated that 39% of all cloud environments they monitor contain instances of Next.js or React running vulnerable versions. This statistic underscores the widespread nature of the issue and the urgency of remediation efforts.

Automated Management of Server Functions and Exploit Limitations

In Next.js, the list of available server functions is managed automatically, which imposes certain limitations on how the vulnerability can be exploited. Unlike some PoCs that attempt to invoke arbitrary server-side functions, the actual exploit does not depend on explicit exposure of dangerous Node.js modules. Instead, it capitalizes on the failure of the deserialization process to enforce strict boundaries between data and executable code (BleepingComputer).

This automated management means that, in Next.js, attackers cannot simply invoke functions like child_process#exec unless the application has been explicitly configured to expose such functionality. However, the underlying deserialization flaw still enables attackers to manipulate the server’s execution flow in unintended ways, potentially leading to arbitrary code execution depending on the application’s configuration and the privileges of the server process.

Real-World Impact and Prevalence

The React2Shell vulnerability has significant real-world implications due to the popularity and widespread deployment of React and Next.js in production environments. According to download statistics from the Node Package Manager (NPM), React is downloaded approximately 55.8 million times per week, while Next.js sees around 16.7 million weekly downloads (BleepingComputer). These figures highlight the vast number of potentially vulnerable deployments across organizations of all sizes.

The risk is further amplified in cloud environments, where rapid scaling and deployment practices can lead to large numbers of exposed endpoints. The ease of exploitation—requiring only a specially crafted HTTP request and no authentication—means that attackers can automate scanning and exploitation at scale. Organizations are advised to audit their environments, identify vulnerable versions, and apply the recommended patches as a matter of urgency.

Technical Distinctions from Other Server-Side Vulnerabilities

React2Shell is distinguished from other server-side vulnerabilities by its exploitation of the serialization and deserialization process specific to the React Server Components Flight protocol. Unlike traditional injection attacks, which rely on manipulating input to execute code through existing application logic, React2Shell abuses the trust placed in serialized component data. The vulnerability does not depend on the presence of dangerous server-side functions or misconfigured permissions; rather, it exploits a fundamental flaw in how data is interpreted and executed by the server.

This characteristic makes React2Shell particularly insidious, as it can affect applications that otherwise follow best practices for endpoint exposure and privilege management. The attack vector is novel in the context of JavaScript frameworks, and its discovery has prompted a reevaluation of serialization and deserialization practices across the ecosystem.

Mitigation Complexity and Patch Adoption

Mitigating React2Shell requires updating to patched versions of the affected packages. React has released fixes in versions 19.0.1, 19.1.2, and 19.2.1, while Next.js has addressed the vulnerability in versions 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7 (BleepingComputer). Organizations must audit their software supply chains to ensure all dependencies are updated, as indirect dependencies on vulnerable packages can also introduce risk.

The complexity of modern JavaScript application architectures, with deep dependency trees and frequent use of third-party plugins, makes comprehensive patch adoption challenging. Security teams must coordinate with development and operations teams to identify all affected components and ensure timely remediation. Failure to do so leaves organizations exposed to automated exploitation campaigns, which are likely to increase following public disclosure of the vulnerability.

Broader Implications for JavaScript Ecosystem Security

The discovery of React2Shell has broader implications for the security of the JavaScript ecosystem. It highlights the risks associated with complex serialization protocols and the need for rigorous validation of all incoming data, especially in server-side rendering contexts. The vulnerability serves as a reminder that even mature and widely adopted frameworks can harbor critical flaws with far-reaching consequences.

In response, maintainers of React, Next.js, and related libraries have begun to reevaluate their serialization and deserialization logic, introducing stricter validation and type checking to prevent similar issues in the future. The incident has also prompted increased scrutiny of third-party plugins and alternative implementations of the React Server protocol, as these may inherit similar vulnerabilities if not properly audited.

Summary of Key Technical Mechanisms

  • Deserialization Flaw: The core issue is a lack of validation during deserialization of RSC payloads, allowing arbitrary JavaScript execution.
  • Attack Surface: Exploitable via unauthenticated HTTP requests to server function endpoints in default configurations.
  • Privilege Escalation: Code runs with server process privileges, enabling broad impact.
  • Widespread Exposure: Affects multiple packages and frameworks, with millions of deployments potentially at risk.
  • Mitigation: Requires prompt patching and thorough auditing of all dependencies and related plugins.

For ongoing updates and technical details, researchers and organizations are encouraged to monitor the React2Shell website and official advisories from React and Next.js maintainers.

Final Thoughts

React2Shell is a wake-up call for the JavaScript ecosystem. It shows how even mature, trusted frameworks can harbor vulnerabilities with far-reaching consequences. The flaw’s ease of exploitation—requiring only a crafted HTTP request and no credentials—means organizations must act fast to patch and audit their environments. The incident also highlights the importance of rigorous validation in serialization protocols, especially as frameworks grow more complex and interconnected (BleepingComputer).

Looking ahead, the React2Shell saga will likely influence how developers and security teams approach server-side JavaScript. Expect more scrutiny of third-party plugins, deeper audits of serialization logic, and a renewed focus on defense-in-depth. As AI and IoT continue to expand the attack surface, lessons from React2Shell will be crucial in building more resilient web applications. For those managing React or Next.js deployments, staying informed and proactive is the best defense. For the latest, keep an eye on the React2Shell website and official advisories.

References

Related Articles