React2Shell CVE-2025-55182: What I Learned Battling This Beast for a Week

This recovering CISO shares hard-won lessons hunting React2Shell CVE-2025-55182. Why your SIEM missed it, evolving IOCs, and AWS detection approaches that work.

I’ve spent way too much time on React2Shell this past week. Way too much. Between customer calls, threat hunting sessions, and building detection logic that actually works, I’ve learned more about CVE-2025-55182 and CVE-2025-66478 than I ever wanted to know. The biggest thing I learned is that your current detection stack either missed it or triggered a false positive. With 77,000+ vulnerable IP addresses exposed globally and China-nexus threat actors weaponizing this within hours of disclosure, you don’t have time for a learning curve. Let me save you some pain.

The vulnerability that broke assumptions

React2Shell isn’t your typical web application vulnerability. It’s a CVSS 10.0 remote code execution flaw in React Server Components that requires zero authentication. No credentials. No valid session. Just a crafted HTTP POST request with a Next-Action header and a payload that exploits prototype pollution in React’s Flight protocol.

The attack chain is elegant in its simplicity. React’s Flight protocol uses reference codes to traverse object properties. Attackers discovered they could reach Chunk.prototype.then via a proto traversal, then chain that to the Function constructor with attacker-controlled JavaScript. The payload executes during chunk reference resolution, before Next.js even validates the action. You read that right. The RCE happens before input validation.

What makes this particularly nasty is the attack surface. Wiz Research found 39% of cloud environments contain vulnerable instances. If you’re running Next.js 15.x or 16.x with App Router enabled, you’re in scope. React 19.0.0 through 19.2.0 with the usual suspects: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack.

CISA added this to the Known Exploited Vulnerabilities catalog on December 5 with a Federal remediation deadline of December 26. When CISA moves that fast, pay attention.

Your SIEM vendor is lying about detection coverage

Here’s where I get annoyed. I’ve watched multiple security vendors publish blog posts claiming their products detect React2Shell. Some do. Most don’t. At least not reliably.

Let me explain why this vulnerability breaks traditional detection approaches. The exploit uses standard HTTP POST requests. The headers look legitimate. The Content-Type is multipart/form-data, which your applications probably use constantly. The malicious payload hides in form fields using React’s proprietary serialization format. Your SIEM wasn’t built to parse Flight protocol. Neither was your WAF, unless your vendor pushed a very recent update.

I ran into this firsthand with several customer environments last week. Our detection tools triggered on legitimate traffic. A lot of legitimate traffic. The patterns that identify React2Shell payloads, things like $@ references and resolved_model status codes, appear in normal RSC application behavior. Curl commands? Yeah… used in backups. One customer’s detection rule generated 3,000 alerts in four hours. None were actual attacks. All were their application doing exactly what React Server Components are designed to do.

The false positive problem gets worse. Post-exploitation commands like whoami, id, and curl are legitimate tools in enterprise environments. Your developers use them. Your monitoring systems use them. When React2Shell executes these commands, they look identical to normal operations unless you’re correlating the command execution with the parent process and the originating HTTP request. Most SIEMs can’t do that correlation in real-time.

I’ve had vendors tell me their ML-based detection handles this automatically. I asked for specifics. They couldn’t provide them. One vendor’s “React2Shell detection” turned out to be a regex matching proto in request bodies. That’s table stakes, not detection. Attackers are already using WAF bypass techniques that prepend 128KB of junk data to push the payload past content inspection limits.

If your security vendor is telling you they’ve got this covered, ask them how. Ask for the detection logic. Ask about false positive rates. Ask what happens when the attacker uses a bypass technique. The answers will be illuminating.

IOCs are evolving faster than your threat intel feeds

The threat intelligence picture for React2Shell changes daily. I’m not exaggerating. GreyNoise reported that 50% of scanning IPs they observed were fresh, first seen in December 2025. Attackers rotate infrastructure constantly. The IP addresses published in initial vendor reports are already stale. Some of them point to infrastructure that’s been taken down. Others have been replaced with new attack nodes.

Here’s what I’ve confirmed as relatively stable indicators. The C2 infrastructure includes IPs like 93.123.109.247, 45.77.33.136, and 194.246.84.13. DNS exfiltration targets ceye.io, dnslog.cn, and oastify.com domains. User agents like Go-http-client/1.1 and Assetnote/1.0.0 flag automated scanning. But AWS threat intelligence explicitly warns that attackers employ user agent randomization. Relying on UA-based blocking alone will fail.

The HTTP patterns are more reliable. Look for POST requests with Next-Action or rsc-action-id headers combined with multipart/form-data content types. Request bodies containing $@ patterns, proto strings, and resolved_model status indicators. These are harder for attackers to vary because they’re required for the exploit to function.

