Between August 13 and October 13, our team at Arc Technologies recorded 1,440 attempts to exploit React2Shell (CVE-2025-55182) against the applications we host for our clients. None of them worked. It would have been easy to close those alerts as noise and move on. Instead, we took apart every request to see what the attackers were really after, and what would have happened if they had succeeded.
What React2Shell is
React2Shell is a CVSS 10.0 flaw in React Server Components, disclosed in December 2025. A single unauthenticated web request to a vulnerable Next.js or React Server Components app can make the server run the attacker’s code. No login and no user interaction are needed. Patches have been out for ten months, yet attackers are still scanning for anyone who hasn’t applied them.
What we saw
- 1,440 exploitation requests over 61 days, on 58 of 62 days in the window
- 597 unique source IPs. 95% were used once and never seen again, and 81% came from Google Cloud address space.
- 46 of 46 hostnames probed, including preview and development environments
- 11 distinct payload families once we decoded every layer of encoding
The attacks also escalated over time. Volume peaked in early September and has since dropped, but the payloads got more dangerous as it fell. Early traffic was simple “are you vulnerable?” checks. By October we were receiving credential harvesters built for cloud and Kubernetes environments. One attempts to read the pod’s service account token and asks the Kubernetes API for every secret in the namespace. Another profiles the server for cryptomining by checking for the AVX2 CPU feature, and flags “high value” victims holding cloud keys, crypto wallets or email-sending API keys.
Attackers also tested ways to slip past defences: 4 KB of junk padding, Unicode and double URL encoding, HTML entities, Arabic-Indic digits in place of regular numbers, and hex-encoded second stages. One operator tried seven encodings in a single session against one site.
What would have happened
This is the part we most want people to take away. We modelled each attempt as if it had reached a vulnerable application:
- Every host would have been compromised. A new attacker reached each host about every 37 hours.
- Not by one attacker, but by many: 631 separate attacker-and-host pairs would have had code execution, an average of 13.7 per host and 33 on the most targeted.
- On one dashboard, six weeks of “harmless” canary checks were followed by a harvester that would have taken the entire secret store in three seconds.
- On one client website, four unrelated groups would each have walked away with every environment variable: database credentials, API keys and email keys.
Why we weren’t affected
The applications we host don’t use React Server Components, so the vulnerable code wasn’t there to exploit. That is a strong position, but not a permanent one. A single new app built on Next.js would change it overnight.
Lessons for defenders
- Treat canary traffic as reconnaissance. The harmless checks are how targets get listed for the harvesters that follow.
- Detect payloads, not IP addresses. Attackers rent fresh cloud servers for every run.
- Decode requests before you match them. Signatures that only look at the raw request miss the evasive variants.
- Assume every subdomain is known, including preview and dev.
- Design for the day a workload is compromised: don’t mount service account tokens where they aren’t needed, restrict outbound traffic, and enforce IMDSv2 (the more secure version of the cloud metadata service that hands out server credentials).
- Patch. There is no workaround.
Read the full anonymized report, including indicators of compromise and detection patterns HERE .
