CVE-2026-41940 isn't just a cPanel bug. It's a design assumption that shipped for a decade.

Updated May 4, 2026: Added exploitation-scale section covering 44,000+ compromised hosts, Sorry ransomware, Mirai botnet deployment, and state-sponsored targeting of Southeast Asian military entities. IOC and detection guidance expanded.

If you run cPanel and haven’t applied the April 28 update, an unauthenticated attacker can get root on your server in four HTTP requests. No credentials, no user interaction, no way around two-factor authentication. CVSS 9.8.

Patch now: /scripts/upcp --force. If you can’t patch immediately, block inbound traffic to TCP ports 2083, 2087, 2095, and 2096 at the perimeter. Then keep reading, because the patch fixes the bug but not the thing that made the bug possible.

How it works

CVE-2026-41940 is a CRLF injection in cPanel’s cpsrvd daemon. When a login attempt hits the server, cpsrvd writes the password from the HTTP Basic Authorization header into a session file on disk. It writes it verbatim. No sanitization, no filtering.

cPanel’s session files are line-delimited key=value pairs. An attacker who embeds \r\n characters in the Authorization header can inject arbitrary keys into the session file: user=root, hasroot=1, tfa_verified=1. A third request forces the server to re-parse the session file from disk instead of loading the JSON cache, which promotes the injected fields into the live session. A fourth request executes as root.

That’s the whole chain. No memory corruption, no race condition, no exotic prerequisite. A string that wasn’t filtered.

The real story is the design

The press coverage has focused on the exploit chain and the patch timeline. Both matter. But the more interesting detail is in what the patch actually changed.

According to watchTowr Labs’ analysis of the fix, cPanel moved filter_sessiondata calls into the core daemon functions rather than leaving them at the call sites. Before the patch, the architecture relied on every piece of code that touched session files to independently call the sanitization function. The daemon’s core write path didn’t enforce it. Any call site that skipped the filter, or never knew it existed, wrote raw input straight to disk.

This design shipped in every cPanel version after 11.40. That’s roughly a decade of releases where the safety of session handling depended on caller discipline rather than a data-layer invariant.

For operators, this matters beyond the immediate CVE. Caller-enforced sanitization is a class of design decision, not a one-off coding mistake. The question isn’t just “did they fix this bug?” It’s “how many other code paths in the same codebase made the same assumption?” watchTowr raised exactly this point. cPanel hasn’t addressed it publicly. That’s not an accusation. It’s a reason to treat your network controls as the primary defense, not the patch alone.

The disclosure timeline matters

The zero-day exploitation window was roughly two months. KnownHost CEO Daniel Pearson confirmed active exploitation dating back to at least late February 2026, per Bleeping Computer’s reporting. The patch didn’t land until April 28.

Cyber Kendra reported that the vulnerability was submitted to cPanel’s parent company, WebPros, approximately two weeks before the advisory, and that cPanel initially pushed back, claiming nothing was wrong. When the advisory finally shipped, it described the issue as “an issue with session loading and saving.” No mention of unauthenticated root access. No mention of active exploitation.

Multiple major hosting providers (Namecheap, KnownHost, HostPapa, InMotion, hosting.com) implemented emergency port blocks within hours of the advisory. That kind of coordinated response from competitors suggests the industry knew more than the advisory said.

For operators, the takeaway is concrete: your vendor’s disclosure speed is part of your attack surface. Two months of silent exploitation, with no advisory and no guidance, is a long time to be exposed to a pre-auth root bypass on the management interface of your hosting infrastructure.

What happened after the patch dropped

Within 48 hours of disclosure, this went from a zero-day with quiet exploitation to an industry-wide incident with at least three distinct campaigns running simultaneously. The scale and speed confirmed what the design analysis predicted: when your management plane is internet-facing, a single bug becomes everyone’s problem at once.

44,000 compromised hosts in the first week

The Shadowserver Foundation detected 44,000+ unique cPanel IP addresses engaged in scanning and brute-force attacks against its honeypots on April 30, two days after the patch. That number represents confirmed compromised infrastructure being weaponized for further attacks. By May 3, the figure dropped to 3,540, likely reflecting a combination of patching and takedowns.

Separately, Censys identified 8,859 hosts exposing open directories containing files with the .sorry extension. Of those, 7,135 were confirmed running cPanel or WHM. That’s strong evidence of automated mass exploitation. On May 1 alone, approximately 15,302 cPanel systems were newly classified as malicious in Censys data, a 79.99% jump.

CISA added CVE-2026-41940 to the Known Exploited Vulnerabilities catalog on April 30, with a federal remediation deadline of May 21 under Binding Operational Directive 22-01.

Three campaigns, three motives

The post-disclosure exploitation split into at least three parallel operations with different objectives.

“Sorry” ransomware. A Go-based Linux encryptor that appends .sorry to encrypted files, uses ChaCha20 for file encryption with an RSA-2048 public key wrapping the symmetric key, then drops a ransom note directing victims to contact via Tox. Bleeping Computer reported variants demanding 0.1 BTC, and the malware wipes backups before encrypting. Researcher Rivitna confirmed decryption is impossible without the RSA-2048 private key. This is distinct from the 2018 HiddenTear variant that also used .sorry; the new strain is purpose-built for Linux hosting environments.

