cPanel Root Escalation Incident Response: Critical First 24 Hours

Patching closes the door. It does not tell you whether anyone walked through it while it was open. Several of the 2026 cPanel vulnerabilities, CVE-2026-41940 above all, were exploited before or within hours of the fix, and the .sorry ransomware campaign that followed hit providers who patched a day late. If a server ran a vulnerable build while reachable from the internet, treat it as potentially compromised and work through the steps below. The order matters: contain first, capture evidence second, rotate third, and decide about rebuilding last.

Short answer: Restrict WHM and SSH to your own addresses, confirm the patched build is installed, and copy volatile state (processes, sockets, cPanel session and access logs) off the server before rebooting anything. Then hunt for .sorry files, unknown SSH keys, API tokens, cron entries and web shells, rotate every password, token and key the server holds, and invalidate all sessions. Rebuild on a fresh server if you find modified binaries, kernel modules or a ransom note; otherwise keep the patched host under heightened monitoring.

Contain without destroying evidence

Restrict access before anything else, but do not reboot or reinstall yet. A reboot loses running processes, in-memory shells and open network connections, which are your best evidence.

csf -a 203.0.113.10 "IR workstation"

Then in WHM » Host Access Control (or directly in /etc/hosts.allow) restrict whostmgrd and sshd to your response addresses only. If the server is actively exfiltrating or encrypting, block outbound traffic except to your own ranges with a temporary CSF rule set rather than pulling the cable; you want to keep your own SSH session.

Make sure the fix is actually installed before you continue, because an attacker can walk back in while you are working:

whmapi1 version
/scripts/upcp --force

Capture what is running

Collect volatile state into a directory off the server (an S3 bucket or a separate host):

mkdir -p /root/ir && cd /root/ir
ps auxwwf > ps.txt
ss -tunap > ss.txt
lsof -nP > lsof.txt
last -aiF > last.txt
cp /var/log/secure /var/log/messages /usr/local/cpanel/logs/access_log /usr/local/cpanel/logs/login_log /usr/local/cpanel/logs/session_log . 2>/dev/null
cp -a /var/cpanel/sessions/raw sessions_raw
crontab -l -u root > root_cron.txt; ls -la /etc/cron.d /var/spool/cron > cron_dirs.txt
find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -newermt "2026-04-20" > new_suid.txt 2>/dev/null
find / -xdev -type f -newermt "2026-04-20" -not -path '/proc/*' -not -path '/home/*' > changed_files.txt 2>/dev/null
tar czf ../ir-$(hostname)-$(date +%F).tgz .

The cPanel access_log and session_log are the ones that show WHM requests, including the malformed Basic Auth requests used against CVE-2026-41940. Search them for requests to /json-api/ or /scripts/ from addresses you do not recognise, and for sessions created for root that you did not open.

Hunt for the .sorry campaign and other persistence

The ransomware left a recognisable footprint, but attackers who did not encrypt still left persistence. Check for all of it:

• Ransom notes: files named with .sorry extensions or README style notes in document roots and /root. find / -xdev -name '*.sorry' 2>/dev/null | head.
• New or modified root SSH keys: cat /root/.ssh/authorized_keys and every /home/*/.ssh/authorized_keys. Anything you did not add is an indicator.
• API tokens: whmapi1 api_token_list for WHM and uapi --user=USER Tokens list_tokens for accounts. Attackers create tokens so they can return after passwords change.
• New accounts and resellers: whmapi1 listaccts | grep -E 'user|owner' compared with your billing system, and cat /var/cpanel/resellers.
• Cron persistence: root and user crontabs, /etc/cron.d, and systemd timers (systemctl list-timers --all).
• Web shells: grep -rlE 'eval\(base64_decode|passthru\(|shell_exec\(' /home/*/public_html --include='*.php' 2>/dev/null | head, and any PHP file in /home/*/public_html/wp-content/uploads.
• Kernel modules and preload: lsmod, cat /etc/ld.so.preload, and rpm -Va --nofiles 2>/dev/null | grep -E '^..5' | grep -E 'bin/|sbin/' for modified binaries.
• Exim: /etc/exim.conf.local and /etc/valiases/* for injected forwarders or filters, since one of the August fixes was an Exim .forward escalation.

A common pitfall is checking only /home. Root escalation means /usr/local/cpanel, /etc and the kernel are all in scope.

Rotate everything

Once the server is patched and evidence is captured, assume every secret on it is known:

passwd root
whmapi1 api_token_revoke token_name=NAME   # for each token, or recreate all
/scripts/mysqlpasswd root "$(openssl rand -base64 24)"
/scripts/resetimappasswd 2>/dev/null

Then, in order: reseller passwords (force reset through WHM » List Accounts » Change Password or whmapi1 passwd), cPanel account passwords with a customer notice, mail account passwords (the bulk method in our Dovecot guide works here), database user passwords, FTP, and any SSH keys. Regenerate DKIM keys if mail was in scope, and rotate credentials for external services the server holds: backup destination keys, remote MySQL, cloud DNS API keys, and the licence account. Invalidate all sessions:

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

Do not skip the backup destination keys. If the attacker has your S3 keys, they have your backups too.

Decide whether to rebuild

Rebuilding is the only way to be certain after root compromise. The practical decision comes down to what you found. If you found a ransom note, modified system binaries, unknown kernel modules or a preload library, rebuild: provision a fresh server on a current build, migrate accounts with the Transfer Tool after scanning each account, and retire the old host. If you found nothing beyond the exposure window itself, and your logs are complete enough to show no successful exploitation, a patched and rotated server is defensible, but keep the evidence archive and increase monitoring on it for the next quarter.

Whichever you choose, restore from backups taken before the exposure window only after checking them; an encrypted server with a backup job that ran afterwards has encrypted backups. Our backup-verify script checks archive integrity, and the offsite retention set up in the S3 backup guide is what makes this recoverable at all.

Verify and keep it running

Close the incident only when whmapi1 version is at or past the builds in the CVE-to-build mapping, every token and key has been rotated, last -a shows only your team, WHM is restricted to known addresses, and the server security audit script comes back clean. Write a short timeline while it is fresh, and if customer data was accessible, follow whatever notification obligations apply to your business. Then fix the thing that caused the exposure: usually WHM open to the world, auto-updates off, or nobody watching the security mailing list. If you would rather have someone on call for the next one, that is what our services cover.

CPanel root escalation incident response at a glance

Official documentation: cPanel & WHM documentation, AlmaLinux wiki, Linux man pages.

Related guides: CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws · CrowdSec vs Imunify360 vs BitNinja: choosing a post-CSF security stack for shared hosting · KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback.

Frequently asked questions