React2Shell Exploits Fuel Massive NGINX Traffic Hijacking

Attackers are chaining the React2Shell vulnerability with NGINX configuration injection to hijack legitimate web traffic at scale. Datadog Security Labs disclosed findings today showing 1,083 unique source IPs conducted CVE-2025-55182 exploitation between January 26 and February 2, targeting web servers running Baota management panels and NGINX across Asia.

When we first covered React2Shell in December, ransomware groups were using it as an initial access vector. This new campaign represents a different playbook entirely—instead of encrypting data, these attackers are silently redirecting visitor traffic through their own infrastructure.

How the Traffic Hijacking Works

After gaining access through CVE-2025-55182 (CVSS 10.0), attackers deploy shell scripts that modify NGINX server configurations. They inject location directives with proxy_pass parameters that reroute incoming web requests to attacker-controlled backend servers. Visitors hit what looks like a normal website, but their traffic passes through a malicious intermediary first.

The attack toolkit includes five distinct shell scripts, each handling a different piece of the operation:

• zx.sh orchestrates the overall attack, using curl, wget, or raw TCP connections depending on what's available on the target
• bt.sh specifically targets Baota (BT) management panels, a popular server administration tool widely used in China and across Asia
• 4zdh.sh enumerates common NGINX configuration file paths to find the right injection points
• zdh.sh focuses on Linux and containerized deployments, specifically hunting for sites using .in and .id top-level domains
• ok.sh generates reports of active hijacking rules already in place, letting operators track their footprint

The geographic targeting is deliberate. The campaign focuses on Asian TLDs (.in, .id, .pe, .bd, .th), Chinese hosting infrastructure running Baota Panel, and government and educational domains (.edu, .gov). Two IP addresses alone—193.142.147.209 and 87.121.84.24—accounted for 56% of observed exploitation attempts.

Two Groups, Two Goals

GreyNoise threat intelligence data reveals two distinct threat actor clusters working the same vulnerability but with different end goals.

The first group retrieves and deploys cryptomining binaries on compromised servers. This is the more straightforward monetization path—hijack server resources, mine cryptocurrency, repeat. The second group establishes direct reverse shell connections back to scanner IP addresses, suggesting hands-on-keyboard access for more targeted operations.

Both groups benefit from the traffic hijacking infrastructure. Redirecting web traffic through attacker-controlled proxies opens up possibilities beyond cryptomining: credential interception, ad injection, SEO manipulation, and phishing distribution through legitimate-looking domains.

A Vulnerability That Won't Go Away

CVE-2025-55182 was first disclosed in late 2025 and has a CVSS score of 10.0—unauthenticated remote code execution. Despite available patches, the Rondodox botnet campaign we covered in January found approximately 90,000 servers still exposed. The vulnerability continues attracting new exploitation campaigns because the patch rate remains low and the attack surface is enormous.

The shift from ransomware to traffic hijacking also makes detection harder. Ransomware is loud—victims notice encrypted files. Traffic hijacking is silent. A compromised NGINX server still serves content normally. Visitors don't see anything wrong. The malicious proxy layer operates invisibly unless someone inspects the NGINX configuration files directly.

Detection and Response

For organizations running NGINX, especially those using Baota panels or hosting sites on Asian TLDs:

1. Inspect NGINX configs manually — Look for unfamiliar proxy_pass directives in location blocks you didn't create, particularly those pointing to external IP addresses
2. Monitor for configuration changes — Set up file integrity monitoring on /etc/nginx/, /www/server/nginx/conf/, and other NGINX config paths
3. Patch React Server Components — If you're running Next.js or React applications with server-side rendering, update to patched versions immediately
4. Block known attacker IPs — Add 193.142.147.209 and 87.121.84.24 to blocklists
5. Check for unauthorized scripts — Search for zx.sh, bt.sh, 4zdh.sh, zdh.sh, and ok.sh in /tmp and other writable directories

The broader lesson: a single critical vulnerability can spawn entirely different attack campaigns months apart. React2Shell went from ransomware tool to traffic hijacking infrastructure in roughly six weeks. Patching remains the only reliable defense.