What concerns me most is the speed of integration into automated attack frameworks. This vulnerability is being incorporated into Mirai variants and other botnet exploitation kits. When script kiddies can point and click their way to RCE on React applications, the attack volume will explode. We’re not there yet, but we’re close.

My AWS hunting approach

I battled this beast mostly in AWS environments this week with GuardDuty and all of the things enabled. That’s not a criticism of AWS. The reality is that most of my clients run on AWS. When React2Shell hit, I needed detection capabilities that work across AWS Organizations with dozens of accounts and thousands of instances. Nothing off the shelf did what I needed.

So I started building something.

The approach focuses on correlating signals across multiple AWS data sources. CloudTrail tells me about API calls that shouldn’t happen, like GetCallerIdentity from application servers or unusual AssumeRole attempts. VPC Flow Logs reveal connections to known malicious IPs. WAF logs capture the HTTP layer indicators. GuardDuty provides the threat intelligence foundation through ThreatIntelSets.

The key insight is that no single data source catches React2Shell reliably. CloudTrail misses the initial exploitation. WAF logs miss the post-exploitation lateral movement. VPC Flow Logs don’t see the payload content. You need all of them working together with correlation logic that understands the attack chain.

I’m using GuardDuty ThreatIntelSets to flag connections to known C2 infrastructure. When GuardDuty generates a MaliciousIPCaller.Custom finding, EventBridge routes that to an alerting pipeline. But that only catches post-exploitation traffic to known bad IPs. For the HTTP layer, I’m parsing WAF logs with specific pattern matching for the Flight protocol exploitation indicators.

The cross-account piece matters because attackers don’t respect your AWS Organization structure. Once they compromise one application, they pivot. They query instance metadata. They steal IAM credentials. They attempt lateral movement through SSM or shared resources. A detection capability limited to a single account misses half the story.

I’m not ready to release this publicly yet. There’s more testing needed, especially around false positive tuning. But I’ll be open-sourcing it soon. If you’re struggling with the same AWS detection challenges, stay tuned.

What you should actually do right now

Patch. That’s the answer. There is no workaround. The vulnerability exists if React Server Components are merely supported, even without explicit Server Function usage.

npm install next@latest react@latest react-dom@latest

Patched versions are Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. React patched versions are 19.0.1, 19.1.2, and 19.2.1. If you can’t patch immediately, you have a problem. WAF rules buy time but attackers are actively developing bypasses.

For AWS environments, enable the AWSManagedRulesKnownBadInputsRuleSet version 1.24 or later in AWS WAF. It includes React2Shell rules. Enable GuardDuty if you haven’t already. Monitor CloudTrail for anomalous GetCallerIdentity calls from application instances.

Review your logs back to November 29, 2025. The vulnerability details were circulating before public disclosure. Look for reconnaissance commands spawned by Node.js processes. Check for file writes to /tmp directories. Look for outbound connections to the DNS exfiltration domains I mentioned earlier.

Rotate secrets. If your application had access to AWS credentials, API keys, database passwords, or anything else sensitive, assume they’re compromised. This applies especially if you can’t definitively prove you weren’t exploited. The absence of evidence isn’t evidence of absence when your detection capabilities have gaps.

For ongoing detection, think beyond signatures. Signature-based detection fails when attackers modify payloads. Behavioral detection that monitors for shell commands spawned by web server processes catches variations.

The bigger picture

React2Shell represents the fact that modern application frameworks introduce complexity that traditional security tools weren’t designed to handle. The Flight protocol is a proprietary serialization format. Your SIEM doesn’t understand it. Your WAF barely handles it. When vulnerabilities emerge in these framework-specific components, we’re playing catch-up.

This is why I keep beating the drum about understanding your attack surface at the application architecture level. Knowing you run Next.js isn’t enough. You need to know which features are enabled, which data flows exist, and which security boundaries the framework assumes you’ve implemented. React Server Components made certain assumptions about input sanitization. Those assumptions were wrong. The fix is a one-line code change, but the impact of the oversight is catastrophic.

The nation-state involvement here is significant. China-nexus groups, including Earth Lamia, Jackpot Panda, and UNC5174, weaponized this within hours of disclosure. That’s not opportunistic scanning. That’s coordinated capability development. These groups target specific industries: financial services, government, logistics, and manufacturing. If you’re in those sectors running vulnerable React applications, you should be treating this as an incident, not just a vulnerability.

30 organizations have been confirmed breached so far. That number will grow. The 77,000 vulnerable IPs represent the exposed attack surface. The actual compromise count depends on how fast defenders move versus how fast attackers scale.

Key Takeaway: Your detection stack probably has gaps for React2Shell, and patching is the only real fix.

Call to action

I’ll be releasing the AWS hunting toolkit I mentioned once testing is complete. If you want early access or want to contribute to the detection logic, reach out through RockCyber or Linkedin.

👉 Subscribe for more AI security and governance insights with the occasional rant.