Spotting .sorry Ransomware on Your cPanel Hosts

We just shipped automatic detection for the “Sorry” ransomware. Every site audit now flags any file ending in .sorry as hacked, and the File Manager renders a red Ransomware badge next to those files so the encrypted artefacts are obvious next to the more usual PHP backdoors.

The reason it needs its own treatment: this is a host-level ransomware, not a CMS-level one. It does not care whether the site it just encrypted is WordPress, Joomla, Drupal, or a single static index.html. If the cPanel account it lands in can read the file, it gets encrypted and renamed with .sorry on the end. The decryptor is the attacker’s RSA-2048 private key. There is no public alternative.

How Does mySites.guru Spot .sorry Files?

The audit pipeline ends with a post-audit pass that flags files matching known-bad patterns. We added one extra query:

UPDATE bf_files
   SET hacked = 1, suspectcontent = 1
 WHERE filewithpath LIKE '%.sorry'

Every Joomla, WordPress and Generic connector now runs that query after the file inventory is collected. The site flips to “hacked” on your dashboard, the encrypted files show up in the Suspect Content tool, and the File Manager renders a red Ransomware badge next to each row alongside the existing Hacked File badge.

That row in the middle, /yes.sorry, is what an encrypted file looks like through the audit. The badge is intentionally distinct from the standard “Hacked File” label so that a portfolio with hundreds of compromised sites can be sorted by ransomware victims first.

What is CVE-2026-41940?

CVE-2026-41940 is a pre-authentication authentication bypass in cPanel and WHM, scored CVSS 9.8 and disclosed by WebPros on 28 April 2026. The root cause is CRLF injection in the login and session-loading code. An attacker injects raw \r\n characters into the Basic Auth header and a crafted whostmgrsession cookie. The server writes those characters straight into a pre-auth session file, which lets the attacker insert properties like user=root, hasroot=1 and tfa_verified=1 into a session it then accepts as authenticated. The attacker walks into WHM as root with no credentials.

watchTowr Labs published the deepest technical breakdown and Rapid7 followed with the patch matrix and IR notes. The vulnerable surface includes every cPanel and WHM version released after v11.40, plus WP Squared up to 136.1.6.

Help Net Security reports earliest in-the-wild exploitation on 23 February 2026, more than two months before the patch landed. By the time the advisory went out, the bug was already a known zero-day inside the threat-actor community.

What Does Sorry Ransomware Actually Do?

The ransomware itself is a separate piece of malware, dropped by attackers once they have root WHM from CVE-2026-41940. The technical detail comes from BleepingComputer’s coverage and ransomware researcher Rivitna:

• Written in Go, Linux-only.
• ChaCha20 stream cipher per file. The per-file key is then wrapped with an embedded RSA-2048 public key.
• Appends .sorry to every encrypted filename.
• Adds a 2,357-byte RSA-encrypted footer to each encrypted file.
• Drops a README.md ransom note in every directory it touches.
• A single Tox ID for contact, reused across all victims, which makes it easy to correlate samples but useless for negotiating.

Before encrypting, the operators scrape the filesystem for AWS, Stripe, OpenAI and Slack keys, then try to insert a hardcoded MySQL root password and dump every database. So even if you restore from backup, treat every secret the host ever held as compromised.

There is no decryptor. Anyone telling you otherwise is selling a scam.

How Many cPanel Hosts Have Been Hit?

Three numbers worth knowing, three numbers worth ignoring:

Worth knowing:

• Shadowserver has logged 44,000+ compromised cPanel IPs.
• Censys sees 8,859 hosts with publicly exposed .sorry files, of which 7,135 are confirmed running cPanel/WHM.
• Help Net Security reports multiple distinct threat actors exploiting the same CVE, not just the Sorry operator.

Worth ignoring: the “1.5 million servers” figure circulating on social media. That is the total population of internet-exposed cPanel hosts, not the victim count. Picus and others cite it for context, but it does not belong in any operational decision-making.

The first figure is the ground truth for “how many hosts had a root WHM compromise”. The second is the lower bound for “how many of those then got hit with ransomware specifically”. The gap between them is the population that got backdoored, credential-scraped, or used as a launchpad without the loud ransomware payload.

How Do I Audit a Suspect cPanel Host Myself?

If you administer the cPanel host directly, three checks beyond .sorry filenames:

1. Session directory. Look in /var/cpanel/sessions/raw/ for pre-auth session files containing user=root, hasroot=1, tfa_verified=1, or multiple pass= lines. Any of those in a pre-auth file is the smoking gun for CVE-2026-41940 exploitation.
2. Webshells. Public reporting mentions “numerous” persistence webshells but does not catalogue specific paths. Pull the file inventory, sort by mtime since 23 February 2026, and grep for the standard PHP backdoor patterns (eval, assert, base64_decode, dynamic includes from $_POST or $_REQUEST). Our Find Hacks and Backdoors post covers the manual technique.
3. MySQL root. Check mysql.user for unexpected users or unexpected Host entries on the root account. The Sorry operator’s pre-encryption playbook includes a MySQL tampering step.

If you only manage the sites and not the host, the file-level check is the only one you can run yourself. That is the one we automated.

How Do I Recover From a .sorry Ransomware Attack?

The recovery story for ransomware is unavoidably the backup story. There is no clever path here.

1. Do not reuse the compromised host. Move to a clean cPanel install on a patched version (11.110.0.97 / 11.118.0.63 / 11.126.0.54 / 11.132.0.29 / 11.134.0.20 / 11.136.0.5 / WP Squared 136.1.7).
2. Restore site files and the database from your last known-good backup. If you have been using mySites.guru’s one-click backup feature, the most recent pre-encryption backup is the obvious starting point. Verify timestamps before restoring. Restoring a backup taken after the breach reintroduces the backdoors.
3. Rotate every credential the host touched. Database passwords, WP_ADMIN_USERS, FTP, mail accounts, API keys present in wp-config.php or configuration.php, Stripe/PayPal connectors, anything in .env. The Sorry playbook scrapes for these before encrypting.
4. Run a full audit of the restored site before pointing DNS at it. Even a clean backup can carry an older backdoor that the attacker used to gain CMS-level persistence months before the ransomware payload landed. Our How to Fix a Hacked Joomla or WordPress Site walkthrough covers this end-to-end.
5. If you have no clean backup, the practical options are: accept the data loss, rebuild from whatever assets you have elsewhere (git repos, CMS exports stored off-host, customer-side copies of content), or, only if the data is genuinely irreplaceable, engage a professional IR firm to negotiate. fix.mysites.guru is who we recommend when “irreplaceable” is the honest answer.

Why Is .sorry Detection a Default Check?

Most signature-based malware scanners look at file content. A .sorry file’s content is by definition unreadable ciphertext, so there is nothing for a YARA rule or a PHP eval-pattern regex to match on. The filename, on the other hand, is unmissable. There is no legitimate reason for a file under any CMS document root to end in .sorry. A single LIKE '%.sorry' query is faster than scanning content, has zero false positives, and works against future variants that change the encryption algorithm but keep the extension.

That is the same logic behind our existing detection for the 8,192,029-byte hack payload and the dozens of filename patterns we already flag on every audit. Cheap pattern checks at the end of an audit catch things content scanners miss. We added this one, we will add more as new ransomware families emerge with their own signature extensions.

If you already have mySites.guru connected to your sites, you do not need to do anything. The next audit on each site will pick up any .sorry files automatically. If a site flips to “hacked” with a Ransomware badge, you will get the standard hacked-site notification. The detection is retroactive: sites that were already encrypted before today will surface the badge on their next audit pass.

If you do not have mySites.guru connected yet, the free audit will run the same check across any sites you point it at.

Further Reading

• BleepingComputer: “Sorry” ransomware mass exploitation of cPanel, first ransomware-specific reporting, 2 May 2026.
• watchTowr Labs: CVE-2026-41940 root cause, the deepest technical breakdown of the CRLF injection chain.
• Rapid7: CVE-2026-41940 ETR, patch matrix, IR notes, and confirmation of mitigations.
• Censys: The cPanel Situation, independent measurement of exposed .sorry files on the public internet.
• Help Net Security: multiple threat actors exploiting CVE-2026-41940, confirms the ransomware is one of several payloads riding the same bug.