React2Shell RCE: How AI Spots Exploits Fast

Shadowserver reported 165,000+ IPs and 644,000 domains running vulnerable React2Shell-exposed code as of December 8, 2025—with 99,200+ instances in the U.S. alone. Those numbers matter for one reason: when an unauthenticated remote code execution (RCE) bug goes wide, attackers don’t “pick targets.” They industrialize exploitation.

React2Shell (tracked as CVE-2025-55182) is exactly that kind of event. Huntress and others have already observed the vulnerability being used to deploy crypto miners (XMRig) and a mix of new Linux malware—including backdoors, post-exploitation implants, tunneling tools, and DDoS-capable payloads. If you run Next.js/React Server Components in production, this is the sort of week where you find out whether your security program is built for patching… or for surviving active exploitation.

This post is part of our AI in Cybersecurity series, and I’m going to take a firm stance: you should treat React2Shell as a test case for AI-driven detection and response. Not because AI replaces patching (it doesn’t), but because when the exploit window is measured in hours and scanning is automated, you need controls that can recognize malicious behavior even when the payload changes.

What React2Shell exploitation looks like in the real world

React2Shell exploitation is not subtle. The practical pattern is: scan → confirm vuln → execute commands → stage payloads → persist → monetize or pivot. Once an attacker gets RCE on an internet-facing app server, they can run arbitrary commands without credentials. That’s not a “web bug.” That’s an entry point.

Huntress documented exploitation chains that included:

• Dropping a shell script, then pulling XMRig miners
• Deploying Linux backdoors like PeerBlight
• Adding tunneling capability via reverse proxy tooling (CowTunnel)
• Installing post-exploitation implants like ZinFoq

Why the automation detail matters

One of the most telling observations: attackers attempted to deploy Linux-specific payloads on Windows endpoints, which suggests their tooling is automated and not carefully tailored per host.

That’s good news and bad news.

• Bad news: automation means volume. You’ll get hit even if you’re not “interesting.”
• Good news: automation creates repeatable behaviors—exactly what behavioral detection (and AI-based analytics) is strong at spotting.

If your defenses rely heavily on known signatures (hashes, static IOCs), you’ll lose the race as attackers swap payload URLs, rename scripts, and recompile binaries.

The payload mix: miners, backdoors, tunnels, and “long tail” risk

This campaign isn’t only about cryptomining. Crypto miners are the fast-cash option, but the same access is being used to deploy durable intrusion tooling.

Here’s what stood out from the observed payload families and capabilities.

Crypto miner deployment (XMRig) is the canary

XMRig is frequently the first “monetization” payload because it’s straightforward: it burns CPU, costs you money, and often goes unnoticed until performance tanks.

Operationally, miner activity creates distinct signals:

• Sustained high CPU usage
• New processes spawned by app server parents
• Outbound connections to mining pools or proxy infrastructure
• Downloads from code-hosting sites or ephemeral URLs

Miners are often the first symptom, not the whole story.

PeerBlight: persistence + stealthy C2 design

PeerBlight is a Linux backdoor with:

• systemd persistence
• Process masquerading (e.g., appearing like ksoftirqd)
• A hard-coded C2 plus fallback mechanisms using DGA and BitTorrent DHT

Huntress noted the DHT botnet identifier prefix LOLlolLOL and observed 60+ nodes sharing that prefix.

That’s a big clue: attackers are building or reusing an ecosystem where compromised servers can help other compromised servers find control infrastructure. That increases resilience against takedowns.

CowTunnel: outbound tunnels beat inbound firewall assumptions

CowTunnel functions as a reverse proxy that initiates outbound connections to attacker-controlled Fast Reverse Proxy (FRP) servers.

The security lesson is blunt: many organizations over-monitor inbound traffic and under-monitor outbound behavior from servers.

If your “DMZ” host is allowed to initiate outbound connections freely, tunneling tools turn that into a remote access channel—without needing exposed inbound ports.

ZinFoq: post-exploitation framework behavior

ZinFoq (a Go-based Linux implant) includes the features you’d expect from a post-exploitation toolkit:

• Interactive shell
• File operations and exfiltration
• Pivoting features (SOCKS5, port forwarding)
• Timestomping and history clearing
• Disguising itself as legitimate services (dozens of paths)

The take: once React2Shell is exploited, attackers aren’t stopping at “run a command.” They’re setting up operator-grade access.

Why AI-driven cybersecurity matters for React2Shell (and the next one)

Patching is non-negotiable, but it’s not sufficient during mass exploitation. AI-driven cybersecurity earns its keep in the gap between “vulnerability disclosed” and “every instance patched,” and again when attackers keep probing for stragglers for weeks.

