The cPanel Zero-Day Was Active for 64 Days Before Anyone Knew

When hosting providers took cPanel offline on April 28, the working assumption was that the vulnerability had been discovered shortly before the advisory. That assumption was wrong. KnownHost CEO Daniel Pearson has confirmed that his company observed exploitation attempts as early as February 23, 2026, roughly 64 days before any public advisory, patch, or CVE existed. Servers were being compromised while their operators had no reason to look.

This is a follow-up to our April 29 coverage. Since then, the vulnerability has been formally assigned CVE-2026-41940 with a CVSS score of 9.8 CRITICAL, added to CISA’s Known Exploited Vulnerabilities catalog with a federal remediation deadline of May 3, and active ransomware and botnet campaigns have been documented at scale across compromised cPanel infrastructure.

cPanel Had an Authentication Bypass. Exploits Were Already in the Wild.

What the Vulnerability Is and What It Allows

CVE-2026-41940 is classified as CWE-306 (Missing Authentication for Critical Function). The technical mechanism is a CRLF injection flaw in cPanel’s session loading and saving process. An unauthenticated remote attacker can exploit this to manipulate session files and inject root-level privileges, bypassing the login screen entirely on both cPanel and WHM interfaces.

A CVSS score of 9.8 reflects the most severe combination of factors: the attack is remotely exploitable, requires no authentication, requires no user interaction, and results in full compromise of confidentiality, integrity, and availability. In practice, a successful exploit gives an attacker the same administrative access as the server owner, including access to all hosted accounts, domains, databases, email, and configuration files on that server. On a shared hosting server hosting hundreds of customer accounts, full WHM access means full access to every one of those accounts.

The vulnerability affects all cPanel and WHM versions from 11.86.0 through 11.136.0, as well as WP Squared v136.1.7 and earlier. Version 11.86.0 dates back several years, meaning the flaw has existed in the codebase across an extended period of cPanel’s release history. The WP Squared scope is notable for managed WordPress providers: WP Squared is cPanel’s WordPress-focused interface, and its inclusion in the affected range means the exposure extends to providers who deploy cPanel specifically for WordPress hosting workloads.

What hosting providers are saying about cPanel in early 2026

Two Months as a Zero-Day

KnownHost CEO Daniel Pearson has confirmed that his company observed exploitation attempts “as early as 2/23/2026”, approximately 64 days before cPanel’s April 28 public advisory. Pearson urged any operator who had not restricted cPanel access during that window to treat affected systems as potentially compromised and investigate accordingly.

This creates a timeline that does not fully reconcile with other public statements. hosting.com’s April 28 incident communications described the vulnerability as having been “responsibly disclosed to cPanel” before the public advisory, a position shared by multiple providers. Our April 29 article cited an industry source who stated the vulnerability had been reported to cPanel approximately two weeks before the April 28 advisory, and that cPanel’s initial response was that nothing was wrong.

The gap between these accounts is significant. If exploitation began February 23 and the responsible disclosure that cPanel acknowledges came roughly two weeks before April 28, that places the researcher’s private report in mid-April. The most likely reconciliation is that attackers discovered and exploited the vulnerability independently, weeks or months before the researcher who performed the responsible disclosure found it. That is a known pattern with authentication bypass flaws in widely deployed software: the window between criminal exploitation and researcher discovery can be substantial, and there is no guarantee the researcher was first.

What this means in practice: any cPanel server accessible on the internet between February 23 and April 28 without firewall restrictions on cPanel and WHM ports was potentially exposed to active exploitation for up to 64 days with no vendor patch available and no public advisory to prompt investigation. cPanel has not addressed the February exploitation date in any public communication.

The Scale of Exposure

Rapid7’s analysis of internet-exposed cPanel instances using Shodan returned approximately 1.5 million potentially vulnerable deployments. Censys, using its own internet-wide scanning, identified 1,052,657 cPanel and WHM hosts on the internet at the time of writing. The difference between the two figures reflects methodology rather than contradiction: both confirm exposure in the millions. Each of those instances hosts multiple customer accounts, domains, and databases, making the downstream exposure considerably larger than the host count suggests.

The exposure during the pre-disclosure window is particularly difficult to assess because there was no CVE, no public advisory, and no vendor alert in circulation between February 23 and April 28. Standard security monitoring tools and vulnerability scanners had nothing to match against. Providers who were not actively monitoring cPanel and WHM authentication logs for anomalous access during that period have no automated mechanism to determine whether their systems were targeted.

Copy Fail: Any Local User Can Get Root on Nearly Every Linux System Since 2017

Active Exploitation Campaigns

Censys data tracking malicious host activity shows how rapidly the vulnerability was weaponized after public disclosure. On April 30 and May 1, the numbers escalated sharply: on May 1 alone, 15,448 cPanel and WHM hosts were observed participating in malicious activity, representing 79.99 percent of all hosts tracked as malicious by GreyNoise that day. The day prior that figure was 146 hosts. The 100-fold increase in 24 hours reflects automated exploitation at scale following the public availability of exploit details.

