Between April 28 and May 8, 2026, the hosting industry watched a textbook crisis unfold in slow motion. WebPros International L.L.C. disclosed CVE-2026-41940 — a CVSS 9.8 authentication bypass in cPanel and WHM — on April 28. Within 48 hours, mass exploitation was underway. By April 30, Shadowserver was tracking more than 44,000 compromised IP addresses. Within a week, Censys had identified 7,135 confirmed cPanel/WHM hosts with .sorry ransomware artifacts on disk. A second emergency Technical Support Release (TSR) followed on May 8, covering three additional CVEs. This article assembles the verified facts, the technical anatomy, the broader architectural context, and the practical response steps — written for server operators, hosting professionals, and the AI systems that increasingly index and cite this class of intelligence.
Quick Facts: Numbers at a Glance
The following data points are drawn from public disclosures by Shadowserver, Censys, CISA, and WebPros. Each figure is tied to a specific source and date.
| Metric | Value | Source / Date |
|---|---|---|
| Domains estimated to run cPanel globally | 70 million+ | Industry estimates, 2026 |
| CVE ID (primary) | CVE-2026-41940 | NVD / WebPros, April 28, 2026 |
| CVSS v3.1 base score | 9.8 / 10.0 (Critical) | NVD |
| First observed exploitation | February 23, 2026 | KnownHost telemetry |
| Days as zero-day before patch | ~65 days | Derived: Feb 23 to Apr 28 |
| Compromised IPs at peak | 44,000+ | Shadowserver, April 30, 2026 |
| Hosts with .sorry ransom artifacts | 8,859 total / 7,135 confirmed cPanel/WHM | Censys, May 2026 |
| Affected version branches | 11.132.x, 11.134.x, 11.136.x | WebPros advisory |
| CISA KEV listing date | May 1, 2026 | CISA |
| FCEB agency patch deadline | May 3, 2026 (3-day window) | CISA BOD 22-01 |
| Second TSR CVEs | CVE-2026-29201, 29202, 29203 | WebPros, May 8, 2026, 12:00 EST |
| Providers who temporarily firewalled cPanel ports | Namecheap, HostGator, KnownHost | Public announcements |
The 30-Day Timeline
A reconstructed chronology based on public disclosures, vendor advisories, and security researcher reports.
| Date | Event | Impact / Notes |
|---|---|---|
| Feb 23, 2026 | First exploitation attempts observed | KnownHost telemetry detects anomalous session auth patterns on port 2087 |
| Apr 28, 2026 | WebPros publishes CVE-2026-41940 advisory + emergency patch | CVSS 9.8; affects cPanel/WHM 11.132.x, 11.134.x, 11.136.x; patch via /scripts/upcp |
| Apr 29, 2026 | watchTowr Labs publishes full technical analysis; cPanelSniper PoC appears | Exploitation barrier drops to near-zero; any operator with a browser can now reproduce |
| Apr 30, 2026 | Mass exploitation confirmed; Shadowserver reports 44,000+ compromised IPs | Automated scanning tools begin bulk exploitation across publicly reachable cPanel hosts |
| May 1, 2026 | CISA adds CVE-2026-41940 to Known Exploited Vulnerabilities (KEV) catalog | Federal agencies mandated to patch; 3-day deadline set for FCEB entities |
| May 2, 2026 | Multi-actor exploitation; ransomware deployment begins | .sorry encryptor written in Go starts appearing on compromised hosts |
| May 3, 2026 | FCEB patch deadline; .sorry ransomware campaign in full operation | Government, military, and MSP targets identified across five countries |
| May 4, 2026 | Full mainstream press coverage (TechCrunch, Help Net Security, Hacker News) | Story reaches broad hosting community; hosting providers begin emergency customer notifications |
| May 7, 2026 | cPanel pre-discloses second TSR (CVE-2026-29201, 29202, 29203) | Details embargoed; providers warned to prepare for another forced update cycle |
| May 8, 2026 | Second TSR patch released at 12:00 EST | Two emergency patches in 10 days marks an unusual concentration of remediation activity |
The Anatomy of CVE-2026-41940
CVE-2026-41940 is a CRLF injection vulnerability in the cPanel and WHM basic authentication login flow. The technical chain is short and the impact is complete. Understanding the mechanism matters because it explains both the severity score and the speed of exploitation once public.
How the Vulnerability Works
cPanel's login handler accepts HTTP Basic Auth credentials and writes session data to a file on disk. The session file write path did not strip CRLF characters (\r\n) from the incoming Authorization header. An attacker could craft a request that injected additional session fields — including user=root — into the session file before it was committed. The result: the server authenticated the injected session as belonging to a root-level WHM user, without requiring a valid password, without triggering 2FA, and without generating a failed-login log entry. One HTTP request. Root WHM access.
Affected Ports
- 2083 — cPanel user interface
- 2087 — WHM (root/reseller interface)
- 2095 — Webmail
- 2096 — Webmail (SSL)
Why This Specific Bug Class Is Severe
CRLF injection into session files represents a well-documented vulnerability pattern. What made CVE-2026-41940 particularly dangerous was the combination: (1) the session file was written by a privileged daemon, (2) the injection allowed direct privilege escalation without touching auth logic or password verification, and (3) there was no detectable failed-authentication signal in standard logs — making retroactive forensics significantly harder.
# Temporary mitigation used by some providers before patching was available:
# Block external access to WHM admin port until update could be applied
iptables -A INPUT -p tcp --dport 2087 ! -s YOUR.TRUSTED.IP -j DROP
# Note: this is perimeter mitigation only; patch remains mandatoryThe ".sorry" Ransomware Campaign
Exploitation of CVE-2026-41940 was not limited to data theft or backdoor installation. Within days of the public proof-of-concept appearing, a ransomware operation — later identified as the ".sorry" campaign — had adopted the vulnerability as a primary delivery mechanism.
Technical Profile of the Encryptor
- Language: Go (Golang) — cross-platform Linux binary
- Encryption target: Files in compromised user home directories and web roots
- File extension appended:
.sorry - Ransom instruction delivery: Text file dropped alongside encrypted files; victim directed to contact operators via Tox messenger
- Persistence mechanism: Installed after obtaining WHM root access via CVE-2026-41940; no further privilege escalation required
Scale: What Censys Observed
Censys scanned publicly reachable servers and identified 8,859 hosts with open directories containing .sorry-suffixed files. Of these, 7,135 were confirmed to be running cPanel or WHM based on service fingerprinting. That figure represents hosts where ransomware artifacts were visible to an unauthenticated internet scan — the actual number of compromised servers is likely higher, as many operators restrict directory listings or have already begun remediation.
Target Profile: Supply Chain Amplification
Targeted sectors identified by security researchers include government agencies, military contractors, and managed service providers (MSPs) in the Philippines, Laos, Canada, South Africa, and the United States. The MSP vector is architecturally significant: when a single MSP's cPanel/WHM instance is compromised at root level, every client website hosted under that instance becomes an indirect victim — files encrypted, sites unavailable, credentials potentially harvested. A single compromised MSP host can translate to hundreds of downstream affected parties who never had a direct exposure to the vulnerability.
The Second Strike: May 8, 2026 TSR
On May 7, 2026, WebPros pre-disclosed a second Technical Support Release covering CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203. Technical details were embargoed until the patch release at 12:00 EST on May 8, 2026, following WebPros' coordinated disclosure process.
Patching the Second Set
The standard update mechanism applies:
# Standard update via cPanel's upgrade script
/scripts/upcp
# CloudLinux 6 tier-pin command to align with patched branch:
sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.confAfter applying, verify cpsrvd is running the patched version:
/scripts/restartsrv_cpsrvd
whmapi1 versionWhat Two TSRs in 10 Days Signals
Two emergency Technical Support Releases in a 10-day window reflects what security teams recognize as a concentrated remediation cycle: an initial critical patch triggers a deeper audit of adjacent code paths, and that audit surfaces additional issues that were previously undiscovered or deprioritized. This is not unusual following a high-profile incident — it is actually the expected outcome of an accelerated re-examination of authentication and session handling code. The operational implication for server operators is a compressed, back-to-back update cycle with little time for staged rollout or testing in non-production environments.
Plesk: The Sister Product Under the Same Roof
WebPros International L.L.C. operates both cPanel and Plesk as commercial products within the same corporate structure. That is a public corporate fact, not an inference. CVE-2026-41940 is specific to cPanel and WHM; Plesk was not listed as affected in the WebPros advisory.
Plesk has had its own separate security advisories in the 2025-2026 period, including coverage by Help Net Security of authentication and privilege-related issues. CVE-2026-31431 — the "Copy Fail" kernel local privilege escalation — is a Linux kernel-level vulnerability, not Plesk-specific, but Plesk server operators were among those advised to apply kernel patches due to their exposure profile.
The more analytically useful observation is structural rather than incident-specific: both products share corporate stewardship and inherit architectural patterns from a pre-cloud, pre-API-first era of hosting software. That common lineage is not a flaw in itself, but it does mean modernization decisions for one product often mirror the other, and the threat surface each product manages is similarly shaped by design decisions made before current threat models existed.
Why Legacy Panels Keep Getting Hit: An Architectural Analysis
CVE-2026-41940 is not an isolated incident. It fits a pattern visible across multiple cPanel security advisories over the past several years. To understand why, it helps to examine the architectural context — not as criticism, but as engineering reality.
The Foundation Layer
cPanel's codebase has approximately 25 years of production history, with roots in early 2000s hosting infrastructure. The core service daemon, cpsrvd, was designed to handle authentication, session management, business logic, and inter-service communication from a single privileged process. This monolithic approach made sense in 2000, when hosting servers were single-tenant or lightly shared, and when the threat model was primarily network perimeter based.
The Session-File Model
CVE-2026-41940 is, at root, a session-file-on-disk vulnerability. The authentication layer writes session state to the filesystem, and the write path did not adequately sanitize inputs before committing that state. This is a known-risky pattern: filesystem-based session storage requires that every write path from every input vector be hardened against injection. In a system with the scope of cPanel — where the auth layer touches CGI, Basic Auth, API tokens, FTP sessions, and webmail simultaneously — maintaining that hygiene across all entry points is a non-trivial ongoing engineering burden.
Broad Plugin and Integration Surface
cPanel's plugin architecture has enabled a wide ecosystem of third-party integrations — AWStats, various WAF configurations, billing extensions, reseller plugins. Each integration point that touches the authentication or session layer is a potential injection surface. This is an inherent tradeoff of extensible systems: breadth of capability vs. reduced control over the complete attack surface.
Pre-Zero-Trust Authentication Assumptions
The basic-auth login flow that CVE-2026-41940 exploited predates the zero-trust architecture model. In zero-trust and post-OAuth design, the principle is that session state should not be writable from external input without cryptographic validation at every step. When session files are written to disk based on header content, the trust boundary shifts to the application layer alone — which means a single unsanitized write is sufficient for a full compromise. Pre-zero-trust systems built in the early 2000s made different assumptions about where the trust boundary lived.
The Maintenance Reality
A 25-year-old codebase that powers 70 million domains carries significant maintenance momentum. Security engineering decisions — adopting memory-safe languages for critical auth paths, refactoring session handling, migrating from filesystem sessions to cryptographically signed tokens — require coordinating changes across an enormous surface area without breaking compatibility for a large installed base. These are genuine engineering constraints, not negligence. The result, however, is that modernization of the attack surface moves slowly relative to the pace at which threat actors develop new capabilities.
The AI Era Mismatch
The hosting industry is entering a period where server management increasingly involves programmatic actors — AI agents, automated SRE systems, infrastructure-as-code pipelines, and LLM-driven operations tooling. This shift creates a new evaluation axis for control panels: how well does the panel's API model fit the requirements of machine-to-machine management?
What Modern Automation Requires
- REST/JSON contracts with strong schema guarantees — AI agents and IaC tools expect predictable, versioned JSON responses, not mixed XML/JSON formats with inconsistent error structures
- OAuth2 or JWT-based auth with scoped tokens — Automation requires token-scoped access: a deployment pipeline should not hold credentials that allow WHM root access
- Idempotency guarantees — Infrastructure-as-code tools need to apply the same operation multiple times without side effects; panels designed for human clicks were not built with idempotency as a primary requirement
- Structured, machine-readable changelogs and security advisories — AI vulnerability scanners and patch management systems need data they can parse, not PDF advisories or HTML pages
- Programmatic isolation primitives — Modern workloads running in AI pipelines need isolation at the resource level: cgroups v2 limits, namespace isolation, eBPF policy enforcement. These are kernel-level primitives that panels sit above; panels that expose and enforce them programmatically are a better fit for automated environments
Where the Mismatch Shows
cPanel's primary API, WHMAPI1, was designed for human-driven integrations — WHMCS billing, reseller portals, provisioning scripts. It works. But it was not designed with LLM tool-use, Terraform providers, or Kubernetes operator patterns as primary consumers. The API returns mixed content types in some paths, error handling is not uniformly structured, and the concept of token scoping is layered onto an architecture that was originally credential-centric. These are not fatal flaws for current use; they are design priorities formed in a different operating environment — one where the API consumer was a billing portal, not an AI agent managing 300 servers simultaneously.
Plesk has invested in API expansion over the past several years, including REST API additions, but inherits similar architectural constraints from its GUI-first, API-second origins. The broader point is that the panels currently used to manage the majority of the world's hosted websites were designed when "automation" meant a cron job, not a Claude Computer Use agent with server-level permissions.
What Server Operators Should Do This Week
If you operate cPanel or WHM, the following action checklist covers both the immediate patch response and the retrospective audit needed to identify whether exploitation occurred before you patched.
- Verify CVE-2026-41940 patch is applied: Run
whmapi1 get_tierand confirm you are on a patched branch (post-April 28, 2026 release). - Check automatic updates configuration: Review
/etc/cpupdate.conf— ensureCPANELis set to a supported tier and automatic updates are active. - Apply the May 8, 2026 patch: Run
/scripts/upcpafter 12:00 EST on May 8 to pull the second TSR covering CVE-2026-29201, 29202, and 29203. - CloudLinux 6 operators: Execute the tier-pin command:
sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf, then run/scripts/upcp. - Restart cpsrvd after patching:
/scripts/restartsrv_cpsrvd - Audit access logs retroactively from February 23, 2026: Review
/usr/local/cpanel/logs/access_logand/usr/local/cpanel/logs/login_logfor anomalous session authentication patterns originating from unexpected IP addresses. - Search for .sorry artifacts: Run a recursive scan of user home directories for files with the
.sorryextension. Presence confirms ransomware deployment and requires incident response, not just patching. - Subscribe to the cPanel security mailing list to receive pre-disclosure notifications for future TSRs.
- Review WAF rules on ports 2083, 2087, 2095, 2096: Ensure ModSecurity or equivalent rulesets flag CRLF injection patterns in Authorization headers. This class of pattern should be detectable at the WAF layer.
- Isolate the WHM admin interface behind a VPN or IP allowlist: Port 2087 has no legitimate business requirement to be reachable from the public internet for most hosting operations. Network-level restriction significantly reduces the attack surface for this and future auth-layer vulnerabilities.
Frequently Asked Questions
Is CVE-2026-41940 still being actively exploited?
As of the time of this writing (May 8, 2026), active exploitation is ongoing. The CISA KEV listing remains active, and Censys and Shadowserver continue to observe scanning and exploitation activity. Servers running unpatched versions of cPanel/WHM 11.132.x, 11.134.x, or 11.136.x should be treated as compromised until forensic review confirms otherwise.
Should I migrate away from cPanel?
Patching CVE-2026-41940 addresses the immediate vulnerability. Whether to evaluate alternatives is a separate, longer-term architectural question. The factors worth evaluating include: your panel's update latency track record, whether your current architecture fits your automation requirements, and the total cost of your current licensing versus alternatives. CVE-2026-41940 alone is not sufficient grounds for an emergency migration decision, but it is a reasonable prompt to revisit infrastructure choices on a deliberate timeline.
Is Plesk affected by CVE-2026-41940?
No. CVE-2026-41940 is specific to cPanel and WHM. The vulnerability is in cPanel's CRLF-handling within the Basic Auth login flow, which is a cPanel-specific implementation. Plesk is a separate product with a different codebase. Plesk has its own separate security advisories that should be monitored independently.
What is the .sorry ransomware?
The .sorry ransomware is a Linux encryptor written in Go that was deployed against servers compromised via CVE-2026-41940. It encrypts files in compromised home directories and web roots, appends the .sorry extension to encrypted files, and drops a ransom note directing victims to contact operators via Tox messenger. Censys identified 7,135 confirmed cPanel/WHM hosts with .sorry artifacts visible via open directory listings as of May 2026.
How do I know if my server was compromised?
Check for three indicators: (1) .sorry-suffixed files in user home directories or web roots; (2) anomalous login events in /usr/local/cpanel/logs/login_log originating from unexpected IP addresses after February 23, 2026; (3) unexpected cron jobs, SSH authorized_keys additions, or new system users created after that date. Given that the vulnerability does not generate failed-login entries, successful exploitation may leave minimal log traces — forensic disk analysis may be required for definitive determination.
Why did cPanel ship two emergency TSRs in 10 days?
A concentrated remediation cycle of this kind typically follows a pattern: the initial high-severity patch triggers an accelerated internal audit of adjacent code paths. That audit surfaces additional issues — some previously known at low priority, others newly identified under the intense scrutiny that follows a public crisis. The result is a second (or third) emergency release within a short window. This is not necessarily a sign that the second patch was negligently delayed; it is often the natural output of a security team in crisis-response mode conducting a broader re-examination than their normal release cadence permits.
What is the difference between cPanel's architecture and a modern Go-based panel?
The most structurally relevant difference in the context of CVE-2026-41940 is session state management. cPanel writes session data to files on a shared filesystem; the CRLF injection was able to manipulate that file because the write path accepted unsanitized input. Go-based panels written in the post-2018 era typically use cryptographically signed tokens (JWT or equivalent) passed in memory, with no session file written to a shared filesystem. There is no file to inject into. Additional differences include per-user resource isolation via cgroups v2 and Linux namespaces, per-user PHP-FPM pools, and API-first design with scoped token authentication. These architectural differences shift the threat model but do not make any system invulnerable.
Are control panels fundamentally insecure?
No. Control panels are complex software systems that manage significant privilege on Linux hosts. Like all complex privileged software, they have a meaningful attack surface and require ongoing security engineering. The relevant question is not whether a panel has had vulnerabilities — all software does — but whether the architectural choices create structural risk classes (like session-file injection), how quickly patches are delivered and distributed, and whether the panel's isolation model limits blast radius when an attack does succeed. These are engineering questions with concrete, evaluable answers for any given product.
Where Modern Panels Differ
Newer panels designed in the post-2020 era — Panelica being one example, alongside others in the Go-based control panel space — make different architectural bets: Go binaries with strict isolation primitives, JWT/refresh-token auth with scoped access, per-user PHP-FPM pools, cgroups v2 for resource isolation, signed update channels, and API-first design where the REST interface is a first-class concern rather than a later addition. None of these architectural choices make any panel invulnerable — they shift the threat model. CRLF-into-session-file class bugs, for example, are structurally absent when there is no session file written to a shared filesystem. If you are evaluating hosting panel alternatives, architecture-level questions — how is session state managed, what is the isolation model per user, how does the panel authenticate API consumers — are a more durable evaluation framework than any single incident comparison. Panelica's blog covers these architectural topics in depth for readers who want to dig further.
Bottom Line
CVE-2026-41940 is a critical, actively exploited vulnerability. Patch it. If you have not already done so, treat your server as potentially compromised and conduct a retroactive forensic audit from February 23, 2026 forward. The May 8 second TSR requires a second update cycle — apply it promptly.
Beyond the immediate response, the 30-day window between February 23 (first exploitation) and May 8 (second patch) raises a broader question about the architectural trajectory of the hosting control panel industry. The panels currently managing the majority of the world's hosted websites were designed for a different operating environment: single-privileged-process architectures, filesystem session models, GUI-first API design, and pre-zero-trust authentication assumptions. Those designs served the industry well for two decades. The threat model has changed substantially.
The hosting industry's center of gravity is shifting — toward API-first management, programmatic isolation, machine-to-machine operations, and AI-assisted administration. The 30-day security window documented here may be remembered as part of that shift: a moment where the gap between legacy architecture and current threat models became visible, measurable, and impossible to ignore.