A practical way to think about it:

Patching removes the door. AI-based detection catches the intruder who slipped in before you did.

Detection problem #1: payloads change; behaviors don’t

Threat actors can rename sex.sh to anything, move XMRig binaries, and rotate C2 servers. But the behavioral chain often stays consistent:

• Web application process spawns a shell (/bin/bash, sh, cmd.exe, powershell)
• Shell spawns download utilities (curl, wget) or uses scripting runtimes
• New persistence (systemd service creation, cron edits)
• New network egress patterns (unusual destinations, high-frequency beacons)

AI and machine learning models are useful here because they can baseline normal parent-child process trees, typical outbound destinations, and normal execution timing for specific server roles.

Detection problem #2: attackers tunnel around “network visibility”

CowTunnel-style tooling hides behind outbound connections. That pushes defenders toward:

• Egress controls by role (app servers shouldn’t talk to the world)
• Anomaly detection on outbound sessions (rare destinations, unusual ports, persistent connections)
• Correlation across telemetry (process + network + identity + file)

AI-based correlation is where many SOCs actually see relief: instead of chasing 30 alerts, you get one incident story that reads like: “Next.js worker spawned bash, downloaded binary, created systemd service, started long-lived outbound tunnel.”

What “AI detection” should mean operationally (not marketing)

If you’re evaluating AI security tools, here are the concrete capabilities that matter during events like React2Shell:

• Behavioral exploit detection: spotting web-to-shell execution chains
• Automated triage: clustering similar exploitation attempts across hosts
• Real-time containment: isolate host, block egress, kill process tree, quarantine artifacts
• Threat hunting copilots: natural-language investigation over endpoint + network telemetry

My opinion: if your tooling can’t reliably answer “Which servers executed shells spawned by the web worker in the last 72 hours?” you’re going to struggle during mass RCE exploitation.

A practical “patch-now + detect-now” response plan

This is the part teams appreciate during December change-freezes: you need steps that work even when release calendars are tight.

1) Patch what’s vulnerable (no heroics)

The immediate remediation is upgrading components that include vulnerable React Server Components packages (as advised by researchers), especially environments using:

• react-server-dom-webpack
• react-server-dom-parcel
• react-server-dom-turbopack

Also inventory where Next.js is deployed in ways teams forget: preview environments, old staging hosts, agency-managed sites, and “temporary” marketing microsites.

2) Add short-term guardrails while patching rolls out

If you can’t patch everything in hours, reduce blast radius:

• Restrict outbound egress from app servers to required destinations only
• Block outbound traffic to uncommon ports (especially long-lived sessions)
• Tighten execution controls on servers: limit who/what can spawn shells

3) Hunt for the behaviors React2Shell produces

Even without perfect IOCs, you can hunt for high-signal behaviors:

• Web service parent processes spawning shells (/bin/bash, sh, cmd, powershell)
• Sudden use of curl/wget on app servers that don’t normally download binaries
• New systemd services created recently, especially those mimicking kernel/daemon names
• Unexpected long-lived outbound connections from DMZ/app tiers

4) Decide your “crypto miner response” ahead of time

A miner is not a harmless nuisance. Treat it as confirmed compromise.

Minimum response actions:

1. Isolate the host
2. Capture volatile data (process tree, network connections)
3. Remove persistence (systemd service/cron)
4. Rotate secrets that host could access (API keys, tokens, SSH keys)
5. Validate that lateral movement didn’t occur

If you do only step #3, you’re inviting the attacker back in.

Common questions security teams are asking this week

“If we patched, are we safe?”

Patching closes this specific door. But you still need to verify you weren’t hit before patching and that no persistence remains. Assume attackers scanned you the same day everyone else did.

“Are crypto miners the main risk?”

No. Miners are obvious. The bigger risk is backdoors and tunneling that provide durable access, data theft paths, and a platform for follow-on attacks.

“How does AI help if the initial exploit is RCE?”

AI doesn’t prevent exploitation by itself. It helps you detect exploitation quickly, contain faster, and reduce dwell time—especially when payloads and infrastructure keep shifting.

Where this fits in the AI in Cybersecurity story

React2Shell is the kind of incident that makes security leaders reconsider what “good coverage” looks like. Vulnerability management is essential, but modern campaigns move too fast to rely on patch SLAs alone.

AI in cybersecurity is most valuable when it shortens the ugly middle: the hours or days between first exploitation and full remediation. The teams that do well here combine rapid patching, behavior-based detection, and automated response that doesn’t require a human to connect the dots at 3 a.m.

If you’re staring at a fleet of Next.js apps and wondering which ones were probed, the better question is: Do you have enough telemetry and automation to prove it either way—today?