# cPanel Root Escalation Incident Response: Critical First 24 Hours

Source: https://srvscripts.com/guides/cpanel-root-escalation-incident-response/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

In short: 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.

**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](/guides/dovecot-2-4-mail-login-failed-cpanel/) 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](/guides/whm-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](/scripts/backup-verify/) checks archive integrity, and the offsite retention set up in the [S3 backup guide](/guides/whm-backups-s3-test-restore/) 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](/guides/cpanel-cve-build-numbers-2026/), 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](/scripts/server-security-audit/) 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](/services/) cover.

## CPanel root escalation incident response at a glance

**Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [AlmaLinux wiki](https://wiki.almalinux.org/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws](https://srvscripts.com/guides/csf-cve-2026-65638-patch/) · [CrowdSec vs Imunify360 vs BitNinja: choosing a post-CSF security stack for shared hosting](https://srvscripts.com/guides/crowdsec-vs-imunify360-vs-bitninja/) · [KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback](https://srvscripts.com/guides/kernelcare-setup-cpanel-directadmin/).

## Frequently asked questions

### How do I know if my cPanel server was actually exploited through CVE-2026-41940?

Search `/usr/local/cpanel/logs/access_log` and `session_log` for WHM requests from unknown addresses, root sessions you did not open, and new API tokens in `whmapi1 api_token_list`. Unknown SSH keys, cron entries or `.sorry` files are confirmation; a clean log set covering the whole exposure window is the only evidence of the opposite.

### Is patching enough after a root escalation vulnerability, or do I need to rebuild?

Patching only closes the entry point. If you find any sign of persistence, especially modified system binaries, kernel modules or a preload library, rebuild on a fresh server and migrate scanned accounts; if the logs are complete and show no exploitation, a patched and fully rotated server is defensible.

### What credentials need rotating after a cPanel root compromise?

Everything the server holds: root, reseller and cPanel account passwords, mail and database passwords, WHM and account API tokens, SSH keys, DKIM keys, and any external secrets stored on the box such as backup destination keys, remote MySQL credentials and DNS provider API keys.