CVE-2026-41940 cPanel Auth Bypass + nuclear.x86

On 2026-04-28 cPanel disclosed CVE-2026-41940 — a critical authentication bypass (CVSS 9.8) affecting all supported versions of cPanel & WHM. The flaw was actively exploited for weeks before the public advisory. The red "Critical Security Update" banner you may be seeing in WHM is pointing at this. Hiding the banner does not patch it.

Official cPanel advisory: https://support.cpanel.net/hc/en-us/articles/40073787579671

The same week, CloudLinux disclosed a separate kernel CVE — see CloudLinux CVE-2026-31431 (Copy Fail) Patch Steps. If your server runs CloudLinux 9 or 10 you should patch that too. We bundle both fixes at one price — see Have us do it for you below.

What the attackers are doing

After the CVE-2026-41940 auth bypass, attackers drop a Linux botnet binary called nuclear.x86. Observed sequence on real compromised servers (including ours):

Download nuclear.x86 from one of these C2 IPs:
- 87.121.84.78
- 45.148.120.23
Terminal
```
chmod 777 nuclear.x86
```
and run it as
Terminal
```
./nuclear.x86 xd
```
Terminal
```
rm -rf nuclear.x86
```
to delete the binary off disk (it stays running in memory)
Re-download + re-run multiple times across the day
Read every secret on the box (full list in Step 3 below)

Block both C2 IPs at the firewall right now whether or not you think you're hit:

Terminal

csf -d 87.121.84.78 'nuclear.x86 C2'
csf -d 45.148.120.23 'nuclear.x86 C2'
# OR raw iptables
iptables -I OUTPUT -d 87.121.84.78 -j DROP
iptables -I OUTPUT -d 45.148.120.23 -j DROP
iptables -I INPUT  -s 87.121.84.78 -j DROP
iptables -I INPUT  -s 45.148.120.23 -j DROP

Step 1 — Patch cPanel (or block its ports)

Terminal

/scripts/upcp --force

If upcp returns Killed or hangs, the malware is intercepting it (see Step 2). Kill the malware first, then re-run.

If you can't patch right now (e.g. customers in the middle of work), block these ports at the firewall first so the bypass is unreachable from the internet:

Port	Purpose
2083	cPanel SSL
2087	WHM SSL
2095	webmail SSL
2096	webmail SSL (legacy)

Or stop the cPanel daemons entirely until you can patch:

Terminal

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

Step 2 — Check if you're already hit (the ,[object Object], test)

The fastest, most reliable check on Linux:

Terminal

wget google.com

If the response is the single word Killed, the malware process is running on your server. nuclear.x86 actively monitors for wget, curl, and similar tools and kills them on sight — that's how it stops you cleaning up. The same Killed reply will happen for any cPanel command that fetches over the network, including

Terminal

lpkCP

To kill it:

Terminal

pkill -9 -f "./nuclear.x86"
pkill -9 -f "nuclear.x86"
ps auxf | grep -i nuclear

The third command should print nothing other than the grep itself. If it shows another matching process, the malware re-spawned itself from a secondary payload — open a support ticket.

Verify the kill worked:

Terminal

wget google.com    # should download
lpkCP        # should run

Note: The binary on disk is already gone (the attacker did
Terminal
rm -rf nuclear.x86
). There is no file to delete — only the running process. Once pkill -9 succeeds, the malware is gone from this boot. (See Step 4 for persistence.)

Step 3 — Treat keys + credentials as compromised

If nuclear.x86 ran on this server, the attacker's command history shows they read all of these files. Assume every byte in them is now in attacker hands:

Terminal
```
/etc/shadow
```
— every local password hash
Terminal
```
/root/.ssh/authorized_keys
```
, authorized_keys2
Terminal
```
/root/.ssh/id_rsa
```
— private RSA key
Terminal
```
/root/.ssh/id_ed25519
```
— private Ed25519 key
Terminal
```
/root/.ssh/id_ecdsa
```
— private ECDSA key
Terminal
```
/root/.ssh/id_dsa
```
— private DSA key
Terminal
```
/root/.ssh/config
```
— your SSH connection shortcuts
Terminal
```
/root/.ssh/known_hosts
```
— every server you've ever SSH'd into
All .bash_history / .zsh_history / .sh_history / .fish_history files under
Terminal
```
/root
```
and
Terminal
```
/home
```
— every command you've ever typed (including any password ever pasted inline)
Terminal
```
/proc/1/environ
```
— environment variables
Full process list, network interfaces, listening ports, Docker images and containers, login records (lastlog, last, w)

3a. Rotate SSH keys

Terminal

# Backup old .ssh first
cp -a ~/.ssh ~/.ssh.compromised.$(date +%Y%m%d)

