Incident Response · Last verified 2026-05-17

Hacked cPanel Server: Recovery Playbook (2026 Edition)

So your cPanel server got popped. Strange files everywhere, an admin account you don't recognize, customers calling, maybe ransom notes in their home directories. The next couple hours matter way more than the next month. Here's the order I work through with clients, written for the CVE-2026-41940 wave that has dominated incident calls since late February.

Read this first, then act

Most operators I talk to destroy half the evidence in the first thirty minutes. They reboot. They re-image. They yank the box offline and start deleting "suspicious" files while the attacker is still parked inside. All three habits make recovery harder, slower, and more expensive than it needs to be.

The order that actually works is boring: contain, preserve, hunt, eradicate, restore, harden. Skipping any of those steps usually means doing the work twice. If you're not sure your server is even compromised, run the CVE-2026-41940 self-check first. From here on I'm assuming you've already found something concrete: a .sorry file, an unfamiliar Filemanager binary, an admin account named something like cpanelsupport, or unexplained outbound traffic to wrned[.]com or wpsock[.]com.

Step 1 — Contain. First fifteen minutes.

Your job in the first fifteen minutes is not to kick the attacker out. It's to wall them off so they can't do more damage and can't pivot somewhere else. Cleanup comes later.

Get into your hosting provider's control panel and lock down ports 22, 2082, 2083, 2086, and 2087 to your own IP at the cloud firewall level. Don't bother with iptables or csf on the server itself. If the attacker has root (which is the assumption with CVE-2026-41940), they've probably already edited those rules. Provider-level firewall sits above the box and they can't touch it.

While you're there, check whether you have any other servers using the same root password, the same SSH key, or the same WHM API token. If yes, those boxes get the same firewall treatment until you can confirm they're clean. Lateral movement off a popped cPanel box to a database server or a backup server is the difference between an incident and a disaster.

If this is shared hosting, send your customers a short factual notice. "We detected a security incident on the server. We're investigating. Sites may be down for a few hours." That email saves you from the much worse conversation in three days when they find out from somewhere else. Silence in hour one is what kills hosting providers.

Last thing: stop new outbound. If the attacker is exfiltrating data or running a cryptominer (very common with this wave), every minute is bandwidth, CPU, and abuse complaints from your provider. Restrict egress to known-good destinations until you've worked out what's running.

Step 2 — Preserve evidence. Next thirty minutes.

Before you change anything else on the box, capture its current state. You'll want this for forensics, for any insurance or police report, and most importantly so you can prove later that your cleanup actually worked.

Take a full disk snapshot through your provider. Every major cloud has a one-click snapshot. If you're on dedicated hardware, image the disk to a separate drive with dd or your provider's rescue mode. Label it with the date and "pre-cleanup".

Then capture the volatile state before anything reboots. Run these and save the output to one timestamped file: 

ps auxf
ss -tlnp
netstat -anp
lsof -i
last -n 50
w
crontab -l -u root
ls -la /tmp /var/tmp /dev/shm
iptables -L -n -v

Don't reboot. A lot of backdoors live partly in memory and reboots wipe them along with the evidence you'd use to prove they were ever there. Capture process lists, open network connections, cron entries, and suspicious binaries before changing system state.

Hash any binary that looks suspicious before you touch it. sha256sum on /usr/sbin/sshd, /usr/bin/find, /usr/bin/ls, /usr/local/cpanel/cpanel, and anything else you don't recognize. Compare against the package manager: rpm -V coreutils on the RHEL family, debsums coreutils on Debian. Mismatch means tampering.

Pull the auth, web, and cPanel logs off the box to your laptop. Attackers routinely truncate or rotate these. Get them off-system now: /var/log/secure, /var/log/auth.log, /usr/local/cpanel/logs/access_log, /usr/local/cpanel/logs/error_log, and the Apache logs.

Step 3 — Hunt the indicators. Next hour.

Now you're looking for proof of how deep this goes. Every attacker leaves traces. The CVE-2026-41940 crew has been remarkably consistent, which is good news — there's a well-known list to walk through.

