Exploit- cPanel & WHM Auth Bypass CVE-2026-41940 · Sorry Ransomware.

The defect lives in cPanel and WHM's Basic-auth handler and the session writer that backs it. cPanel's own NVD entry confirms the affected version range begins after 11.40 and persists through the patched releases issued in late April 2026. Hosting platforms running cPanel/WHM as their administrative back-end are squarely in scope; only customers of cPanel-on-cPanel (the company's own SaaS) are insulated.

cPanel's Basic-auth handler does not strip Carriage Return / Line Feed characters from the value supplied in the Authorization request header. Because the header value is later written into a session file, an attacker can inject arbitrary header keys and values — effectively forging fields the application will treat as legitimate session metadata.

cPanel normally encrypts a segment of the whostmgrsession cookie before writing session data to disk. The encryption is gated on the cookie containing all expected segments. By omitting one of those segments, the attacker steers the code into a branch that skips encryption entirely — meaning the CRLF-injected raw value lands on disk verbatim.

The session loader trusts session timestamps as a sign of legitimacy. If a timestamp field is present in the loaded session — exactly the kind of field the CRLF injection allows the attacker to plant — the password validation branch is skipped and AUTH_OK is returned unconditionally. With AUTH_OK, the request is treated as a privileged WHM administrator and full WHM API access is granted.

Shodan scans cited by Picus and others put the internet-exposed cPanel/WHM population at roughly 1.5 million hosts. By April 30, 2026 — one day after public disclosure — at least 44,000 IP addresses were observed scanning honeypots and brute-forcing exploitation against cPanel-style endpoints. Censys observed 8,859 hosts already exposing files with a .sorry extension, of which 7,135 were running cPanel or WHM.

Fig. 2 — Exposure vs. exploitation footprint, late April–early May 2026.

The most prevalent payload observed post-exploit is a Go-based Linux encryptor that appends .sorry to encrypted files and drops a ransom note instructing victims to negotiate via Tox. The Go runtime makes static binaries that drop cleanly onto a wide range of Linux distributions, which suits a campaign opportunistically targeting unrelated cPanel hosts.

Censys also documented Mirai-family botnet variants being deployed onto compromised hosts, plus a third bucket of intrusions where attackers simply wipe entire websites and their backups. The wipe behaviour is consistent with hacktivist or destructive actors riding the same exploit; the payload diversity confirms the bug is being weaponised by multiple unrelated crews simultaneously.

The strongest pre-exploit signal sits in raw web-server logs (Apache or Nginx fronting cPanel). Look for unusual byte sequences in the Authorization header and unexpected shapes of the whostmgrsession cookie. The two patterns below are tuned tight — false-positive rate should be near zero on a normal cPanel host.

For environments shipping web logs into Sentinel, the same logic translates directly into KQL. Adjust the table reference to match your ingestion (CommonSecurityLog, W3CIISLog, Custom CEF parser, etc.).

• 1Patch immediately. cPanel released fixed builds in late April 2026 covering the supported TIERs. Subscribe to cPanel's security feed and apply the latest 11.126.x / 11.128.x / 11.130.x update for your release channel.
• 2Compromise-assess every cPanel host with internet exposure since February 2026. In-the-wild exploitation predates the patch by approximately two months — patching alone does not invalidate prior intrusion.
• 3Inventory and rotate credentials for any account stored in or accessible via WHM (database creds, API tokens, billing-system links, FTP accounts, mail accounts).
• 4Audit WHM custom hooks, package post-install scripts, and PHP-FPM configurations for newly added entries since February — these are the legitimate WHM features attackers turn into root persistence.
• 5Restrict WHM access to a management VPN or IP allowlist where possible. There is no business case for unauthenticated WHM access from the public internet.
• 6Hunt for .sorry filenames across hosted customer directories — Censys's footprint suggests many Sorry victims are still unaware.