Two distinct attack campaigns have been identified. The first deploys “Sorry Ransomware,” a Hidden-Tear-based ransomware variant that renames victim files with a “.sorry” extension and leaves a ransom note referencing the qTox communication tool. Censys identified 7,135 cPanel and WHM hosts showing “.sorry” file extensions at the time of writing, indicating successful ransomware deployment. The file types most frequently renamed include WordPress core files: wp-config.php, wp-cron.php, wp-load.php, and wp-settings.php, which suggests the ransomware is specifically targeting WordPress installations hosted on compromised cPanel servers.

The second campaign deploys a Mirai botnet variant (identified as “nuclear.x86”) via Telnet post-compromise, adding compromised servers to a distributed botnet infrastructure. A community report published on r/cpanel on May 2 illustrates the speed of exploitation: a brand-new dedicated server on HostGator infrastructure with cPanel installed was compromised on April 29 at 22:59, hours after the public advisory, before the customer had added any content. The shell history showed the attacker downloading nuclear.x86 from 87.121.84.78, executing it, and removing the binary to cover tracks. The server logged 2,481 failed login attempts since the last legitimate login. The provider declared the server “dirty,” cancelled the service, and issued a refund.

The broader infrastructure targeting cPanel is not new. The Brutus Botnet, first documented in March 2024, has been targeting cPanel ports 2082 and 2083 as part of a large-scale brute-force and credential-stuffing campaign spanning VPN appliances, RDP, and web applications. In March 2025, EclecticIQ connected Brutus to Black Basta ransomware operations, identifying it as an automated foothold generator for ransomware-as-a-service affiliates. While no explicit connection between Brutus and CVE-2026-41940 has been established, the overlap in attack surface and the presence of an organized ransomware supply chain targeting cPanel infrastructure provides context for how quickly CVE-2026-41940 was weaponized after public disclosure. Community-sourced blocklists of IP addresses observed attempting CVE-2026-41940 exploitation are circulating in hosting operator forums and should be reviewed by any provider running cPanel infrastructure.

Among cloud and hosting providers, Censys identified the highest concentrations of malicious cPanel hosts at the time of writing at: DigitalOcean (1,043 hosts), Contabo (716), OVH (501), Vultr (391), Oracle (321), Unified Layer (280), Hetzner (277), Akamai Linode (275), GoDaddy (209), and Microsoft (169). These figures reflect the distribution of cPanel deployments across provider infrastructure and should not be read as reflecting provider-specific security failures; they correlate with where cPanel is most widely deployed.

Is the hosting industry stuck in the past? The problem of legacy security

What the CISA Listing Means

CISA’s Known Exploited Vulnerabilities catalog is maintained specifically for vulnerabilities with confirmed active exploitation in the wild, not merely theoretical risk. Addition to the catalog is a formal signal that exploitation is real and ongoing. CVE-2026-41940 was added on April 30, two days after the public advisory, with a mandatory remediation deadline of May 3 for all US federal agencies.

For commercial hosting providers, the CISA listing carries two practical implications. First, enterprise and government clients who operate under security frameworks that reference the KEV catalog will now have contractual or compliance reasons to ask their providers about remediation status and about the pre-disclosure exposure window. Second, the listing confirms that the threat is active enough for a government cybersecurity authority to classify it as a priority, which raises the threshold for how providers communicate about the incident to their customers.

Providers who took cPanel offline on April 28 and patched promptly can document a clear remediation timeline. Providers who did not will face harder questions about their response, and about what, if anything, they can determine about the February-April exposure window.

How to Sell Security in Hosting (Without Scaring Your Customers)

What Providers Should Do Now

Patching closes the current exposure, not the historical one. If you have not yet updated to a version beyond the 11.136.0 series, that is the immediate priority. For any server that was internet-accessible between February 23 and April 28 without firewall restrictions on ports 2082, 2083, 2086, 2087, 2095, 2096, 2077, and 2078, treat the system as potentially compromised regardless of current patch status.

If compromise is suspected or confirmed, the recommended approach is not cleanup but migration to a clean installation using pre-breach backups. NocInit, which has published detailed response guidance for CVE-2026-41940, makes the case directly: “Modern post-exploitation toolkits are designed specifically to survive cleanup: rootkits hide in kernel modules, persistence is split across multiple unrelated locations.” A server that has been compromised at the WHM level cannot be assumed clean after a manual audit.

Specific indicators of compromise to check immediately:

• Unexpected session files in /var/cpanel/sessions/raw/
• Unfamiliar login entries in WHM access logs
• Multiple customer websites on the server showing signs of defacement or file modification
• Files with .sorry extensions, particularly WordPress core files

If no active compromise is confirmed but the server was exposed during the February-April window, run a full audit covering: SSH authorized keys in /root/.ssh/authorized_keys; cron entries across /etc/cron.d/, /etc/crontab, and /var/spool/cron/; WHM API tokens for any unrecognized entries; and sudoers files for unauthorized privilege grants. Restricting administrative ports 2082 through 2096 and port 22 from the public internet at the firewall level should be treated as a baseline configuration going forward, not an incident response measure.

This article will be updated when cPanel responds to webhosting.today’s questions about the disclosure timeline.