Hunting React2Shell (CVE-2025-55182): From Prototype Pollution to Remote Code Execution
VULNERABILITIES
f0xyPr0xy
12/15/20254 min read


A newly disclosed critical vulnerability in React Server Components has exposed a severe attack surface for publicly accessible web applications. Exploitation of this flaw enables adversaries to achieve remote code execution (RCE), effectively granting them control over vulnerable servers. Once compromised, attackers can deploy persistent backdoors, install cryptominers, and exfiltrate sensitive data, turning affected applications into high-value targets.
The issue impacts specific versions of the React Server DOM packages — 19.0, 19.1.0, 19.1.1, and 19.2.0 across
react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, making immediate awareness and remediation critical for organizations relying on these components.
Prototype Pollution–Based Code Execution Exploit
CVE-2025–55182 represents a dangerous prototype-pollution–based code execution vulnerability in JavaScript applications. By abusing prototype pollution, an attacker can inject malicious properties into the global object prototype, silently influencing the behavior of all objects across the application.
This systemic manipulation can lead to severe consequences, including security logic bypasses, application-wide denial of service, and, in the most critical scenarios, full remote code execution.


A security weakness that allows an attacker to poison JavaScript’s Object.prototype with malicious properties, causing those properties to be inherited by all objects and potentially enabling logic bypasses, privilege escalation, or even remote code execution.
Understanding React2Shell
React2Shell is an attack technique that exploits insecure handling of React Server Components, where attacker-controlled input can trigger issues such as prototype pollution or promise confusion. By abusing these weaknesses, an adversary can manipulate the server-side execution flow and ultimately achieve remote code execution, effectively gaining shell-level access to the server.


The underlying cause of the vulnerability is an unsafe deserialization flaw. When a server processes attacker-controlled payloads without proper validation, it becomes possible to influence server-side execution flow.
In this case, crafted input allows an attacker to inject logic that the server interprets in a privileged context.


At its core, the vulnerability stems from unsafe deserialization. When the server processes untrusted payloads without strict validation, a crafted input can influence how server-side logic is executed. In the case of React2Shell, specially constructed requests allow malicious logic to be interpreted in a privileged server context.
As a result, a carefully crafted HTTP request containing command execution logic can be processed by the vulnerable application, leading to direct execution of commands on the web server and returning the output to the attacker.
Hunting React2Shell: What to Look For
Since these attacks primarily target publicly exposed web servers, the investigation strategy should focus heavily on web access logs and network telemetry. In many cases, the most reliable evidence resides within network-level logs, as attackers typically deliver the exploit through specially crafted HTTP POST requests.
During analysis, defenders should look for anomalous or unexpected POST requests that carry suspicious payloads or patterns indicative of embedded host-level commands, as these often signal an attempt to manipulate server-side execution and achieve code execution.

Since the attack is delivered over HTTP, the packets can be directly inspected; however, when HTTPS is used, payload visibility is effectively lost, leaving little to no insight into the contents of the traffic.


The following Wireshark query can help effectively identify and prioritize traffic potentially associated with React2Shell activity. However, because this approach relies on pattern matching and correlation, the results require additional validation and cross-correlation, as false positives may occasionally occur.
Query :
http.content_type == "application/x-www-form-urlencoded" || http.content_type == "multipart/form-data" ||
http.content_type == "next-action" || http.content_type == "rsc-action-id"

Process Exection
From a process execution perspective, activity is often observed where node.exe spawns cmd.exe to execute remote commands. Monitoring command-line executions initiated by Node.js can provide valuable insight into the types of commands adversaries are attempting to run and help identify malicious behavior patterns.
node.exe
└── cmd.exe
└── powershell.exe
Modern EDR/XDR platforms are generally effective at detecting suspicious command execution patterns, such as Node.js spawning system shells, making them a strong layer of defense against attacks like React2Shell.
Defending against React2Shell requires a layered security approach—from secure coding practices and strict input validation to improved visibility across network, application, and endpoint telemetry. While HTTPS limits payload inspection, behavioral detection through web logs, process monitoring, and EDR/XDR analytics remains highly effective, especially for identifying suspicious patterns such as Node.js spawning system shells.
Ultimately, React2Shell is more than a framework-specific flaw—it underscores a broader lesson in secure server-side application design. Even with advanced security solutions in place, organizations must keep dependencies up to date and continuously evolve their detection and response strategies to remain ahead of emerging adversary techniques.
All rights reserved © 2025 MalwareHunts. For educational and research purposes only. MalwareHunts is not responsible for any misuse of the information provided.