Understanding and Mitigating CVE-2025-55182 (React2Shell)

Designated CVE-2025-55182 and widely dubbed "React2Shell," this vulnerability represents a worst-case scenario for modern web applications: Unauthenticated Remote Code Execution (RCE) on default configurations.

What is CVE-2025-55182?

At its core, CVE-2025-55182 is an unsafe deserialization vulnerability assigned a severity score of Critical (CVSS 10.0). It allows an attacker to execute arbitrary code on a server simply by sending a malicious HTTP request, without requiring any login credentials or special privileges.

Note: While the core vulnerability is CVE-2025-55182 (React), Next.js specific tracking is often referenced as CVE-2025-66478. Both refer to the same root cause in this context

The mechanism

The vulnerability resides in the React Server Components (RSC) architecture, specifically within the "Flight" RPC (Remote Procedure Call) protocol used to communicate between the client and the server.

When a user interacts with a Next.js or React 19 application — for example, submitting a form via a Server Action — the data is serialized (converted into a string format) to be sent to the server. The server then deserializes this data to process the request.

The flaw

The React Security Team and Vercel disclosed that the server-side deserializer failed to strictly validate incoming object keys.

The specific failure allows attackers to inject forbidden JavaScript properties — such as _ _proto_ _, constructor, or prototype — into the payload. This Server-Side Prototype Pollution effectively "poisons" the application state. When the server processes this polluted object, it unwittingly triggers a "gadget chain" that executes the attacker's system commands.

Affected ecosystems

Because this vulnerability exists in the core React library handling Server Components, the blast radius is significant. It affects not just specific frameworks, but any toolchain leveraging RSC.

Primary Targets:

• React Core: Versions 19.0.0 through 19.2.0.
• Next.js:
  
  • v16.x (Prior to v16.0.7)
  • v15.x (Prior to v15.5.7)
  • Legacy v14.x Canary releases utilizing the App Router.
• RSC-Enabled Frameworks: Waku, RedwoodJS, and custom implementations using the Vite RSC plugin.

Why React2Shell is uniquely dangerous

Unlike previous vulnerabilities that required specific, non-standard configurations to exploit, CVE-2025-55182 is actionable on default installations. 

Note: Security researchers have confirmed that the attack vector is a simple HTTP POST request. If your application exposes a Server Action or an RSC endpoint to the public internet, it is effectively vulnerable until patched.

How to mitigate the impact of CVE-2025-55182

Given the "Critical" severity rating and the public availability of exploit code, immediate action is required. Mitigation strategies fall into two categories: Remediation (Patching), which is the only permanent fix, and Mitigation (WAF Rules), which serves as a temporary shield.

1. Patch Immediately

The React team and Vercel have coordinated a simultaneous release of patched versions. You must upgrade your dependencies to the versions listed below or higher.

React (library level) 

If you are using React directly or a framework other than Next.js that relies on React 19, ensure react and react-dom are updated to:

• v19.0.1
• v19.1.2
• v19.2.1

Next.js (framework level) 

Next.js users should upgrade to the latest patch release for their major version. Safe versions include:

• Next.js 16: Upgrade to v16.0.7 or later.
• Next.js 15: Upgrade to v15.5.7, v15.4.8, v15.3.6, v15.2.6, v15.1.9, or v15.0.5.

Dependency warning: If you are using frameworks like Waku, RedwoodJS, or Parcel, you may not see a top-level update for your framework immediately. You must inspect your package-lock.json or yarn.lock to ensure the nested react version is resolved to one of the patched versions listed above.

How to detect if you have been impacted

Patching closes the door for future attacks, but it does not tell you if someone has already walked through it. To determine if your infrastructure was targeted or compromised prior to mitigation, you must analyze both your network logs and host behavior.

Network traffic analysis

The first line of detection involves reviewing HTTP access logs for specific patterns associated with the "React2Shell" exploit.

Suspicious headers 

Filter your logs for HTTP POST requests containing the headers next-action or rsc-action-id. While these are legitimate headers used by Next.js and React, an unusually high volume of these requests — especially from a single IP address — may indicate scanning activity.

Payload signatures 

The most reliable indicator is found within the request body. Search your WAF or load balancer logs for the following strings:

• "$@": A sequence used in the exploit payload structure (often inside a JSON array).
• "status":"resolved_model": A specific JSON pattern used to trick the server into processing the malicious object.
• _ _proto_ _, constructor, or prototype: JSON keys attempting to pollute the object prototype.

Error rate anomalies 

Look for a sudden spike in 500 Internal Server Errors on your RSC endpoints. Because exploit payloads are often unstable or trial-and-error based, attackers frequently crash the server process multiple times before successfully achieving code execution.

Host-based indicators

If an attacker successfully bypasses your network defenses, the evidence will reside on the server itself. Detection here relies on spotting behaviors that are technically possible but operationally abnormal for a web server, starting with how the application interacts with the underlying operating system.

Unexpected process spawning 

This is the highest-fidelity indicator of a breach. In a standard React/Next.js environment, the node process should almost never spawn shell commands. Monitor your Endpoint Detection and Response (EDR) tools for node processes spawning:

• Shells: sh, bash, cmd.exe, powershell.
• Network utilities: curl, wget (often used to download second-stage malware).
• Reconnaissance tools: whoami, id, uname.

File system artifacts 

Scanners and attackers often leave behind evidence in temporary directories. Check /tmp (Linux) or %TEMP% (Windows) for:

• Files named pwned.txt, test.txt, or random alphanumeric strings.
• Zero-byte files created to test write permissions.

Additionally, monitor for unauthorized read attempts on sensitive system files, such as /etc/passwd or environment variable files (.env), which attackers often target immediately after gaining access.

Automated scanning and validation

To confirm if your application is still exposed without manually crafting exploits, utilize vulnerability scanners that have updated their definitions for CVE-2025-55182. Tools like UpGuard have released non-intrusive checks that send "probe" packets to check whether you are running a vulnerable environment, even if a firewall is protecting you.