Start with the .sorry sweep. Censys identified 8,859 hosts dropping .sorry ransom notes during the active exploitation window, 7,135 of them confirmed cPanel/WHM. Run: 

find / -name "*.sorry" -type f 2>/dev/null
find / -name "READ_ME_TO_RECOVER*" -type f 2>/dev/null

If you find any, you're dealing with the Mr_Rot13 group. The .sorry ransomware explainer covers the full story.

Then check listening ports. The Filemanager backdoor binds a bcrypt-protected web GUI on a configurable port, usually somewhere in the 8000-9999 range. ss -tlnp and look for anything you didn't put there. The Mr_Rot13 Filemanager detection guide has hashes and persistence locations you can match against.

Audit cPanel accounts. whmapi1 listaccts and read every line. Names like admin2, support, cpaneladmin, or anything ending in numbers you didn't create are the usual offenders. They look administrative on purpose so you skim past them.

SSH key audit. find / -name "authorized_keys" 2>/dev/null and read every file. Any key you didn't put there is an attacker key. Take a snapshot before you delete anything.

Cron persistence. The non-root accounts are where the real persistence lives, not in root's crontab: 

for u in $(cut -f1 -d: /etc/passwd); do
  echo "=== $u ==="
  crontab -u "$u" -l 2>/dev/null
done

Anything you didn't author, you treat as hostile.

Recent binary changes: 

find /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -mtime -90 -type f -ls

Anything modified in the last ninety days that wasn't part of your normal patch schedule deserves a closer look.

Step 4 — Eradicate. Don't try to be clever here.

Eradication is the painful step because the only honest answer is almost always: rebuild from scratch. A backdoor by definition is built to survive cleanup. Every hour you spend trying to surgically remove a Go-based backdoor is an hour the attacker is prepping their next move on you.

Stand up a fresh server. New VM, new dedicated box, current OS image (AlmaLinux 9, Ubuntu 24.04 LTS, RHEL 9 — pick your poison). Don't reuse the compromised disk.

Patch fully before exposing it to the internet: 

dnf update -y      # or: apt update && apt upgrade -y

Then install cPanel through the official installer and confirm you're at or above the May 8, 2026 patch level. That covers the original CVE-2026-41940 plus the second emergency TSR (CVE-2026-29201, 29202, 29203). Two emergency TSRs in ten days is not normal for cPanel and you don't want to be on the wrong side of that timeline.

Restore data, but be picky about what comes across. If you have a backup from before 2026-02-23 (when in-the-wild exploitation started), use that. If your earliest backup is more recent, scrub it: keep email, databases, content uploads, customer files; throw out system binaries, cron jobs, SSH keys, authorized_keys, sudoers files, web shells, and any PHP file modified after the suspected compromise date.

Rotate every credential the old server could have read. cPanel passwords. Reseller passwords. Email passwords. Database passwords. API tokens. SSH keys. IPMI/iDRAC/iLO. If a credential touched the compromised box, it leaked. The "but it was hashed" argument doesn't work — most cPanel-stored secrets were readable in plain text by an attacker with root.

Don't forget the integrations. Stripe webhook secrets, AWS access keys, GitHub deploy keys, Cloudflare API tokens, anything that pointed at the old IP can be redirected to attacker infrastructure if you don't rotate. Webhook hijacking is the thing nobody remembers until it bites them.

Step 5 — Restore in stages

With a clean server, patched stack, and rotated credentials, restoring is mostly operational. Two non-obvious things matter:

Bring sites up one at a time, not all at once. If the attacker planted a delayed-execution PHP backdoor in customer data (this happens), you want it firing on the first restored site, not on all 200 simultaneously. Watch traffic for a day, then add the next.

Update DNS only after you've validated the new server. Keep TTL low for the first week. If something goes wrong you can roll back in minutes. If TTL is at 86400 you're committed for a day.

Step 6 — Harden so it doesn't happen again

Treat the breach as the cost of an education. Now make sure that education isn't recurring tuition.

