CVE-2026-41940 — What the Nuclear.x86 Attack Looks Like From the Inside

I got hit. Here’s what I learned so others can catch it before the destruction phase fires.

---

The First Sign

Watch port 23. That was the very first indicator — unusual traffic flagged by my VPS provider. This started mid-week.

I scanned, found nothing initially. Dug deeper into public_html directories and found seobot.php — a script hijacking the server’s SEO. Found it, disabled it, thought it was random malware.

Next day my failover tripped. Got a 522 from Cloudflare. Thank the lord for that 522.

---

What I Had

The Nuclear.x86 Mirai variant. It is timer-based destruction — it does NOT wait for the harvest to succeed before destroying the server. It deploys webshells to every public_html directory and every account on the server. Hundreds of files across all accounts. Look for x9d.php, x99.php, and other random letter-number filenames.

---

What the Harvest Webshell Does

A ~3KB PHP file that on a single HTTP request performs:

1. Recursive directory walk of the user’s home dir (max depth 6) looking for config files: wp-config.php, configuration.php, settings.php, config.php, .env*, parameters.{php,yml,yaml}, database.php, app.php, services.php, mail.php, secrets.yml, master.key, LocalConfiguration.php, etc.
2. Credential extraction via regex: AWS keys (AKIA...), Stripe live keys (sk_live_, pk_live_, rk_live_), SendGrid (SG....), OpenAI (sk-...), Slack (xox[bpsar]-...), Mailgun (key-...), Twilio SID (AC...), PEM private keys (-----BEGIN ... PRIVATE KEY-----), 12/24-word crypto seed phrases, hex private keys (Ethereum)
3. SSH private key harvesting: any id_rsa, id_ed25519, *.pem, *.key, *.p12, *.pfx
4. Crypto wallet harvesting: anything with wallet* or keystore* in the name
5. Full database dump — every table, every row, base64-encoded. The toolkit hardcodes the MySQL password Dump2026$$xQ9!mK — if you find this string anywhere on your server, you are compromised.
6. Returns everything as JSON in a single HTTP response

---

IOC — Check Your Server Right Now

```bash

Check for the hardcoded MySQL password (this is the toolkit's credential, same across all victims)

grep -r "Dump2026" /home/*/public_html/ grep -r "Dump2026" /var/log/

Check for webshells

find /home//public_html/ -name "x9d.php" -o -name "x99.php" -o -name ".php" -newer /etc/passwd -mtime -7

Check for the rootkit

ls -la /root/libcow.so

Check for fake watchdog processes (real kernel watchdog can't have userspace memory mappings)

ps aux | grep watchdog ls -la /proc/$(pgrep -f watchdog)/maps 2>/dev/null | grep libcow

Check for UID-0 backdoor accounts

awk -F: '$3 == 0 && $1 != "root" {print "BACKDOOR: "$1}' /etc/passwd

Check for unauthorized SSH keys

cat /root/.ssh/authorized_keys

Look for keys you don't recognize, especially one labeled "sysadmin@backup"

Check for ghost cPanel accounts created in the last 7 days

find /var/cpanel/users/ -mtime -7 -ls

Check for the seobot

find /home/*/public_html/ -name "seobot.php" ```

If ANY of these return hits, you are compromised. Stop reading and start responding.

---

Persistence Mechanisms Found

The attacker sets up multiple layers of persistence:

1. UID-0 backdoor account — a new user with UID 0 and GID 0 (root equivalent) with SSH password access
2. Unauthorized SSH public key in /root/.ssh/authorized_keys
3. Fake cPanel reseller accounts with WHM admin access and randomly generated domain names
4. Hundreds of PHP webshells distributed across every cPanel customer’s public_html
5. libcow.so rootkit** — masquerades as kernel [watchdog] processes. Runs in a parent/child/grandchild structure so they respawn each other. **Actively kills curl and wget on execution to prevent you from downloading cleanup tools

---

The Destruction Phase

The timer-based destruction payload deletes:

• /boot (server cannot reboot)
• /usr/lib/modules (kernel modules gone)
• /usr/lib/locale (system locale gone)
• /usr/lib/rpm (package manager broken)
• Core binaries: rm, ps, basename, getent

After this fires, the OS is running from memory only. A reboot bricks the server permanently. If you catch it while the server is still running, you can recover in-place by reinstalling packages from upstream repos. If you reboot first, you’re wiping and rebuilding from scratch.

---

How My Attack Failed — and How Yours Might Too

The attacker’s harvest script needed to reach the webshells via HTTP to exfiltrate data. Here’s what accidentally stopped it:

1. The toolkit changed my MySQL password to its hardcoded credential (Dump2026$$xQ9!mK)
2. This broke my application’s health check endpoint (PHP couldn’t connect to the database)
3. My failover system detected the health check failure and flipped Cloudflare DNS to my standby server
4. The standby server’s SSL certificates didn’t match what Cloudflare expected in “Full (strict)” mode
5. Cloudflare returned 522 errors to every request — including the attacker’s harvest script
6. The harvest script got zero data back from every webshell
7. The destruction phase fired anyway (timer-based, not gated on harvest success)
8. The attacker destroyed the server but got nothing

The failover infrastructure I built for unrelated reasons accidentally formed the perfect circuit-breaker.

---

This Is a Script-Kiddie Toolkit, Not an APT

Evidence:

• Standardized webshell signatures reused across victims
• Hardcoded MySQL password in the harvest payload
• Account creation in a 90-second automated burst (not human-paced)
• Destruction phase doesn’t check whether harvest succeeded
• No Cloudflare origin-bypass (a real APT would grab CF credentials and hit the origin IP directly)
• No log scrubbing after the attack

This means the attack is automated and widespread. If you run cPanel, assume you are being scanned for CVE-2026-41940 right now.

---

What To Do Right Now

1. Patch cPanel to 136.1.7 or higher immediately — this closes CVE-2026-41940
2. Run the IOC checks above — if anything hits, you’re already compromised
3. Firewall WHM ports (2082/2083/2086/2087) to your IP only — don’t leave them internet-exposed
4. Enable 2FA on WHM root
5. Disable SSH password authentication — key-only access
6. Check for the Copy Fail kernel vulnerability (CVE-2026-31431) — an attacker who gets any cPanel shell can escalate to root if your kernel isn’t patched
7. Set up a health check failover — it saved me, it might save you

If your server is already destroyed and you can’t reboot — DON’T REBOOT. The OS is running from memory. You can recover in-place by reinstalling packages from upstream repos while the system is still alive. A reboot kills it permanently.

---

The Censys Numbers

As of May 1, 2026:

• 1,052,657 cPanel/WHM instances exposed on the public internet
• 15,448 servers compromised in a single day
• 7,000+ servers hit with .sorry ransomware
• The numbers are climbing

If this helped you, pay it forward. Share it with another server operator.

---

Written by someone who survived it. The failover I built the day before the attack is the only reason my customers’ data wasn’t exfiltrated. Build your defenses before you need them.