React2Shell: Technical Deep-Dive & In-the-Wild Exploitation of CVE-2025-55182

We break down the exploit mechanics and detail active in-the-wild attacks observed by our team, from credential harvesting to sophisticated cloud backdoors.

17-12-2025 - Added information about new post exploitation payloads utilizing Node for fileless persistence and exfiltration.

The disclosure ofCVE-2025-55182, a critical Remote Code Execution (RCE) vulnerability in React, has sent shockwaves through the industry. Dubbed"React2Shell,"this vulnerability allows attackers to bypass security boundaries and execute arbitrary code on the server by exploiting improper input deserialization within React Server Components (RSC).

While initial reports have rightly focused on Next.js due to its massive popularity and default exposure, our research indicates the rabbit hole goes much deeper. This is not merely a framework-specific bug; it is a fundamental issue with how RSC payloads are handled, with implications reaching far beyond the Vercel ecosystem.

In this post, we present our extensive research into React2Shell. We will move beyond the basic headlines to explore:

Active Exploitation:Exclusive data from Wiz regarding what we are observing in the wild right now, from opportunistic cryptominers and "smash-and-grab" credential harvesting to sophisticated, persistent backdoors leveraging Sliver implants.

The Broader Scope:Why frameworks likeWakuandVite(with RSC plugins) are also vulnerable, and how the "default open" nature ofNext.js- specifically thenext-actionheader - makes it a prime target.

The Technical Mechanics:A deep dive into the deserialization logic, the self-referencing "gadget" chains, and how exactly the released PoC gets to RCE.

Whether you are patching a Next.js application, architecting a custom React server, or defending cloud-native workloads, understanding the mechanics of this exploit is critical.For detection and remediation guidance see our responseblogpost.

We’ve observed a rapid wave of opportunistic exploitation of CVE-2025-55182, with attackers pivoting quickly from simple recon to hands-on-keyboard abuse in cloud-native environments. Most attacks target internet-facing Next.js applications and other containerized workloads running in Kubernetes and managed cloud services.

In multiple cases, attackers used the vulnerability to obtain an interactive shell inside application containers (for example, Next.js frontends running in Kubernetes/GKE). From there, we consistently see:

Environment and identity discovery:whoami,hostname, environment variable dumps, and enumeration of/etc/passwd, often wrapped into one-liners and sent back to attacker-controlled infrastructure or oastify domains viacurlornc.

DNS-based beaconing: extensive use of oast*. domains and similar callback infrastructure to confirm code execution and network egress from cloud workloads, often embedding application-specific hostnames and URLs into the callbacks to fingerprint the target environment while these might be noise from scanners and bug bounty hunters a lot of those commands sent environment variables to the oast.* domains, acting beyond what is needed for simple scanning.

In several incidents, we saw the exploit chain progress from simple connectivity checks to fully interactive reverse shells directly from the application runtime (Node.js / Next.js processes) to external command-and-control servers.

Multiple campaigns show a strong focus on cloud and developer credential theft:

One actor used a reverse shell to systematically dump npm, AWS, Docker, Git, SSH and applicationpackage.jsondata from a Next.js server, all base64-encoded for exfiltration.

A separate campaign executed a Base64-encoded script that:

Scrapes environment variables for cloud and application secrets (e.g.,AWS,TOKEN,SECRET,PASS,DB_).

Recursively scans key filesystem paths (/home,/root,/etc,/var/www,/opt) for config and key material (*.env, JSON/YAML configs, SSH keys, etc.), while avoiding large or noisy files.

Attempts to access the cloud instance metadata service at169.254.169.254/latest/meta-data/iam/security-credentials/to retrieve IAM credentials, indicating clear cloud-specific privilege escalation intent.

Another large, standalone shell script retrieved by attackers performs broad secret harvesting at scale:

