Today, in December 2025, JS frameworks like ReactJS have blurred the line between backend and frontend development. While server components built with React enable faster, more dynamic applications, they also introduce risks. The server component architecture has enabled React2Shell to become one of the most serious vulnerabilities.
React2Shell poses a major threat to cybersecurity teams and developers by enabling attackers to run code remotely on vulnerable servers. This threat highlights how attackers can exploit the thin yet obscured line between server-side and frontend logic when the attack surface is not properly secured. The National Vulnerability Database (NVD) lists CVE-2025-55182 as having a severity level of 10, the highest possible.
What is React2Shell?
React2Shell is a remote code execution (RCE) type of vulnerability. This type of vulnerability affects apps that use React for server-side component logic in the site architecture. This architecture, combined with the React2Shell vulnerability, allows attackers to send altered requests to the server and run arbitrary commands without needing to log in to that server.
As the name implies, “React2Shell” as an attacker can escalate from a server-side React component to the server's shell. From here, the attack can run commands to gain persistence on the machine for further exploitation.
How does React2Shell Work?
For the reader to understand how this vulnerability works, you will need to understand how the server components work. Usually, in React apps or websites, you see the application on the screen, eg, a button, text, etc. Let's take the button, for example, we would call this a component in React. These components, when drawn on the screen (rendering), are either rendered in the browser or on the server that the user is requesting the content from. In this case, React2Shell affects server-side components, as components rendered on the browser (client-side) are not targeted by this vulnerability. With server-side components, the component is rendered on the server and streamed to the user's browser via the React Flight protocol. The render component's data is serialized to enable this.
The vulnerability comes from how React processes data from server-side pollution. In JavaScript, properties and methods are inherited by objects through the prototype chain. If this inheritance mechanism fails in validation, as is the case with this vulnerability, the React deserialization process has failed to validate the properties of the object, particularly the __proto__ property, thus allowing the attacks to fill the __proto__ object with crafted data that allows them to breach the runtime environment of the application.
When an attacker sends crafted HTTP POST requests to the endpoint of a server function, they can bypass prototype validation, allowing them to begin the hijacking process. The outcome is arbitrary code execution via functions such as “child_process.execSync.” To date, this is showing a 100 percent exploitation rate on the target servers.
Upon successful exploitation of the target server, the attacker can gain access to the server at the same level as the application. The level of access is determined by the logic running in the Node.js runtime. This allows the attacker to install backdoors, execute system-level commands, and use the server as a launch pad for further attack.
Which applications are affected?
The React applications affected by React2Shell are those that use Server components. One particular version and configuration are vulnerable to React2Shell. All versions before 19.x to 19.1.0 are vulnerable to React2Shell. In NextJS, it is a bit more complex. The affected versions are 15.0.0 through 15.0.4, 15.1.0 through 15.1.8, 15.2.0 through 15.2.3, and Next.js 16.x versions 16.0.0 through 16.0.6 and 16.1.0 through 16.1.2. Even canary builds starting from 14.3.0-canary.77 are affected.
All libraries that utilize server-rendered components are vulnerable to this vulnerability. Also, components that use React Router. While it's also important to point out that pure client-side-rendered applications with no server components are not at risk from React2Shell.
The Impact of React2Shell
React2Shell is the dreadful combination of the wrong factors that has security researchers worried. These factors are trivial exploitation, high motivation among bad actors, and widespread acceptance.
Security Impact
The most obvious impact is the compromise of the entire server. Once the bad actor gains full server control, they can perform remote code execution, allowing them to install backdoors, connect the server to a command-and-control server, and deploy web shells. This can allow a threat actor to have long-term persistence long after the server has been patched.
After the attacker gains a foothold on the server, they can steal API keys, database login credentials, JWT secrets, environment variables, and customer information. In environments with multiple tenants, this can expose significant internal customer information and system configuration.
React2Shell also allows bad actors to perform lateral movement within the environment. The compromised servers have access to internal services, including backend servers and databases. Internal services can be leveraged by attackers as an effective stepping stone to penetrate the network further. This makes cloud infrastructure highly vulnerable to this type of attack, as a single vulnerable server can serve as a pivot to access other parts of the cloud infrastructure.
How to prevent React2Shell Attacks?
Preventing React2Shell attacks requires developers and security teams to use a combination of architectural safeguards, monitoring, and timely updates. Thankfully, a safeguard can be put in place to drastically minimise risk.
The most practical and immediate defence is to upgrade the server to the latest, patched version of React and a framework such as NextJS. This update should take top priority, especially for any server facing the internet and using server components. For other frameworks, please also update to the latest and read the release notes. Before release, it is also important to thoroughly test the application to ensure its logic is not broken and remains functional. Updates are designed to be backwards compatible with older code bases, but it is also good practice to test before going to production, as untested code bases could result in user flows and server-side logic not working as they should.
Preventing updates, even if it's a short interval, can expose the application significantly to the React2Shell, given the rapid exploitation timeline of the vulnerability.
How to check if you are vulnerable to React2Shell?
Before patching, it is important to first determine whether you are vulnerable to React2Shell. There are multiple steps to help determine if the application is vulnerable.
There are automated scanning tools that can deliver the fastest results; for example, the tool created by Assetonote can scan the codebase and packages to identify vulnerable areas. Also, there is an npm package called react2shell-next. Not only does this npm package run a scan, but it can also apply fixes by changing configurations. Also, in Microsoft Defender Vulnerability Management, you can see which applications are vulnerable in the cloud environment.
The manual approach involves reviewing the package.json files for NextJS, React Router, or React. Comparing the versions of the packages in the package.json with the packages that are vulnerable. Also, check if your application uses the App Router rather than the Pages Router, as the App Router with server components is currently vulnerable. Also, check which applications are also internet-facing, as these are at the highest risk.
In cloud environments with many instances, using cloud security tools such as Microsoft Defender for Cloud helps reduce exposure through built-in Exposure management features. The defender for cloud helps identify React2Shell vulnerabilities in Azure, AWS, and other cloud environments. Additionally, path analysis tools can provide insight into how React2Shell can lead to further exploitation within the infrastructure.
When patching cannot be conducted immediately
As patching should be a priority for some applications, they may face delays due to complex testing requirements or dependencies. Furthermore, there are critical applications; therefore, implementing additional controls to reduce the risk posed by vulnerable applications is a must.
Firewalls, such as Web Application Firewalls, can block exploitation attempts, as the Azure WAF has custom rules that defend against React2Shell. Azure can block the malicious payload. Other WAFs have provided the same signatures for their solutions. The key is to have your WAF monitor the POST requests to the server components. In particular, POST requests containing a pull pattern and any changes to the __proto__ constructor.
Beyond patching and firewall measures, server-side applications can also be hardened against React2Shell by treating all incoming requests as untrusted. Correct, but strict input validation and defensive coding should be enforced when dealing with component data serialized from outside the application.
Also, it is important to implement logging that records server component invocations, as any unusual loading of modules and child processes spawned from these invocations can be paramount for investigation in the event of a major server compromise.
If the application has been compromised
If the application has been exploited, it is very important to conduct incident response actions swiftly. Isolate the server by removing it from the environment and placing it in quarantine segments to prevent further damage and lateral movement by attackers.
It is good practice to rotate environment variables, JWT signing secrets, connection strings, Azure service principals, and other credentials, such as cloud-provider and database passwords. Across the environment, it is important to do this as this will prevent any attacker from gaining access to any internal services, also preventing later movement and pivoting.
Determine the scope by viewing the logs; in particular, you would be looking for any abnormal server function calls. Also, check for any child processes being spawned right after these invocations. Also, check the network logs for any data exfiltration or any C2 connections. Additionally, the logs should show any lateral movement and check for any forms of persistence, such as files and new user accounts.
Also, check for backdoors and any malware on the compromised servers. The types of modifications to look for include crypto miners, CPU-intensive processes, and any code that has been modified.
Rebuilding compromised servers from known-good images and configurations may be a better option than a simple patch and trying to clean out a compromised device that could still contain hidden backdoors. Hece rebuilding the machine with a clean state seems to yield a better security posture.