Welcome to "Honeypot Tales," an ongoing series of posts by our Director of Incident Response, Tyler Hudak, sharing stories from the front lines of cybersecurity.
When CVE-2025-55182 and CVE-2025-66478—collectively known as React2Shell—hit the headlines as a perfect 10.0 CVSS vulnerability, we knew what had to be done. Within days of the announcement, public proof-of-concept exploits were already circulating. At Inversion6, whenever a widespread vulnerability starts making waves, we spin up honeypots to watch how attackers exploit it in the wild.
React2Shell affects React versions 19.0-19.2 and Next.js versions 15.x or 16.x, allowing remote code execution on vulnerable systems. In plain terms, successful exploitation gives attackers complete control: downloading files, executing commands and maintaining persistent access—the works. (For a deeper dive into the technical details of this vulnerability, check out our React2Shell forensics analysis.)
We set up two honeypots: one Linux, one Windows. Both ran vulnerable versions of React with servers exposed directly to the internet. To monitor what happened next, we deployed SentinelOne for endpoint detection and full packet capture (PCAP) recording to catch every byte of network traffic.
Then we waited. Well, sort of.
We didn't have to wait long. Attacks started hitting the Linux honeypot in under five minutes. Keep in mind this was only two or three days after React2Shell had been publicly disclosed. The speed told us everything we needed to know: attackers were already weaponizing this vulnerability at scale.
Many initial attacks were simple validation checks—commands that echoed phrases or performed basic calculations to confirm the system was vulnerable. If the attacker got the expected response, they knew they had a live target.

The Linux system fell fast. As soon as the attacks ramped up, crypto miners appeared. This is a pattern we've observed across multiple honeypot exercises over the years: whenever a new high-impact exploit drops, crypto miner operators are the first ones to weaponize it at scale. Within hours, so many crypto miners had infected the Linux honeypot that we had to shut it down temporarily.

The Windows honeypot told a different story. While it was immediately targeted, most attackers were running Linux commands against it. The exploits worked—the vulnerability was successfully triggered—but the post-exploitation commands failed because they weren't compatible with Windows.
Occasionally we'd see an attacker run a successful Windows command, but these were still just vulnerability checks, not full exploitation attempts.
After several days of this pattern, one attacker finally got it right. They successfully exploited the Windows system and loaded malicious code.
That code? A crypto miner, naturally.
After a few weeks, we brought the Linux honeypot back online to see if attack patterns had shifted. Typically, once a vulnerability has been public for a while and many systems are patched, we see fewer opportunistic attacks like crypto miners and more targeted operations—ransomware precursors, for example.
React2Shell was different.
Within minutes of coming back online, the honeypot was compromised again by crypto miners. While the rate of attacks had decreased compared to the initial frenzy, we still saw several successful crypto miner infections within the first hour.
For organizations affected by React2Shell, the threat is real and ongoing. Many security researchers have compared this vulnerability to Log4Shell from a few years ago, and the comparison is apt. Both earned perfect 10.0 CVSS scores. Both allowed remote code execution. Both were aggressively exploited within days of disclosure.
If your organization is running vulnerable versions of React or Next.js and hasn't patched yet, assume your systems are already compromised. The attackers didn't wait—and neither should you.