Walks/rootand all/home/*directories.

Targets common cloud/dev paths such as.ssh,.aws,.kube,.config/gcloud, and multiple cryptocurrency wallet locations.

Captures environment, OS details, network interfaces, process list (ps aux), and network connections (netstat -anpt).

Bundles all findings into a single report file and uploads it via HTTP POST to attacker-controlled infrastructure, using whichever tool is available (curl,wget, orpython).

This behavior highlights a clear trend: attackers treat compromised containers as credential collection points for both cloud control planes and adjacent developer tooling.

We observed several distinct cryptomining campaigns leveraging CVE-2025-55182, all targeting cloud workloads:

One campaign dropped a UPX-packed XMRig variant and used custom infrastructure to distribute shell scripts that:

Kill competing miners and processes.

Attempt local privilege escalation (e.g., via CVE-2021-4034).

Masquerade as plausible system processes (e.g.,systemd-devd) to blend into container process lists.

Another campaign simply pulled stock XMRig from GitHub, configured with attacker-controlled mining pools, and ran it from writable locations like/tmp.

In more advanced activity, actors retrieved installer scripts from c3pool and executed them via an interactive shell, wiring the cryptominer to Monero wallets and usingnohup /var/tmp/crondas a disguised persistence mechanism inside the container.

Several of these campaigns are multi-tenant, reusing the same script families and infrastructures (anywherehost[.]site,inerna1[.]site, and related hosts) across different customers and clusters.

Beyond mining, at least one campaign deployed a fully featured backdoor:

Attackers downloaded shell scripts from a dynamic DNS host that in turn fetched Sliver payloads (64-bit ELF binaries) and executed them from temporary locations.

These Sliver implants communicated with an external C2 over IP infrastructure that reused TLS certificates and domains across multiple samples, indicating a dedicated attacker-controlled ecosystem rather than opportunistic commodity malware.

This represents a meaningful escalation from “smash-and-grab” cryptomining to long-term access and operator-driven post-exploitation inside cloud workloads.

One of the more sophisticated technique we have observed involves "monkey patching" the Node.js runtime to implant a persistent backdoor directly into the memory of the application server.

Instead of running a one-off command or dropping a malicious file to disk, this payload dynamically imports core modules (node:http,node:url) and overrides thehttp.Server.prototype.emitmethod. This effectively hooks intoeveryincoming HTTP request at the lowest level of the Node.js stack, bypassing Next.js routing entirely.

The payload functions as a "magic path" webshell. It passively monitors traffic until it detects a specific, URL path (/favicon.login.ico). When triggered, it executes commands provided via query parameters; otherwise, it passes traffic normally to the application, making it nearly invisible to standard log analysis.

Distinct from the shell-based attacks described above, we have observed a quieter, more insidious class of payloads:Node-native execution.

Unlike standard reverse shells that fork a new process (e.g., spawning/bin/shorcurl), these payloads execute entirely within the memory of the running Node.js process. By leveraging the existing runtime environment, attackers can bypass runtime security rules configured to alert on suspicious child process creation.

The following payload, captured in the wild and de-obfuscated, demonstrates this technique. It dynamically loads internal modules to harvest and exfiltrate sensitive data without ever leaving the Node.js event loop

Overall, the observed activity shows a clear pattern: attackers are using CVE-2025-55182 not just to run one-off commands, but to gain interactive, cloud-aware access to containerized workloads, aggressively harvest secrets, weaken local defenses, and monetize access through cryptomining and backdoor deployment.

One important aspect we noticed was missing in other coverage of this Proof-of-Concept (PoC) is its applicability to other non-Next.js platforms that utilize React Server Components (RSC).

We believe Next.js was the primary focus for two main reasons:

It is the most popular framework using the RSC feature.

The RSC feature is enabled and exposed by default on all Next.js applications.

This second point is crucial, as it explains the PoC's potency: any Next.js application - whether or not it has Server Actions defined - has the vulnerable flow accessible simply by adding thenext-actionheader to the HTTP request. There is no need to guess or find a correct action name; all payloads sent with this header are parsed.

Because of this ease of exploitation, other platforms where this vulnerable flow is reached differently may have been excluded from the initial conversation, but they remain extremely vulnerable.

In our internal research, we successfully executed code using this PoC (with minor adjustments) on both Waku and Vite (with the RSC Plugin). With only minor modifications to the PoC, we are confident that more frameworks are vulnerable and would require only very minor adjustments to be exploited as well.

In a custom "native" React setup, the decoding logic is only invoked if the developer has explicitly architected a server to support RSC. The vector requires the attacker to identify the specific, custom endpoint where the server manually calls the decoder function.

After finding the endpoint to reach the server actions logic any application using the vulnerable react versions is susceptible to this exploit.

That means that detection of vulnerable servers must be done holistically both with dynamic scanners with the current PoCs but also with code and disk validation that can detect the vulnerable packages in lesser known platforms or “native” react implementations.

Since there are already excellent online explanations of this vulnerability - for example,Guillermo Rauch’s (Vercel’s CEO) - we will focus on explaining the main points briefly.

The vulnerability exploits improper inputdeserialization of React Server Component (RSC) form data payloads. By crafting a malicious payload, an attacker can achieveRemote Code Execution (RCE).

Let's break down the proof-of-concept (PoC) payload, which relies on a complicated structure with several self-references:

The payload works by replacing legitimate objects with attacker-controlled "gadgets" during deserialization, as the vulnerable code lacks type checking in crucial points.

Chunks 2 and 3 (The Function() Gadget):

'3': [] is a simple empty array.

'4'._formData.get is pointed to$3:constructor:constructor.

An array's constructor is Array.

Array.constructor is the nativeFunction()constructor.

This Function() constructor is theprimary RCE gadget, as it behaves similarly to eval(), creating a callable function from a string of JavaScript.

'4'._prefix holds the malicious JavaScript to be executed: 'console.log(7*7+1)//'.

‘2’: points to `$@3` this tells the de-serializer to treat the chunk as aPromiseobject, which causes our `.then` to be executed later.

Chunk 4:

This object mimics the internal Response object used by the deserializer, but with properties pointing to our gadgets:

_formData.get->Function()

_prefix->Our Arbitrary Code

Chunk 1:

This object is designed to look like a Chunk object, but it references our crafted Response object (_response:$4).

The vulnerability is triggered during the deserialization logic so lets follow this logic step-by-step

Initial Resolution:Parsing begins with'0': '$1', leading to the resolution ofChunk 1.

Gadget Injection:Resolving Chunk 1's`_response`: '$4'forces the deserializer to resolve Chunk 4. During this process, Chunk 4's_formData.getis set to theFunction()gadget, and its_chunksproperty is set via '$2:_response:_chunks', which is necessary to correctly link the object into the deserialization context.

Promise Chain Trigger:The core of the exploit lies in Chunk 1's value property, which is a nested JSON object designed to trigger a promise chain:

'value':'{"then":"$3:map","0":{"then":"$B3"},"length":1}'

RCE Trigger:The innermost reference,$B3, is processed. This triggers the vulnerable code snippet:JavaScript

The response object here is our craftedChunk 4.

The call becomes Chunk_4._formData.get(Chunk_4._prefix + obj).

This effectively executes:Function( 'console.log(7*7+1)//' + obj ).

Final Execution:The resulting anonymous function containing the attacker's code is returned up the promise chain and is ultimately called by the then resolutions, resulting incode execution.

For a broader look at how Wiz helps teams identify, prioritize, and respond to vulnerabilities like this across their cloud environment, check out our latest post:React2Shell (CVE-2025-55182): Everything You Need to Know About the Critical React Vulnerability

44VvVLU2Vmja6gTMbhNHAzc7heYTiT7V mQEXkjdaYo6K41WqH8qWw1CL8wKAAgz5 xLYT3XL3pb9KCUZS7PPZbzUGCCpZ9Ee

42NTfUjbU3Gj536zubU7vpjfC7X9DPEC ciwbCXrrjBk5KqkJS1Xq4saVgQLP1yqU YHKzn7apt1p3W6mDWm87n3nwDEmWeSh

Detect and mitigate React2Shell (CVE-2025-55182), critical RCE vulnerability in React and Next.js exploited in the wild. Organizations should patch urgently.

Check out new product releases that help security and engineers work together to keep cloud environments secure

Modern code runs in complex and distributed cloud environments. Wiz SAST meets this complexity by correlating code flaws with real cloud context–including where workloads run, what they can access, and how exposed they are.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings