cPanel CVE-2026-41940: 40,000 servers hit by "Sorry" ransomware. The exact patch order to run today.

# cPanel CVE-2026-41940: 40,000 servers hit by "Sorry" ransomware. The exact patch order to run today.

If you administer a cPanel/WHM box and you haven't patched in the last 72 hours, assume you are already compromised and read this post in that order. As of this morning (May 4, 2026) the running tally from SecurityWeek is over 40,000 cPanel servers owned by the campaign now being tracked as "Sorry" — named after the Sorry.txt ransom note the operator drops in every encrypted home directory. BleepingComputer broke the mass-exploitation story Friday. The bug at the center of the storm is CVE-2026-41940, an authentication bypass in the WHM administrative endpoints that hands the attacker root-equivalent control of the entire shared-hosting box.

I run shared-hosting boxes for clients. I have spent the last day rotating WHM root passwords, tearing down reseller accounts, and grepping /var/log on every cPanel machine I touch. This post is what I would hand to a junior on my team if I had to spin one up tonight: what the bug is, exactly which commands to run to figure out if you've been hit, the order to apply the patch and rotate credentials, and what to do if Sorry.txt is already sitting in /home/.

#What "Sorry" actually does on the box

Once the operator has admin access through CVE-2026-41940, the post-exploitation playbook is consistent across every reported victim:

