Topic starter
25/10/2026 11:07 am
TL;DR: React2Shell exploitation has stayed active at high volume, GreyNoise counted more than 8.1 million attack sessions, over 8,163 source IPs across 1,071 ASNs and 101 countries, and 70,000 unique payloads since disclosure. React and Next.js deployments now need runtime and identity controls that limit what a compromised app can reach.
Editorial analysis by NHI Mgmt Group, based on content published by GreyNoise: “CVE-2025-55182 (React2Shell) Opportunistic Exploitation In The Wild: What The GreyNoise Observation Grid Is Seeing So Far”.
By the numbers:
- GreyNoise observed 8,163 unique source IPs across 1,071 ASNs spanning 101 countries.
Key questions
Q: Why do cloud-hosted exploitation waves make static IP blocklists less effective?
A: Because attackers can rotate source IPs, ASNs, user agents and payload shapes much faster than defenders can maintain manual blocks.
Q: What signs suggest a web RCE campaign has moved into post-exploitation staging?
A: Look for encoded PowerShell, in-memory downloaders, suspicious script execution, AMSI tampering and repeated proof-of-execution commands that return deterministic output.
Q: What breaks when a framework flaw allows unauthenticated server-side execution?
A: The main failure is that the application tier stops being a control boundary.
Practitioner guidance
- Patch exposed React and Next.js deployments first Prioritise internet-facing instances that can reach production data, cloud APIs or internal admin paths, then verify the fixed version is actually deployed across all environments.
- Replace static perimeter blocks with dynamic campaign blocking Use continuously updated threat feeds and fingerprint-based filtering so rotating IPs, ASNs and cloud hosts do not bypass a fixed denylist.
- Hunt for post-exploitation PowerShell activity Look for powershell.exe or pwsh.exe with encoded commands, DownloadString, IEX, AMSI tampering and suspicious script block patterns on affected Windows systems.
Bottom line: React2Shell is being exploited as an active campaign, so exposed framework instances should be treated as live access-risk endpoints rather than routine patch items.
Glossary terms: Unauthenticated Remote Code Execution, Proof of execution, AMSI Bypass, Exploit Campaign
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:14 pm
React2Shell has become an access-governance problem, not just a patching problem. Once unauthenticated RCE exists in a production framework, the issue is no longer limited to vulnerability management. The real question is what service credentials, runtime permissions and management paths are exposed behind the affected application layer. That is why this pattern belongs in identity and privilege governance discussions, especially where web applications can reach cloud APIs or internal services.
A question worth separating out:
Q: How do teams reduce the blast radius of unmanaged service accounts?
A: Teams reduce blast radius by narrowing permissions, removing inactive identities, and preventing credentials from persisting after their business purpose ends. The goal is to make every service account easy to attribute, easy to review, and easy to revoke when its workload changes or disappears.
👉 Read our full editorial: React2Shell exploitation shows a sustained, automated attack wave
This post was modified 7 days ago by NHI Mgmt Group