TL;DR:
React2Shell (CVE-2025-55182) is a critical vulnerability in React Server Components that allows attackers to execute code on production servers without authentication. It exploits insecure deserialisation and prototype pollution, bypassing traditional defenses like WAFs. Patch your React versions and enable updated security controls immediately to protect your systems.
Table of Contents
Introduction
Modern web frameworks are designed to make developers faster and applications more powerful. They say, with great power comes great responsibility. When frameworks move logic across the network and rebuild it dynamically on the server, errors in judgement in how data is trusted or reconstructed can have serious consequences.
React2Shell (CVE-2025-55182) is one such error. It is an unauthenticated remote code execution vulnerability in React Server Components that allows attackers to execute arbitrary code on production servers by exploiting insecure deserialisation.
This is not a theoretical edge case. Estimates suggest that up to 39 percent of cloud environments could have been exposed. React2Shell initially bypassed traditional protections such as Web Application Firewalls (WAFs), which made it especially dangerous in real-world environments.
This article explains how React2Shell works, why it is so severe, and what it teaches us about the risks of deserialisation in modern web frameworks.
Quick Threat Summary
Who is affected
Organisations running React Server Components in production.
What versions
React versions prior to the security patches released in December 2025. Refer to the official React advisory for exact version details.
Worst case outcome
Full production server compromise. Attackers can:
- Execute arbitrary code
- Steal credentials and data
- Potentially move laterally to other systems using the server’s privileges
Quick Tip
Azure customers can now protect their public facing systems from React2Shell with Azure WAF
The React2Shell Vulnerability Explained
React2Shell is a security vulnerability that allows unauthenticated remote code execution by exploiting a flaw in how vulnerable versions of React decode payloads sent to backend (React Server Function) endpoints.
React Server Components rely on serialised request payloads, commonly referred to as Flight payloads. These payloads describe which server-side functions should run and with what data. The server decodes the payload and reconstructs objects before invoking the appropriate logic.
In vulnerable versions of React, this decoding process does not strictly validate metadata during reconstruction. An attacker can inject additional fields that reshape base objects while they are being rebuilt. This creates an opportunity for prototype pollution during deserialisation.
Initially, WAFs were not equipped to deal with this threat. WAFs typically look for data that matches attack patterns. Since React2Shell is formatted as legitimate data, the WAF sees it as standard application traffic rather than a threat, thus bypassing the perimeter defence entirely.
Since then, major WAF vendors have all released controls for this vulnerability, but this was after the fact based on analysis of the published exploits.
Prototype Pollution as an Execution Path
JavaScript objects inherit behaviour through prototypes. By polluting a prototype during deserialisation, an attacker can inject malicious behaviour that affects all objects that inherit that prototype.
React’s runtime automatically follows these polluted prototype chains. In particular, then-style hooks can be abused to influence execution flow. This allows an attacker to pivot from a crafted payload directly into code execution on the server without authentication.
Once code execution is achieved, the impact is severe. Attackers can:
- Access secrets stored on the server
- Steal credentials and tokens
- Read, modify, or destroy application data
- Move laterally to other systems if the compromised server has network access
A Backstage Analogy
Imagine a backstage system where a stage company sends instructions for setting up equipment. Occasionally, these instructions include sourcing additional parts. The crew trusts the instructions and follows them without verifying their origin.
An attacker hides a malicious device inside one package along with forged setup instructions. The crew follows the instructions, sources the parts, assembles the device, and powers it on. The payload is activated without the attacker ever entering the building.
React2Shell works in much the same way. The server trusts what it receives, reconstructs it, and executes it.
Why React2Shell Matters
React is the current bad boy poster child of web frameworks, but it is conceivable that other modern web frameworks may one day have their turn in the news.
For example, other popular web frameworks like Qwik and Nuxt in JavaScript, LiveWire in PHP, Blazor Server in .NET all feature stateful reconstruction.
This vulnerability shines a light on three uncomfortable truths:
- Many modern web frameworks increasingly rely on reconstructing complex objects sent over the network.
- Small validation gaps in that reconstruction process can lead directly to code execution.
- Traditional perimeter defences are often ineffective against these classes of bugs until after the vulnerability is discovered, which is too late.
To understand why vulnerabilities like this keep appearing, we need to look beyond React itself and examine deserialisation as a systemic security problem, which we’ll tackle together in the next article.
Key Takeaways
1. React2Shell enables unauthenticated remote code execution
No credentials are required. A single crafted request can lead to full server compromise. If you are using React Server Components, patch and implement WAF controls now.
2. The vulnerability exploits insecure deserialisation
The issue lies in how payloads are reconstructed and trusted.
3. Prototype pollution is the critical enabler
By reshaping base objects during deserialisation, attackers can hijack execution flow.
4. Traditional defences are not enough
WAFs and perimeter network controls do not reliably stop deserialisation exploits before they are discovered because they can masquerade as legitimate traffic.
5. This is a pattern, not an anomaly
React2Shell fits into a long history of deserialisation vulnerabilities across ecosystems that is likely to continue for some time
Conclusion
React2Shell is a reminder that the most dangerous vulnerabilities often emerge at the intersection of convenience and complexity. React Server Components make it easier to build powerful web applications, but this power is built on trusting data that crosses a security boundary.
When that trust is misplaced, the result is not a minor bug but a critical system-level failure.
Understanding how React2Shell works is valuable not only for React developers, but for anyone building modern stateful web apps. Because this is fundamentally a cautionary tale in the inherent dangers of deserialisation, and the difficulties in guarding against them in a deep and complex ecosystem.
In my next article, I will step back from React and talk to deserialisation’s insecurities more broadly. I will look at why deserialisation is so intransigent a culprit, and what practical steps architects and developers can take to create defence-in-depth.
