The University of Michigan‘s operational security team did something unusual in the hours after CVE-2025-55182 was disclosed. They advised that sites not behind Cloudflare should be taken offline. Not patched quickly. Taken offline. When an academic security team publicly recommends decommissioning production infrastructure, something has fundamentally changed.
That something is the asymmetry at the heart of React2Shell: attackers needed one working exploit chain to compromise thousands of servers. Defenders needed to secure every React Server Components deployment across every platform simultaneously. Darktrace researchers put a honeypot online and watched attackers land on it within two minutes of deployment. Cloudflare recorded 582 million exploit attempts in the first eight days, peaking at 12.72 million hits in a single hour. Unit 42 identified 968,000-plus exposed React and Next.js instances.
While the React2Shell crisis from every angle provides the full strategic overview, this article answers two questions that build on each other: what actually happened in the wild, and which defensive strategies worked against it. The comparison across Cloudflare Workers, Deno Deploy, and Vercel Edge reveals that the decisive variable was platform architecture, not patching speed.
How Are Attackers Exploiting React2Shell in the Wild?
CVE-2025-55182 was disclosed on December 3, 2025. Within 30 hours, GreyNoise had documented the first in-the-wild exploitation attempts. A public proof of concept emerged, the Metasploit module followed, and by December 5 Trend Micro recorded the first Cobalt Strike beacon, the first Sliver implant, and the first cryptomining campaigns. CISA added it to the Known Exploited Vulnerabilities catalog on December 6.
The attack surface discovery was methodical. Attackers used Shodan fingerprinting, Nuclei templates, and the Assetnote react2shell-scanner to enumerate vulnerable instances at internet scale, filtering by icon hashes, SSL certificate attributes, and framework metadata. Cloudflare noted that some threat actors excluded Chinese IP space while focusing enumeration on Taiwan and Xinjiang Uygur networks.
What began as mass scanning in early December had, by January and February, consolidated into sustained campaigns. GreyNoise observed two IPs generating 56 percent of all React2Shell traffic between them. One retrieved cryptomining binaries. The other opened reverse shells directly back to the scanner on port 12323. The actor diversity, China-nexus clusters like UNC6586 alongside DPRK-affiliated operations and cryptomining operators, meant no single motivation drove the exploitation — but every campaign traced back to the same mechanism. Understanding how the exploit chain works under the hood is essential for grasping what made this campaign diversity possible.
What Post-Exploitation Payloads Have Attackers Deployed via React2Shell?
The payload landscape reveals that the exploitation volumes represent something more structured than mass opportunism. Every category of threat actor operated through the same entry point at the same time.
Cryptominers were the most common payload. XMRig deployments targeted Node.js processes, connecting to C3pool, SupportXMR, and HashVault. Huntress documented a bash script that pulled XMRig from GitHub, installed it as a systemd service named “system-update-service,” and connected to HashVault over TLS. Alibaba Cloud specific variants uninstalled the provider’s own threat detection agent.
Cobalt Strike beacons, generated via CrossC2 for Linux targets, provided persistent access. Trend Micro found beacons installed under systemd services masquerading as “Rsyslog AV Agent Service,” with scripts containing AI-generated code and Chinese comments never removed. Sliver C2 implants followed the same pattern.
The credential harvesting was automated and indiscriminate. Cisco Talos documented UAT-10608’s campaign using TruffleHog, Gitleaks, and custom scripts to walk filesystems from working directory to root, reading every .env file, SSH key, and cloud credential. The NEXUS Listener web application catalogued credentials from over 766 servers, including OpenAI and Anthropic API keys, Stripe secrets, and Azure subscription credentials. Microsoft confirmed attackers targeted cloud IMDS endpoints across AWS, Azure, GCP, and Tencent Cloud.
Then there were the backdoors nobody had seen before. PeerBlight uses the BitTorrent DHT network for C2. CowTunnel tunnels through attacker-controlled FRP proxies. ZinFoq provides SOCKS5 proxying with timestomping, its file timestamps defaulting to 2016-01-15. Unit 42 found KSwapDoor, a P2P mesh backdoor with AES-256-CFB encryption, mimicking a kernel swap daemon. Botnet operators recruited servers into Mirai, RondoDox, and Kaiji botnets. Every category of payload, through a single deserialisation vulnerability in a framework protocol.
Which Platform Runtime Provides the Strongest Isolation Against RSC Exploits?
The defence answer changes depending on where the application runs, and why default configurations exposed so many deployments explains why the differences between platforms reveal more about architectural security than any CVE score.
Cloudflare Workers are immune to React2Shell exploitation. The Workers runtime uses V8 isolates with no shared process memory and no Node.js API surface. The process object, child_process, and require do not exist. This is architectural protection, not a patch response. Trend Micro confirmed that Edge Runtime is not vulnerable because it lacks the Node.js APIs that React2Shell RCE depends on for post-exploitation.
Cloudflare added WAF Managed Rules within hours of disclosure with default Block action across all plan tiers, creating a two-layer defence: the WAF blocks known exploit patterns at the network layer, and the V8 isolate sandbox neutralises any bypass that reaches the runtime. The limitation is that binary Flight protocol payloads challenge signature-based detection. WAF rules that block __proto__ keywords miss the minimum viable exploit entirely, and Trend Micro documented nearly 145 in-the-wild exploits with WAF bypass features.
Deno Deploy takes a different path to the same result. Deno’s security model denies filesystem, network, and subprocess access by default. Any exploit payload that lands and attempts execSync or a filesystem write hits the permission boundary before reaching the host. This is isolation at the runtime level, and it curtails post-exploitation capabilities even if deserialisation succeeds. The limitation is adoption: Deno Deploy’s market share is smaller, so fewer deployments benefit from this protection model.
Vercel’s Edge Runtime sits in a different category. As the default deployment for many Next.js applications, Vercel was the most directly affected. Its response was the coordinated May 2026 patch release across 13 advisories, fixing the deserialiser at the framework level. This fixes the root cause. Both strategies are valid, but they protect against different parts of the threat lifecycle: framework-level patching addresses the vulnerability directly, while runtime isolation contains what happens when it is exploited.
How Do Different WAF Approaches Compare for Blocking React2Shell?
While runtime isolation limits what a compromised process can do, WAF detection aims to stop the exploit before it reaches the runtime. The effectiveness of that detection depends on a specific technical capability: whether the WAF can parse the React Flight protocol’s binary serialisation format. Most WAFs were designed to inspect HTTP headers and form-encoded bodies. React2Shell exploits live inside POST bodies as chunk references and prototype pollution chains.
Cloudflare deployed WAF Managed Rules with default Block action across all plan tiers within hours of disclosure. Users received protection without touching their configuration. The detection engineering burden was absorbed centrally.
CrowdSec’s community-driven virtual patching takes a different approach. The vpatch-CVE-2025-55182 rule correlates multiple signals: HTTP POST method, React Server Action headers, tampering with internal Flight parameters, and suspicious $@ payload patterns. The strength is speed, because practitioners encountering novel payloads can contribute signatures rapidly. The weakness is uneven coverage.
Fortinet’s signature-based approach, with IPS rules deployed through FortiGuard outbreak alerts, benefits from enterprise integration but introduces a customer-side deployment gap. Centrally published signatures still require someone to push them to production.
F5 Labs captured the core tension: most exploit attempts are constrained by recognisable behaviours that generic WAF signatures can block, such as prototype pollution keys and references to process.mainModule.require. But legitimate RSC traffic uses the same chunk reference syntax that signatures target, so aggressive Flight protocol inspection risks breaking server-rendered content. WAF operators must balance detection coverage against the risk of blocking valid traffic.
How Should Security Teams Assess the Blast Radius of a React2Shell Compromise?
WAFs are fallible, and the payload diversity from December’s campaigns confirms that some exploits will reach the runtime. When they do, blast radius assessment maps what the compromised process could reach. Organisations that assessed their exposure across four dimensions were able to scope the damage quickly.
Runtime privilege level. The exploit inherits the full privilege set of the compromised Node.js process. Organisations that confirmed whether the process ran as root or a restricted user knew immediately whether filesystem access was unlimited. Containerised deployments add a second boundary, and teams that assessed privileged mode, hostPath mounts, and elevated capabilities understood whether container escape was feasible.
Network egress posture. Security teams that mapped what the compromised process could reach, external IPs enabling reverse shells and credential exfiltration, or egress filtering constraining communication, identified the extent of post-exploitation options. Microsoft’s observation of Cloudflare Tunnel abuse confirmed that attackers actively probe egress boundaries.
Data access scope. As the Cisco Talos documentation of NEXUS Listener confirmed, credential harvesters systematically read every configuration file from working directory to root. Organisations that assumed all environment variables, .env files, mounted secrets, and cloud IMDS credentials had been exfiltrated made better decisions than those that waited for forensic confirmation.
Lateral movement potential. Teams that mapped whether the RSC server shared a network segment with databases, internal APIs, or Kubernetes control planes understood whether harvested SSH keys and cloud IAM tokens enabled further access. These are architectural questions about deployment topology, not post-breach forensics.
What Indicators of Compromise Should Security Teams Hunt for After the React2Shell Disclosure?
The behavioural signatures persist across campaigns because they are tied to how React2Shell exploitation works, even as specific IPs, hashes, and domains age out. Security teams that hunted across four observable dimensions caught compromises that single-dimension searches missed.
Process-level indicators are immediate. Teams that looked for unusual child processes spawned from Node.js, especially sh, bash, curl, and wget originating from the server-rendering process, detected exploitation before persistence was established. Unit 42 documented the value of reviewing all child processes spawned by the node process for suspicious file operations and network connections. XMRig processes were observed masquerading as kernel threads under names like [ksoftirqd].
Network indicators include outbound connections to unknown IPs on non-standard ports, connections to mining pool domains, reverse shell callbacks on ports 12323 and 8899, and traffic to credential exfiltration endpoints. Cloudflare Tunnel endpoints emerged as a common bypass technique.
Filesystem artefacts reveal persistence. Incident responders found that checking for new systemd service files masquerading as legitimate services, crontab @reboot entries, modified shell RC files, and new SSH authorised keys surfaced compromises even when process-level monitoring had been evaded. ZinFoq’s default timestomp timestamp of 2016-01-15 provided a specific forensic marker.
Flight protocol indicators are the hardest to inspect because they require WAF or logging infrastructure that can parse the binary serialisation format. Trend Micro’s pattern table documents Next-Action headers, $@ chunk references, resolved_model strings, and constructor:constructor access chains. Huntress published Sigma rules for detecting suspicious shell processes and YARA rules for ZinFoq, CowTunnel, and PeerBlight. Microsoft Defender triggers on React2Shell-specific alerts. The detection tooling exists.
The platform defence comparison does not declare a winner, because each approach protects against a different part of the threat lifecycle. Vercel’s framework-level patching fixed the root cause. Cloudflare’s V8 isolate sandbox contained the blast radius regardless of patch status. Deno Deploy’s permission model denied post-exploitation capabilities by design. Deployments that combined approaches fared best.
For the architectural analysis behind the headlines, the full crisis overview connects these operational findings to the deeper questions about framework trust and accountability that React2Shell raised. The University of Michigan’s advice now reads as an implicit recognition that architecture was the decisive defensive variable. Patching speed alone could not replicate the structural insulation that Cloudflare’s V8 isolate sandbox and automatic WAF deployment provided.
The question React2Shell leaves behind is whether your platform architecture makes the next RSC deserialisation vulnerability survivable, regardless of how quickly you patched CVE-2025-55182. The blast radius assessment framework and behavioural IoC hunting methodology give you tools that work regardless of what that next vulnerability looks like, because they evaluate exposure at the architectural level, not the CVE level.
Frequently Asked Questions
Is React2Shell only a Next.js problem, or does it affect other React frameworks?
React2Shell targets the React Flight Protocol serialisation format, which is the foundation of React Server Components. Next.js is the most widely deployed RSC framework, so it bore the brunt of exploitation, but any framework that implements React Server Components with the vulnerable react-server-dom-webpack or react-server-dom-turbopack packages is susceptible. The vulnerability lives in React’s core deserialisation logic, not in Next.js specific code. GreyNoise telemetry confirmed exploitation attempts against non-Next.js RSC deployments within the first week of scanning.
Does containerisation protect against React2Shell exploitation?
Containerisation does not prevent the initial exploitation, which occurs at the application layer through deserialisation of a malicious Flight payload. However, containers do constrain the post-exploitation blast radius. A restricted container without privileged mode, hostPath mounts, or elevated capabilities limits what an attacker can access after achieving RCE. The credential harvesting campaigns documented by Cisco Talos were most devastating when the compromised Node.js process ran with broad filesystem access and cloud IMDS reachability, both of which proper container hardening would restrict.
Do I still need to patch if my site is behind Cloudflare?
Yes, patching remains essential even behind Cloudflare. Cloudflare’s WAF Managed Rules block known exploit patterns before they reach the origin server, providing a critical buffer during the exposure window between disclosure and patch deployment. But WAF rules are signature based, and novel bypass payloads that avoid blocked keywords will eventually emerge. Cloudflare’s own documentation notes that binary Flight protocol payloads inherently challenge signature-based detection. Patch your react-server-dom-webpack and react-server-dom-turbopack packages to the versions specified in the May 2026 coordinated advisories.
How can I verify my React or Next.js application has been patched against CVE-2025-55182?
Check the installed version of react-server-dom-webpack or react-server-dom-turbopack in your dependency tree. Use npm ls react-server-dom-webpack or yarn why react-server-dom-webpack to identify all instances, including transitive dependencies. The patched versions were published as part of the 13 coordinated advisories in May 2026. After updating, run the Assetnote react2shell-scanner against your own deployment in a staging environment to confirm the patch is effective, then audit your lockfile to verify no older version has been reintroduced by a subsequent install.
What should I do if I suspect my server has already been compromised via React2Shell?
Isolate the affected host from the network immediately. Preserve forensic evidence by capturing memory dumps and disk images before shutting down. Hunt for the behavioural IoCs documented by security researchers: unusual child processes spawned from Node.js, outbound connections to unknown IPs on non-standard ports, new systemd service files masquerading as legitimate services, and modified shell RC files. Rotate all credentials accessible to the compromised process, including environment variables, .env file secrets, cloud IAM tokens, and SSH keys. Assume complete credential exfiltration until forensic analysis proves otherwise.
Why did the University of Michigan specifically recommend Cloudflare in their advisory?
The University of Michigan security team made an operational risk calculation. Cloudflare was the only provider that had deployed automatic WAF Managed Rules with default Block action across all plan tiers, including Free, within hours of disclosure. Other providers required customer-side configuration changes or offered protection only on enterprise plans. For an organisation managing hundreds of web properties across diverse teams, recommending a single provider that removed the configuration burden was operationally pragmatic. It was not an endorsement of Cloudflare’s technology over alternatives; it was a recognition that automatic protection works at institutional scale.
Are there free tools available to scan for React2Shell vulnerabilities?
Yes, several free scanning options exist. The Assetnote react2shell-scanner is an open-source command-line tool that sends benign Flight protocol probes to identify vulnerable servers without delivering a payload. Nuclei templates are available from the community template repository, enabling integration with existing vulnerability scanning workflows. GreyNoise offers a free React2Shell tag that identifies IPs actively scanning for the vulnerability, which helps defenders distinguish opportunistic background noise from targeted scanning against their infrastructure. Each tool targets a different defensive use case: internal validation, CI/CD integration, and threat intelligence enrichment.
Does React2Shell affect statically generated Next.js sites?
Statically generated Next.js sites that do not use React Server Components at runtime are not directly vulnerable to React2Shell exploitation. The vulnerability requires an active server-side rendering path that deserialises Flight protocol payloads from client requests. A purely static site, served as pre-rendered HTML and JSON files from a CDN, has no server-side RSC deserialisation endpoint for an attacker to target. However, be thorough in your assessment: many Next.js deployments use a hybrid model where most pages are static but specific routes, like search or admin dashboards, invoke server components dynamically.
What makes React2Shell different from other Node.js deserialisation vulnerabilities?
Most Node.js deserialisation vulnerabilities exploit unsafe use of eval, vm.runInNewContext, or serialize-javascript to achieve code execution. React2Shell is different because it attacks the framework’s own serialisation protocol, React Flight, which is designed to be deserialised safely. The vulnerability emerged from Flight’s chunk reference mechanism: $@ and $B prefixes create object references during deserialisation, and attackers discovered that these references could be manipulated to achieve prototype pollution and ultimately arbitrary code execution through the framework’s own internals, not through a misused third party library.
Is it true that simply updating to the latest Next.js version fixes CVE-2025-55182?
Not necessarily just the latest version. The fix for CVE-2025-55182 was backported across multiple release lines as part of the May 2026 coordinated advisories, so the patched version depends on which major release you are running. Simply running npm update next may pull a version without the backport if your project pins a major version range. Consult the specific advisory for your Next.js version line and verify that react-server-dom-webpack or react-server-dom-turbopack in your dependency tree matches the patched release. Blindly updating without checking the dependency tree leaves room for error.
