Recently, a serious cPanel & WHM security issue named CVE-2026-41940 was reported, and many server owners started facing strange problems like unknown cPanel accounts, SSH lockouts, rescue mode, outbound attack traffic, and even broken operating systems. cPanel officially described this issue as an authentication bypass vulnerability affecting cPanel & WHM versions after 11.40, and they released patched versions with required update steps.
In this article, I will explain what this exploit is, what kind of symptoms you may notice on your server, how to check whether your cPanel server is affected, and what immediate steps you should take to secure or recover your server.
This guide is based on real server recovery work where multiple cPanel/WHM servers were affected, some servers were recoverable, and one server became completely unbootable due to GRUB rescue/OS damage.
What is CVE-2026-41940?
CVE-2026-41940 is a security vulnerability related to cPanel & WHM. According to cPanel’s official security update, it is an authentication bypass issue. In simple words, authentication bypass means an attacker may be able to access or abuse parts of the system without logging in through the normal username and password process.
This type of vulnerability is more dangerous than a normal WordPress plugin issue because it is not limited to one website folder. A cPanel/WHM level issue can affect the full hosting environment, including cPanel accounts, WHM functions, server settings, logs, passwords, and sometimes even root-level access depending on the attack path.
cPanel has released patched versions and recommends updating the server immediately using the cPanel update script.
Common Signs of Compromise
If your cPanel server is affected, you may notice one or more of these signs:
- Unknown cPanel accounts created automatically
- Strange email addresses like
a@exploit.local - Fake local domains like
something.cpx.local - Root password suddenly not working
- SSH login denied or changed
- WHM/cPanel not accessible
- Server placed into rescue mode by provider
- Outbound attack traffic alerts from hosting provider
- Websites showing 404 or becoming unavailable
- Server stuck in GRUB rescue mode
- Missing website files or database folders
- Suspicious SSH keys, API tokens, or new users
In our case, one of the strongest indicators was an unknown cPanel account named:
sptadm
The account had a suspicious contact email:
a@exploit.local
And a fake-looking domain:
15d898fc.cpx.local
If you see anything similar, treat your server as compromised.
How to Check Unknown cPanel Accounts
Login to your server through SSH and run:
ls -la /home
Then check cPanel users:
ls -la /var/cpanel/users
Also check domain mappings:
cat /etc/trueuserdomains cat /etc/userdomains
To search for known suspicious patterns:
grep -R "cpx.local\|exploit.local\|sptadm" /var/cpanel/users /etc/trueuserdomains /etc/userdomains /etc/domainusers 2>/dev/null
If this command returns any result, inspect it carefully. If the account is not created by you, suspend or terminate it from WHM after confirming that it is not a legitimate account.
How to Check cPanel Version
Run this command:
/usr/local/cpanel/cpanel -V
Then compare the version with cPanel’s patched versions list. cPanel has listed patched versions for multiple release branches, and all further versions should also include the fix.
How to Update cPanel Immediately
Run:
/scripts/upcp --force
After update, restart cPanel service:
/scripts/restartsrv_cpsrvd
Then verify version again:
/usr/local/cpanel/cpanel -V
If the server is already compromised, updating cPanel is still required, but it may not remove already-created backdoors, unknown users, SSH keys, or malicious files. So after updating, you must still perform security checks.
Check Suspicious Cron Jobs
Cron jobs are often used by attackers for persistence. Run:
grep -R "wget\|curl\|bash\|sh \|python\|perl\|php\|base64\|/tmp\|/dev/shm\|nc " /etc/cron* /var/spool/cron 2>/dev/null | head -150
Normal cPanel, Imunify360, Mailman, and WP Toolkit cron entries may appear. You need to look for unknown commands like:
curl http://unknown-domain wget http://unknown-domain php /tmp/file.php bash -c suspicious-command /dev/shm/randomfile
Check Temporary Folders
Attackers often use /tmp, /var/tmp, and /dev/shm to run files.
find /tmp /var/tmp /dev/shm -type f -perm /111 -exec ls -lah {} \; 2>/dev/null
If you find unknown executable files there, do not immediately delete everything blindly. First inspect the file name, timestamp, and process relation.
Check Hidden Backdoor Files
For cPanel website accounts, run:
find /home/*/public_html -type f \( \ -name ".*.php" -o \ -name "*.phtml" -o \ -name "*.phar" -o \ -name "*.php5" -o \ -name "*.php7" -o \ -name "*.suspected" \ \) -exec ls -lah {} \; 2>/dev/null | head -200
Some .phtml files may be legitimate, especially inside WordPress maintenance or plugin vendor folders. But random hidden PHP files inside uploads, cache, images, or unknown directories are suspicious.
Check SSH Access
Check root SSH keys:
ls -la /root/.ssh cat /root/.ssh/authorized_keys
Check user SSH keys:
find /home -path "*/.ssh/authorized_keys" -type f -exec echo "FILE: {}" \; -exec cat {} \; 2>/dev/null
If you find unknown SSH keys, remove them after confirming.
Also check SSH login attempts:
grep -i "Accepted\|Failed\|Invalid user\|session opened" /var/log/secure* 2>/dev/null | tail -150
Failed login attempts are common on public servers, but unknown successful logins should be investigated immediately.
Block Outbound Telnet and DNS Flood Traffic
In some affected cases, hosting providers detected outbound attack traffic from the server. This means the server was sending suspicious traffic to other IPs.
Two common patterns were:
- TCP SYN traffic to port 23
- UDP DNS traffic to port 53
You can add a temporary emergency outbound block:
cat > /etc/systemd/system/emergency-egress-block.service <<'EOF' [Unit] Description=Emergency outbound attack block After=network-online.target [Service] Type=oneshot ExecStart=/usr/sbin/iptables -I OUTPUT -p tcp --dport 23 -j DROP ExecStart=/usr/sbin/iptables -I OUTPUT -p udp --dport 53 -m limit --limit 30/second --limit-burst 60 -j ACCEPT ExecStart=/usr/sbin/iptables -A OUTPUT -p udp --dport 53 -j DROP RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable --now emergency-egress-block
Check status:
systemctl status emergency-egress-block --no-pager iptables -L OUTPUT -n --line-numbers | head -30
This is an emergency protection step. If your server needs heavy DNS usage, you may need to adjust the DNS rate-limit later.
What is Outbound Attack Traffic?
Outbound attack traffic means traffic going from your server to other external IP addresses.
For example:
Your VPS → random outside IPs on port 23 Your VPS → DNS flood traffic on port 53
This usually means your server is being abused by an attacker or malware to scan, attack, or flood other systems.
What is Port 23?
Port 23 is used by Telnet.
Telnet is an old remote login protocol. It is insecure and rarely used on modern servers. If your server is sending traffic to many random IPs on port 23, it may indicate scanning or botnet-like activity.
What is TCP SYN?
TCP SYN is the first packet used to start a TCP connection. A normal TCP connection starts like this:
SYN SYN-ACK ACK
This is called the TCP three-way handshake.
If a server sends many SYN packets to many outside IPs, it can be part of scanning or attack traffic.
What is Port 53?
Port 53 is used for DNS.
DNS converts domain names into IP addresses. For example:
example.com → 192.0.2.10
Normal DNS traffic is expected on servers. But high-volume UDP traffic to port 53 can look like DNS flood or DNS abuse.
What is DNS UDP?
DNS usually uses UDP port 53 because it is fast and lightweight. But UDP can also be abused for flood attacks because it does not require a full connection like TCP.
So if your provider reports a huge amount of UDP traffic to port 53, it should be investigated immediately.
If Server is in Rescue Mode
If your provider places your VPS in rescue mode, do not reinstall immediately.
First identify partitions:
lsblk
fdisk -l
blkid
Mount the main root partition read-only first:
mkdir -p /mnt/server mount -o ro /dev/sda4 /mnt/server
Then check data:
ls -la /mnt/server ls -la /mnt/server/home ls -la /mnt/server/var/lib/mysql ls -la /mnt/server/var/cpanel/users
If /home, /etc, /var/lib/mysql, and cPanel user data are present, backup first.
If these folders are missing and the disk shows very low usage, then it may not be a simple boot issue. It may indicate data deletion, overwritten disk, wrong disk attachment, or serious storage-level issue.
Backup Before Reinstall
Before reinstalling, always backup:
/home /var/lib/mysql /etc /var/cpanel /usr/local/cpanel /root /backup
If possible, create archive files:
tar -czf /root/home-backup.tar.gz /home tar -czf /root/etc-backup.tar.gz /etc tar -czf /root/var-cpanel-backup.tar.gz /var/cpanel tar -czf /root/mysql-backup.tar.gz /var/lib/mysql
But if disk space is low, download data using SFTP/WinSCP instead.
Important Security Steps After Recovery
After recovering access:
- Change root password.
- Change all cPanel account passwords.
- Enable WHM two-factor authentication.
- Check and delete unknown WHM API tokens.
- Check root SSH keys.
- Check all cPanel accounts.
- Terminate unknown accounts like
sptadm. - Update cPanel immediately.
- Update WordPress, plugins, themes, and WHMCS.
- Install and configure Imunify360.
- Enable cPHulk protection.
- Keep daily off-server backups.
- Restrict SSH and WHM access by IP if possible.
Why Imunify360 Can Help
Imunify360 is not a magic shield, but it can reduce damage by detecting malicious files, suspicious processes, brute-force attempts, web attacks, and abnormal activity.
>>Get Imunify360 License @ $2/month (Unlimited cPanel Accounts)
In some cases, servers with Imunify360 installed were recoverable, while an unprotected server suffered much more severe damage. This does not prove that Imunify360 will stop every exploit, but it can add an important layer of security.
Conclusion
CVE-2026-41940 is not a normal website-level vulnerability. It is a serious cPanel & WHM security issue that can affect the full hosting environment if exploited. The most important action is to update cPanel immediately, check for unknown accounts, rotate passwords, audit SSH/API access, and keep reliable off-server backups.
If your server is already inaccessible or placed into rescue mode, do not reinstall immediately. First mount the disk safely, check whether data exists, take backups, and then decide whether repair or fresh reinstall is the best option.
