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.

Since the initial disclosure and the release of initial patches, security researchers have uncovered two additional, related vulnerabilities that existed in the same affected packages—a Denial of Service (DoS) and a Source Code Exposure issue. It is crucial to note that the initial patches released to address the RCE were incomplete, leaving systems vulnerable to the new DoS and Code Exposure flaws. Immediate action is required to update to the latest patch version to secure your application against all known threats.

What is CVE-2025-55182?

1. Critical: Remote code execution (CVE-2025-55182 / "React2Shell")

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.

2. High severity: Denial of service (CVE-2025-55184 and CVE-2025-67779)

Discovered during attempts to exploit the initial RCE patches, this set of vulnerabilities allows an attacker to successfully crash or freeze your server process, denying service to legitimate users.

• Severity: High (CVSS 7.5)

The flaw

Security researchers discovered that a malicious HTTP request can be crafted and sent to any Server Functions endpoint. When this request is deserialized by React, it triggers an infinite loop that causes the server process to hang and consume excessive CPU resources, resulting in a performance impact and effectively denying users access to the product. CVE-2025-67779 was a follow-up fix addressing an incomplete patch for the initial DoS flaw (CVE-2025-55184).

3. Medium severity: Source code exposure (CVE-2025-55183)

This vulnerability allows an attacker to leak sensitive information directly from your Server Function code.

• Severity: Medium (CVSS 5.3)

The flaw

A malicious HTTP request sent to a vulnerable Server Function may unsafely return the source code of that function. If you have any secrets hardcoded within the Server Function (e.g., API keys, database connection strings), they may be exposed. This vulnerability is triggered when a Server Function explicitly or implicitly exposes a stringified argument.

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.

Initial Patches: 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 one of the following initial patch versions:

• 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.

Definitive Patches (for RCE, DoS, and Code Exposure)

The initial patch versions listed above are not sufficient and remain vulnerable to subsequent Denial of Service (DoS) and Source Code Exposure (CVE-2025-55183, -67779, 55184) issues.

To fully secure your application against all four known vulnerabilities, you must update to the following definitive patch versions or later:

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.

A sudden, sustained spike in CPU utilization may indicate a successful DoS attack (CVE-2025-55184 / CVE-2025-67779).

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.