1. Drop a webshell in /usr/local/cpanel/base/3rdparty/ or under one of the customer public_html directories. The shell is small, usually around 4 KB, and obfuscates command output through base64 in cookies.
2. Enumerate every /home// directory and tar them up in batches.
3. Encrypt each user's public_html, mail/, and etc/ (the cPanel-managed mail and DNS configs). Encryption is AES-256-CBC with a per-victim key. The key is exfiltrated to the operator before encryption so victims cannot recover by introspection.
4. Drop a file named Sorry.txt in the root of every encrypted home, containing a ransom note in broken English (the "sorry" theme is the operator's trademark — they apologize, then demand 0.6 BTC per server, with a 72-hour decay clock).
5. Wipe the shell history. Wipe /var/log/messages selectively. Don't touch the cPanel access logs, because by the time you read those the data is already gone.

The box stays online. Email keeps trying to deliver, DNS keeps resolving, but every customer site on the server returns either a 500 or the ransom note as index.html. Hosting providers cannot just rm -rf and restore from backup quickly because the encryption is per-account and the operator has often dropped persistence in /etc/cron.d/ and /etc/rc.d/init.d/ to re-encrypt after restoration.

The operator targets shared-hosting boxes specifically because the per-server payout is much lower than enterprise ransomware (0.6 BTC versus seven figures), but the count is enormous. 40,000 boxes at 0.6 BTC each is ~24,000 BTC of theoretical addressable revenue. Real conversion is much lower — most SMB site owners do not have BTC on hand and hosting providers absorb the loss — but even at 1% conversion you are looking at $20M+ for a campaign that ran on a single CVE for two weeks.

#CVE-2026-41940 — what we actually know

The cPanel security bulletin describing this CVE is, as of writing, sparse. Here is the bullet list cPanel published, plus what can be inferred from the public exploitation traces:

• The vulnerability lives in WHM's administrative API surface — the endpoint set served on TCP/2087 in the default config.
• The bypass involves a malformed authentication header that causes the WHM auth handler to short-circuit to a privileged context. From the on-the-wire signatures published by SecurityWeek's source, the attacker submits a modified Authorization: Basic header where the encoded payload contains an embedded null byte that truncates the username comparison while leaving the privilege-lookup function with a value treated as root.
• Once authenticated as root-equivalent, the attacker can call addhost, createacct, passwd, and the WHM "Modify Account" suite without further checks.
• The vulnerability is reachable from any interface where WHM is listening, which on most stock installs includes the public-facing WAN interface. There is no CSRF prerequisite, no session prerequisite, and no rate limiting on the affected endpoints.

That last point is what makes this campaign so ugly. The attacker does not need a foothold or a phished credential. A single TCP/2087 reachable on the open internet is enough. Shodan currently indexes ~280,000 hosts with WHM in the banner; the 40,000 number is approximately 14% of the addressable pool. Expect the count to keep rising for the next two to three weeks until the long tail of patches roll through. Most managed hosting providers patched within 24 hours of the cPanel advisory. Self-managed VPSes with WHM are the long-tail risk pool, and that is where the 40K is concentrated.

#Detection commands — run these first

Before you patch, know if you've been hit. Patching a compromised box without finding the persistence is an excellent way to be re-encrypted by a cron job ten minutes after you finish the upgrade. Run all of the following as root.

Check your installed cPanel version.

/usr/local/cpanel/cpanel -V

The fixed releases per the cPanel bulletin are 11.118.0.46, 11.116.0.62 (LTS), and 11.114.0.81 (extended LTS). Anything older than these on your major track is vulnerable.

Check for the ransom note.

find /home -maxdepth 3 -name 'Sorry.txt' -ls 2>/dev/null

If this returns rows, you are compromised. Stop here, isolate the box (block the public IP at your hosting provider's firewall, do not just iptables -P INPUT DROP because that won't survive a reboot), and skip to the "If you are already compromised" section.

Check for the dropped webshells in cPanel's third-party directory.

find /usr/local/cpanel/base/3rdparty -type f -newer /var/log/cpanel-install.log -ls 2>/dev/null

The mtime check will surface anything cPanel did not install. Look for any PHP file under that path that is not part of a recognized package (Mailman, RoundCube, Horde, phpMyAdmin). Anything else is suspect.

Grep the cPanel and WHM access logs for the malformed auth signature. The exact byte pattern depends on the variant, but the consistent feature is a Basic authorization where the decoded form has an embedded null. The logs themselves don't decode the auth header, so look at the second-order artifacts — successful WHM API calls from IPs with no prior session:

zgrep -h 'cpsrvd' /usr/local/cpanel/logs/access_log* | \
  awk '{print $1, $7, $9}' | \
  grep -E ' 200 ' | \
  grep -E '/json-api/(addhost|createacct|passwd|modifyacct)' | \
  sort -u

Cross-reference each source IP against your own admin IPs. If you see anything from outside your operations footprint hitting addhost or createacct, the box was abused.

Look for unauthorized cPanel users.

ls -la /var/cpanel/users/ | grep -v '^d' | awk '{print $NF, $6, $7, $8}'

Compare the list of /var/cpanel/users/ files to the actual customer roster you maintain elsewhere. The Sorry operator typically creates one or two new accounts to hold persistence and to launder logs. Any account you don't recognize is suspect.

Look for unauthorized resellers.

cat /var/cpanel/resellers

Every line is username: feature1,feature2,feature3. You should know every line of this file. If you don't, treat the unknown ones as compromised reseller accounts and disable them immediately.

Look for added cron persistence.

for u in $(cut -d: -f1 /etc/passwd); do
  echo "=== $u ==="
  crontab -u "$u" -l 2>/dev/null
done
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /var/spool/cron/

Sorry operators have been observed dropping persistence as both root and the customer cPanel user. Walk every cron schedule on the box, including per-user.

Look for added SUID binaries.

find / -xdev -perm -4000 -type f -newer /var/log/cpanel-install.log 2>/dev/null

Anything that wasn't there a week ago and has the SUID bit on is a candidate persistence binary.

Inspect the WHM API token store.

cat /var/cpanel/authn/api_tokens_v2/whostmgr/root.json 2>/dev/null

If there are token entries you didn't issue, they are operator-issued tokens and you must rotate them all (covered in the next section).

#Patch order — exact sequence

Order matters. If you rotate the WHM root password before you patch, the unpatched binary still has the bypass and the operator (if they're still on the box) gets your new password back through the same vector.

1. Apply the cPanel update first, before touching credentials.

/usr/local/cpanel/scripts/upcp --force

upcp is the cPanel update tool. The --force flag bypasses the daily-rate-limit check and runs the update in the foreground. Watch for errors. Re-run cpanel -V afterwards to confirm you landed on a fixed version.

If upcp won't run because the box is too sick to bootstrap a download, you can pin the LTS series and force the upgrade with:

/usr/local/cpanel/scripts/cpanel_initial_install --force

2. Rotate the WHM root password. Through WHM (now patched), or directly:

passwd root

Use a 30+ character random password from a password manager. Do not reuse. The old password should be considered known to the operator.

3. Rotate every reseller account password. Through WHM, "List Accounts," then for each reseller use "Change Password." Or scripted:

for u in $(grep -v '^root:' /etc/trueuserdomains | cut -d: -f1); do
  newpw=$(openssl rand -base64 24)
  echo "$u: $newpw"
  /scripts/realchpass "$u" "$newpw"
done | tee /root/cpanel-pw-rotation-$(date +%F).log

Read that log carefully. Any user that fails to rotate is either a deleted account that did not get cleaned up (delete it now) or a corrupted entry (investigate before continuing). Save the password log to a secure place — you will need to distribute new passwords to legitimate customers.

4. Audit /etc/cpanel/RPMS/cpanel.config. This file controls a wide range of cPanel security toggles. Walk through each:

grep -E '^(allow_login_autocomplete|disable_cphulk|skipboxtrapper|allow_weakpasswords|usemailformat)' /etc/cpanel/RPMS/cpanel.config 2>/dev/null

If you find anything turned off that should be on (for example, disable_cphulk=1 — that is cPHulk brute-force protection, and it being off is a tell that the operator disabled defenses), turn it back on.

cPHulk specifically should be:

disable_cphulk=0

And while you're in WHM, push cPHulk's brute-force lockout aggression up. The default of 30 failed attempts per 5 minutes is not aggressive enough for a public-facing WHM box.

5. Rotate every API token. WHM's "Manage API Tokens" interface. Or scripted:

ls /var/cpanel/authn/api_tokens_v2/whostmgr/

For every file in that directory:

whmapi1 api_token_revoke token_name="<the_name>"

Then mint new tokens with whmapi1 api_token_create for any automation that legitimately needed the old ones. Update the consuming systems. The same drill applies to per-user cPanel API tokens stored in /var/cpanel/authn/api_tokens_v2/cpanel/.json.

6. Rotate any service that shares credentials with cPanel. MySQL root, PostgreSQL postgres, the Exim DB password, the cPHulk database. Any of these whose creds are stored in cPanel-managed config files should be considered exposed.

7. Restart cpsrvd and whostmgr to ensure new binaries are loaded.

/usr/local/cpanel/scripts/restartsrv_cpsrvd
/usr/local/cpanel/scripts/restartsrv_cphulkd

8. Tighten WHM's external exposure. If you don't need WHM reachable from the public internet, firewall TCP/2087 to your operations IPs only:

iptables -A INPUT -p tcp --dport 2087 -s <your-ops-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 2087 -j DROP

Persist with iptables-save > /etc/sysconfig/iptables (or your distro's mechanism). For real shared-hosting providers who have to expose WHM publicly for self-service, at minimum require IP allowlisting in cPanel's "Host Access Control" panel and turn on cPHulk lockouts at IP-level.

#If you are already compromised

If Sorry.txt exists on the box, the patch flow above is necessary but not sufficient. Compromised boxes need a different runbook.

Step 1. Isolate immediately. Block the box at the upstream — your hosting provider's firewall, your AWS security group, your Hetzner cloud firewall, whatever sits in front of the public IP. Do not rely on host-based iptables alone, because if the operator has root persistence they can flush iptables faster than you can paste the rules.

Step 2. Snapshot the disk before doing anything else. If you are on a hypervisor (VMware, KVM, EC2, Hetzner Cloud, Vultr), take a snapshot of the disk. This is your evidence and your fallback. You will be glad you took it.

Step 3. Pull a memory image if you can. On Linux you can use lime (Linux Memory Extractor) or avml. Memory has the operator's session keys and unencrypted ransom payloads. It is golden for forensics.

Step 4. Decide between recover-and-clean versus reinstall. Recover-and-clean on a cPanel box that has been rooted is possible but risky. The operator has had unlimited time on the box, and there are too many places to hide persistence (init scripts, kernel modules, cron, /etc/profile.d/, hidden alias chains in /root/.bashrc, modified package binaries, tampered pam_unix.so). The honest professional answer for a compromised cPanel server is rebuild from a known-clean OS image and restore customer data from a clean backup. If you don't have clean backups, that is a much larger conversation with your customers.

Step 5. Restore data, not config. When you restore customer home directories, restore the *data* (public_html files, mailboxes, MySQL dumps) but rebuild the *cPanel configuration* (account creation, DNS zones, reseller hierarchy) from your authoritative source. The operator may have planted configuration-level persistence (a malicious .htaccess file in public_html, an SSH key in ~/.ssh/authorized_keys for the customer's shell account) that survives a cPanel rebuild if you blindly tar-restore.

Step 6. Reset every account password and rotate every API token after restoration. Even on a fresh box, treat all customer credentials as compromised. Force-rotate every cPanel password, every email mailbox password, every database password. Notify customers individually with the new credentials through a channel they can verify (do not email the new passwords to email accounts hosted on the same box you just rebuilt).

Step 7. Notify your customers. This is the hard part for hosting providers. Customers running their small business on a shared cPanel box you operate need to know their data was exposed. Some of them have regulatory obligations (HIPAA, PCI, GDPR) that require them to do their own breach notification, and they cannot do that if you do not tell them. The legal exposure of *not* telling customers in a timely fashion is much worse than the reputational exposure of telling them.

#Why the hosting providers are the real victims

Most of the 40K compromised boxes are not run by enterprises. They are SMB shared-hosting boxes operated by GoDaddy, Bluehost, HostGator, NameCheap, A2 Hosting, SiteGround, and the long tail of regional hosting brands. The end customer — the contractor with a five-page WordPress site, the local plumber, the small church, the Etsy seller — has no idea their site is on a cPanel box, no idea what cPanel is, and no ability to patch even if they did. They paid $5/month for "web hosting" and they expect that to be it.

The hosting provider eats the responsibility. The hosting provider also eats the reputational hit when 40,000 of their customers' sites go down for a weekend. And the hosting provider eats the cost of restoring data when the customer's last backup is from "whenever WordPress's automatic plugin did it last, I think."

If you run a hosting business, today is the day to patch every cPanel box in your fleet, rotate every WHM root password, and post a customer notice acknowledging the incident even if you weren't hit. Not posting a notice while every other major hosting brand does is a tell that you weren't paying attention.

If you are an SMB site owner — the customer side of this — and your hosting provider has not sent you a notification email or a status-page update within 48 hours acknowledging this CVE, escalate. Open a ticket. Ask them, in writing, what version of cPanel your server is running and when it was patched. If the answer is unsatisfying, that is a signal to migrate. There are cPanel hosts who patched within 4 hours of the cPanel advisory. There are also hosts who have not yet acknowledged the CVE exists. Vote with your $5/month.

#What to expect over the next two weeks

This is going to keep growing. The patch is out, but the long tail of unpatched WHM boxes on the public internet is enormous. Expect the count to climb past 60K before the curve flattens. Expect a second wave of opportunistic operators picking up the same exploit and running parallel campaigns under different ransom-note branding. Expect at least one major hosting provider to disclose a fleet-wide compromise within ten days; the only question is which one moves first. Expect class actions in any jurisdiction with strong consumer-data law (California, New York, EU member states) within sixty days.

Patch. Rotate. Audit. If you got hit, rebuild and tell your customers.

#How Valtik helps

We do incident response on shared-hosting compromises, including the post-mortem forensics and the customer-notification flow. We also do proactive cPanel/WHM hardening engagements — the version of this runbook applied to your fleet *before* the next CVE drops, plus continuous monitoring on the WHM API for the brute-force and bypass signatures we've cataloged from this campaign. If you run a hosting business and the 40K number this week made your stomach drop, that is the right instinct. Reach out at contact@valtikstudios.com or request a free external check of any single cPanel box you suspect.