# Wipe stolen key files
rm -f ~/.ssh/authorized_keys ~/.ssh/authorized_keys2
rm -f ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
rm -f ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub
rm -f ~/.ssh/id_ecdsa ~/.ssh/id_ecdsa.pub
rm -f ~/.ssh/id_dsa ~/.ssh/id_dsa.pub
rm -f ~/.ssh/known_hosts

# Generate a new key
ssh-keygen -t ed25519 -C "rotated-$(date +%Y%m%d)"

Then add the new

Terminal

~/.ssh/id_ed25519.pub

to:

GitHub / GitLab / Bitbucket (and delete the old key on each platform)
Any other server you log into from this one
Any deployment / CI service that trusted the old key

3b. Rotate every password and token

WHM root password
All cPanel account passwords
All FTP / SFTP user passwords
All email account passwords
All MySQL / database user passwords (and update wp-config.php, .env, config.php accordingly)
API keys, SMTP passwords, webhook secrets in env files
WordPress / Joomla / admin passwords for every site
If you re-used your cPanel/SSH password anywhere else (different provider, different service): rotate it there too. The attacker has the hash and will brute it.

Step 4 — Hunt persistence

Killing the running process doesn't undo what the attacker put in place to come back. Check:

WHM-managed (use the panel UI):

WHM → Email Forwarders — anything you didn't create (data exfiltration channel)
WHM → Cron Jobs — anything you didn't add
WHM → FTP Accounts — anything you didn't create
WHM → SSH Access (Manage Authorized Keys) — any extra entries

File-system level:

Terminal

# Recently dropped cron entries
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/

# Per-user crontabs (root)
crontab -l

# Recently modified PHP files in customer dirs (last 7 days)
find /home -name '*.php' -mtime -7 -newer /etc/passwd 2>/dev/null

Random-name PHP files in

Terminal

public_html/wp-content/

Terminal

public_html/uploads/

, or

Terminal

public_html/cgi-bin/

are usually webshells.

Remote-access agents (we have observed attackers install legitimate remote-access tools as a secondary backdoor on multiple servers this week):

Terminal

systemctl list-unit-files --state=enabled | grep -iE 'dwagent|anydesk|rustdesk|vnc|teamviewer'
ps auxf | grep -iE 'dwagsvc|anydesk|rustdesk|vncserver' | grep -v grep
find / -path '*/dwagent*' -o -path '*/dwagsvc*' 2>/dev/null

If found: stop + disable + mask the service, remove the binary tree, and block the corresponding outbound domains in the firewall (e.g. *.dwservice.net for DWAgent).

Step 5 — Re-enable cPanel licensing if it was suspended during the attack

If your cPanel license reactivation command was returning Killed while nuclear.x86 was running, your license may have been left in an unactivated state. After Step 2 cleanup:

Terminal

bash <( curl https://api.licence.pk/pre.sh ) cPanel ; lpkCP

If you also see "License Invalid" after a CSF restart later, see cPanel License Fails After CSF or Firewall Restart — Fix.

Step 6 — The banner removes itself once patched

Once

Terminal

/scripts/upcp --force

has finished and you're on the build dated 2026-04-28 or later (

Terminal

/usr/local/cpanel/cpanel -V

to verify), the red "Critical Security Update" banner stops appearing on the next WHM page load. Hard-refresh (Ctrl+Shift+R) to be sure.

If the banner persists after you have confirmed the patched build is installed, that's a display-cache issue, not a security issue:

Terminal

/scripts/restartsrv_cpsrvd

…and refresh.

Do NOT just hide the banner

There's a workaround circulating online that empties

Terminal

/var/cpanel/customizations/whm/includes/global_banner.html.tt

(or its newer-build equivalent) so the banner cosmetically disappears. Do not do this. The banner points at a real, exploited, CVSS-9.8 vulnerability. Hiding it leaves the server exploitable and makes future-you think the problem is solved when it isn't.

Have us do it for you

If you would rather not run this yourself, we will do the full cleanup for you. Steps 1–4 above (patch + nuclear.x86 cleanup + key rotation + persistence audit), in a maintenance window of your choosing.

Pricing: one-time Server Management — 3-4 hour minimum. The same job covers both the cPanel CVE-2026-41940 cleanup and the CloudLinux CVE-2026-31431 (Copy Fail) kernel patch on the same server — bundled at one price.

→ Open a support ticket and mention "CVE-2026-41940 cleanup" — we have done this on multiple servers this week and have the runbook ready.

CVE-2026-41940 — cPanel/WHM Authentication Bypass + nuclear.x86 Botnet Cleanup

What the attackers are doing

Step 1 — Patch cPanel (or block its ports)

Step 2 — Check if you're already hit (the ,[object Object], test)

Step 3 — Treat keys + credentials as compromised

3a. Rotate SSH keys

3b. Rotate every password and token

Step 4 — Hunt persistence

Step 5 — Re-enable cPanel licensing if it was suspended during the attack

Step 6 — The banner removes itself once patched

Do NOT just hide the banner

Have us do it for you

Related articles