Mirai botnet variant (nuclear.x86). A separate campaign deploys the nuclear.x86 Mirai variant after gaining access. Post-compromise, these operators create new admin accounts, disable security logging, modify firewall rules for persistence, drop cryptocurrency miners and DDoS bot clients, and harvest credentials from co-hosted accounts. Censys confirmed the Mirai payload (SHA256: 95bcc0a2bb0fff25a2770010406cd0964fd4b3033ed8bae181518f7c8b69d324) was deployed post-compromise rather than integrated into the exploit chain itself.

Targeted espionage in Southeast Asia. On May 2, Ctrl-Alt-Intel identified an exposed attacker staging server revealing a distinct campaign targeting government and military entities. Primary targets included Philippine military domains (*.mil.ph) and Lao government infrastructure (*.gov.la), with secondary targets across MSPs and hosting providers in Canada, South Africa, and the United States. The threat actor used the AdaptixC2 command-and-control framework (C2 callback to delicate-dew.serveftp[.]com:4455), OpenVPN for persistent tunneled access (configured on port 1194/UDP since March 8, 2026), and Ligolo for internal network pivoting. Exposed data on the staging server also revealed a separate custom SQL injection and RCE chain targeting an Indonesian defence-sector training portal, plus evidence of earlier exfiltration of Chinese railway-sector documents. Attack traffic originated from 95.111.250[.]175.

The espionage campaign is particularly notable for its timeline. The OpenVPN configuration on the staging server dates to March 8, seven weeks before the public advisory. This actor was exploiting CVE-2026-41940 during the zero-day window, not just opportunistically scanning after disclosure.

The DigitalOcean and hosting-provider footprint

Censys data shows the compromised infrastructure skews heavily toward commodity hosting. The top affected ASNs: DigitalOcean (1,043 malicious hosts), Contabo (716), OVH (501), Vultr (391), Oracle (321), GoDaddy (209), Microsoft (169). These are the providers where cPanel is most commonly deployed on internet-facing VPS instances without enterprise network controls.

What to do beyond patching

The patch is table stakes. Apply it and move on to the harder work. The post-disclosure campaign data makes several additional actions urgent.

Restrict management port access permanently. Ports 2083, 2087, 2095, and 2096 should be behind IP allowlists, not open to the internet. This isn’t CVE-specific advice. It’s the control that would have contained the blast radius during the two-month zero-day window, and it’s the control that will matter the next time a cPanel bug surfaces. Rapid7 counted approximately 1.5 million internet-facing cPanel instances via Shodan at the time of disclosure. That’s 1.5 million servers where the management plane was reachable by anyone.

Scan for compromise indicators. cPanel released an updated detection script (with false-positive fixes and log correlation) that checks session files in /var/cpanel/sessions for injected keys. Look in /var/cpanel/sessions/raw/ for files where the pass field spans multiple lines, or where token_denied and cp_security_token both appear in the same session file. Check for tfa_verified=1 without a valid origin, and origin_as_string with method=badpass. Check access logs for requests to /scripts2/ paths without a valid cp_security_token prefix. If you find matches, treat it as a confirmed compromise, not a near-miss.

Check for post-exploitation artifacts. Given the three distinct campaigns, scan for: unexpected WHM admin accounts, unauthorized SSH keys, new cron jobs, modified firewall rules, disabled logging, files ending in .sorry, and any binaries matching SHA256 95bcc0a2bb0fff25a2770010406cd0964fd4b3033ed8bae181518f7c8b69d324 (the Mirai nuclear.x86 payload). Check for outbound connections to 95.111.250[.]175 and delicate-dew.serveftp[.]com on ports 4444, 4455, and 1194/UDP.

If you find ransomware artifacts, do not pay. The Sorry ransomware uses RSA-2048 to protect the ChaCha20 file key. Decryption without the attacker’s private key is not feasible. Your recovery path is backups, assuming the attacker didn’t wipe them first (some variants do). If your backups are intact, rebuild. If they’re not, you have a larger problem than this CVE.

Assume the next bug exists. The patch fixed this specific CRLF injection. It didn’t retroactively redesign the session-handling architecture. If the pattern was caller-enforced sanitization across multiple code paths, the structural risk isn’t eliminated by one fix. Your network-layer controls on management interfaces are the defense that works when the application doesn’t.

The concentration problem

cPanel holds the dominant share of the hosting control panel market. A single design assumption in its session writer, one that shipped for a decade, became an industry-wide infrastructure event the moment someone noticed it. The lesson isn’t that cPanel is uniquely bad. Most infrastructure software of that age carries similar debt somewhere. The lesson is that management interfaces exposed to the internet are a bet that every code path between the login form and root has been audited. That’s a bet you will eventually lose.

The post-disclosure data makes that lesson visceral. Three separate threat actors, with three different motives (ransomware, botnet, espionage), all exploiting the same bug within days. The espionage actor was already using it during the zero-day window. The ransomware and botnet operators weaponized it within 48 hours of the PoC going public. Forty-four thousand compromised hosts in the first week. This is what happens when a management plane bug meets internet-facing defaults and market concentration.

Network-layer restrictions on management ports aren’t optional hardening. They’re the control that buys you time when the application fails, when the vendor is slow, and when the next CVE is already being exploited before anyone files an advisory. Port allowlists aren’t exciting. They’re what kept some operators safe for two months while everyone else was exposed.

PatchDay Alert covers CVEs like this one every morning: plain-English summaries, exploit status, and the patch-now-or-Thursday call, delivered before your first ticket of the day.