On December 3, 2025, Lachlan Davidson disclosed a new, critical vulnerability in React Server Components: React2Shell. This vulnerability within the popular JavaScript framework was published as CVE-2025-55182 and categorized as Critical with a CVSS score of 10 (the highest score possible).
All current versions of React Server Components, including React 19.0.0, 19.1.0, 19.1.1, and 19.2.0, are vulnerable. Update to the patched versions immediately to remediate this vulnerability.
Broader Impact of React2Shell
Many application frameworks in the JavaScript ecosystem use React Server Components. Next.js versions 15.x and 16.x with App Router are affected because they rely on the same underlying deserialization logic. Any application that supports React Server Components is potentially vulnerable—even if it doesn’t explicitly define server functions.
An attacker can leverage this weakness to perform Remote Code Execution (RCE) against vulnerable applications. The attack exploits unsafe deserialization in React’s “Flight” protocol—the mechanism React uses to send component data between client and server. An attacker can craft a malicious payload that, when processed by the server, executes arbitrary JavaScript in the server process. This could result in reading sensitive files, spawning processes, or complete server compromise.
Within hours of public disclosure, Amazon’s threat intelligence teams observed active exploitation by multiple China state-nexus threat groups, including Earth Lamia and Jackpot Panda. The speed of weaponization underscores how critical it is to patch immediately.
Immediate Remediation Steps
- Patch immediately. Update React and Next.js to patched versions. See the React Team Security Advisory for specific version guidance.
- Check framework dependencies. Even if you didn’t install react-server-dom-* directly, your framework might have. Review your complete dependency tree.
- Scan with StackHawk. Run a StackHawk scan to confirm whether your application is actually exploitable, and verify the fix after patching.
- Deploy WAF rules. If you use AWS WAF, the AWSManagedRulesKnownBadInputsRuleSet (version 1.24+) includes protection rules. Other WAF providers are releasing similar rules.
- Review logs for exploitation attempts. Look for the indicators listed above. If you see evidence of exploitation, treat the server as potentially compromised.
- Assume exposure. If you were running vulnerable versions on internet-facing infrastructure, conduct a thorough incident response review. Public exploit code has been available since December 4th.
How to Check for React2Shell in Your Environment
There are multiple ways to find vulnerable versions of React in use.
Check Your Framework Dependency Tree
The most direct method is examining your project’s dependencies:
# For npm projects
npm list react-server-dom-webpack
npm list react-server-dom-turbopack
# For yarn projects
yarn why react-server-dom-webpack
yarn why react-server-dom-turbopack
If you’re using Next.js, check your Next.js version:
npm list next
Next.js versions 15.x and 16.x using App Router inherit the vulnerable React Server Components packages.
Network-Based Detection
Look for indicators of exploitation attempts in your logs:
- HTTP POST requests with next-action or rsc-action-id headers
- Request bodies containing $@ patterns
- Request bodies containing “status”:”resolved_model” patterns
Host-Based Indicators
Signs your server may have been compromised:
- Unexpected execution of reconnaissance commands (whoami, id, uname)
- Attempts to read /etc/ passwd
- Suspicious file writes to /tmp/ directory
- New processes spawned by Node.js/React application processes
Technical Details: How the React2Shell Exploit Works
React Server Components communicate using a protocol called Flight. When a client needs server-rendered data, it sends a request to a server endpoint. The server parses the payload, executes server-side logic, and returns a serialized component tree.
The vulnerability exists in how the server parses incoming payloads. Vulnerable RSC packages trust received data too implicitly. Instead of validating request structure and ensuring it originates from legitimate client code, the server deserializes arbitrary user-supplied data.
The exploit chain:
- Attacker submits a Flight payload containing a crafted object that resembles an internal “Chunk”
- The fake Chunk defines a custom then method
- React’s deserialization attempts to resolve the Chunk as a Promise
- Promise resolution calls the attacker-controlled then method
- The handler provides access to internal parsing state, including the _response object
- The attacker modifies state so React later calls attacker-chosen server functions
- Those functions become the RCE path
This attack requires no authentication, no user interaction, and works against any exposed RSC endpoint. That’s why it received a maximum CVSS score of 10.0.
Does StackHawk Detect React2Shell Vulnerabilities?
Yes. StackHawk detects React2Shell (CVE-2025-55182) using plugin ID 40058.
The scanner sends crafted Flight protocol payloads to your application’s endpoints and analyzes the responses. Detection works by identifying specific response patterns—either 400-500 error codes indicating payload processing or successful output from non-destructive test commands. This confirms the vulnerability is actually exploitable in your running application, not just that you have an outdated package in your dependency tree.
What makes StackHawk’s React2Shell detection different?
- Confirms actual exploitability. Instead of just telling you that you have an out-of-date library, we detect whether your application has a discoverable and exploitable React2Shell vulnerability.
- Validates your fix. After patching, run a scan to confirm you’ve successfully mitigated the issue.
- Simple configuration. Tests run as part of your normal StackHawk scans—no special setup required.
- CI/CD integration. StackHawk’s runtime testing is designed to run directly in your pipeline so you can catch React2Shell before it reaches production.
To see React2Shell detection in action, check out the StackHawk documentation.
Does Using StackHawk Expose Any Risk of React2Shell Attacks?
No. The StackHawk service does not use React Server Components within our infrastructure. Our web applications are not built on vulnerable versions of React or Next.js with App Router. StackHawk’s platform and scanner are not affected by CVE-2025-55182.
The StackHawk scanner (HawkScan) operates as a testing tool against your applications. In typical deployment scenarios:
- StackHawk’s scanner does not process React Server Component payloads as a server would—it sends requests to your application, rather than receiving Flight protocol requests.
- StackHawk’s scanner is ephemeral in nature, reducing or completely removing the possibility of persistence due to any RCE.
- StackHawk’s scanner runs inside a customer’s environment and should not be publicly exposed to attack.
What React2Shell Reminds Us
React2Shell joins Log4Shell in the hall of fame for critical vulnerabilities, receiving maximum severity scores. Both share common characteristics: ubiquitous library usage, trivial exploitation, and near-instant weaponization by threat actors. (And both were reported during the holiday season.)
The lesson is familiar but bears repeating: keeping dependencies updated isn’t optional. When critical vulnerabilities drop, you need confidence in what you’re running and the ability to test whether you’re actually vulnerable—not just whether your package.json is out of date.
StackHawk gives development teams that confidence. Runtime security testing tells you what’s actually exploitable in your running application. Knowing you have an outdated package is useful—knowing whether that outdated package is actually reachable and exploitable is what lets you sleep at night.
For questions about StackHawk’s response to CVE-2025-55182 or our detection capabilities, contact us at security@stackhawk.com.