Put cPanel behind a reverse proxy. Cloudflare's free tier with a custom firewall rule restricting /cpanel and /whm to known IPs eliminates the entire pre-auth-exploit class. CVE-2026-41940 wouldn't have touched a server behind that rule.

Enable WHM auto-updates on the daily channel. WHM → Update Preferences → Daily → Automatic. The 28-hour patch window for CVE-2026-41940 would have caught any server on auto-update. The 44,000 compromised IPs were almost entirely on manual or weekly cycles.

Two-factor on every admin account. WHM → Security Center → Two-Factor Authentication. Mandatory for root and reseller accounts. Yes it's annoying. It also reduces many common lateral-movement paths in this attack pattern.

Restrict cPanel network access. WHM → Host Access Control. Allow only your office IPs, your VPN, and any monitoring that genuinely needs in. The attacker class that runs CVE exploits at scale is fundamentally a port-scanning operation. Take ports 2083 and 2087 off the internet for unknown source IPs and you drop off most target lists.

Daily IOC scan. The official cPanel detection script, Lynis, and our own cpanel-cve-41940-detector will catch the well-known indicators in minutes. Free, scriptable, paste into cron and forget about it.

Offsite immutable backups. A backup the attacker can also encrypt isn't a backup. Restic with a B2 or Wasabi append-only bucket gives you 30 days of point-in-time recovery at low cost. Keep at least one backup path outside the server and outside the hosting account.

Subscribe to a CVE feed for your stack. We publish a continuously-updated Active Threat Tracker covering cPanel, WHM, WordPress, NGINX, Apache, Exim, and Dovecot. New advisories surface within minutes of vendor disclosure. Most operators find out about CVEs from Twitter days late.

Frequently asked questions

Should I pay the .sorry ransom?

No. The Mr_Rot13 group's decryption track record is poor and the payment addresses they use have appeared on US Treasury OFAC sanction lists. Paying is bad business and may be illegal depending on your jurisdiction. If your only path back is decryption, talk to a real digital forensics firm before you do anything with the ransom note.

How long does a recovery actually take?

For a single shared-hosting cPanel box with a couple dozen accounts, an experienced operator gets through steps 1 to 5 in 24 hours. Without prior incident response experience, plan on 2 to 3 days, mostly because the IOC hunt and database cleanup take longer when you're learning as you go. Larger fleets or anything involving ransomware encryption of customer data is closer to a week.

Do I have to notify regulators?

Depends on your jurisdiction and what the box held. GDPR (EU/UK), CCPA (California), HIPAA (US healthcare), and PCI DSS (any card data) all have mandatory breach notification windows around 72 hours from discovery. If your server held any of that, lawyer up. If it was a personal blog or a hobby site, almost certainly not.

Can I just reinstall cPanel without rebuilding the OS?

I wouldn't. Reinstalling cPanel doesn't touch kernel-level rootkits, modified system binaries, persistent SSH keys, or cron jobs running as non-root. The Filemanager backdoor specifically lives outside the cPanel directory tree precisely so it survives reinstalls. Full OS rebuild on fresh media is the only response that gives you high confidence afterwards. Anything less and you'll be running this playbook again in a few weeks.

I don't have time for this. What now?

Most reputable hosting providers offer paid incident response. Expect $300 to $2,000 depending on size and complexity. Sucuri and Wordfence Care take cPanel work too. Our own CVE repair service walks the full playbook with you. Whoever you hire, do not skip steps 1 and 2 (containment and snapshot) before help arrives. Those two are time-critical and can't be redone after the fact.

Related guides

References

Wrap-up

A hacked cPanel server is recoverable. The work is mostly about discipline: contain, preserve, hunt, eradicate, restore, harden, in that order. The mistake I see most often is people jumping to "restore" before they've understood how the attacker got in. They restore, get hit again in days, and then it's twice the cleanup with half the trust from their customers. If you'd rather hand this off, our CVE repair service takes the whole playbook off your plate. Whatever you choose: don't pay the ransom, don't reboot before the snapshot, and don't restore without rotating credentials.