Vulnerabilities

cPanel & WHM Auth-Bypass Zero-Day (CVE-2026-41940) Was Exploited for Months

A critical cPanel/WHM authentication bypass — CVE-2026-41940 — let attackers reach hosting control panels with no credentials, and was exploited as a zero-day for months before April's emergency patch. What to patch, lock down, and hunt for.

Nicholas Robert

Nicholas Robert

— 4 min read
Share
Cracked server control panel with broken login lock and data leaking outward, symbolizing critical cPanel authentication bypass and unauthorized administrative access.

For at least two months before anyone outside a handful of attackers knew, the login screen guarding millions of web servers could be walked straight through. On April 28, cPanel shipped an emergency patch for a critical authentication bypass in cPanel and WebHost Manager (WHM) — now tracked as CVE-2026-41940 — that let an unauthenticated attacker reach the control panel with no valid credentials. It was already being exploited as a zero-day. And because WHM sits at the root of a hosting server, a single bypass does not compromise one site; it can reach every site, mailbox, and database on the box.

A Login You Could Walk Through

cPanel deliberately withheld the technical details to slow copycats, but the shape is clear from provider advisories: the flaw lived in the authentication layer shared by cPanel and WHM, so an attacker could reach an interface without ever passing the login. Namecheap described it as an authentication exploit that could allow unauthorized access to the control panel; hosting provider KnownHost called it a zero-day authentication and privilege-escalation bug affecting almost all known cPanel versions, both end-of-life and supported.

What sharpened the alarm was the timeline. The first read on this was that exploitation preceded the patch by hours. The fuller picture is worse: SecurityWeek and CyberInsider report the bug was exploited as a zero-day for months — with activity traced to around February 2026 — before the April disclosure, and Picus estimated the flaw put on the order of 1.5 million servers at risk. Treat the exact figure as an estimate, but the direction is not in doubt: a long, quiet window against an enormous install base.

●  ONE BYPASS, THE WHOLE SERVER
WHM sits at the root of a hosting box, so skipping its login reaches everything on it.
AUTH BYPASS → WHM ROOT
No valid credentials needed. WHM holds root-level control of the entire hosting stack.
↓
EVERY ACCOUNT, SITE, EMAIL & DATABASE
Create or delete accounts, deploy malware or ransomware, exfiltrate customer databases, redirect traffic.
THE SERVER AS INFRASTRUCTURE
Persistent backdoors, spam relays, proxying, botnet use — and hundreds of downstream sites on shared hosting.
EOL VERSIONS — SAME FLAW, NO PATCH
End-of-life cPanel is vulnerable and will not be fixed. A full upgrade is the only remediation.
Source: cPanel advisory; BleepingComputer; provider notices. CVE-2026-41940.

The Response Worth Copying

The hosting industry's reaction is the part enterprise security teams should study. Within hours of the advisory, Namecheap, KnownHost, InMotion Hosting, hosting.com, and HostPapa blocked cPanel-related ports at the network level as a stopgap while the fix propagated. cPanel shipped patched builds roughly two to three hours after going public, and major providers reached full deployment in six to seven hours. That speed was not luck — it came from pre-staged firewall rules, emergency-patch runbooks, and clear escalation paths. Most organizations have no equivalent for their own critical software, and this incident is a clean argument for building one.

The EOL Trap

There is a catch no patch solves. End-of-life cPanel versions carry the same vulnerability and will not receive a fix. cPanel's advisory urges anyone on an unsupported version to update immediately because they too are affected — but for those environments the only real remediation is a full platform upgrade, not a patch. Running EOL cPanel after this is not deferred maintenance; it is operating a server with a known, unfixable authentication bypass.

My Read

The uncomfortable lesson is about leverage, not cPanel specifically. Hosting control panels almost never appear in threat-intelligence briefings, yet they are among the highest-leverage targets on the internet: one authentication bypass against a shared-hosting WHM can cascade into hundreds or thousands of downstream site compromises whose owners have no visibility into the server layer at all. A months-long zero-day window against roughly 1.5 million of those servers is exactly the kind of quiet, high-yield access that gets resold or held for later. If you host on cPanel — directly or through a provider — “we patched in April” is necessary but not sufficient. The real question is whether anything was planted during the window.

What To Do Now

Confirm the patch, then hunt for what the window may have left behind:

  • Force the update to a fixed build. Run /scripts/upcp --force and confirm the server is on a patched release — 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, or 11.136.0.5 (or later on your track).
  • Lock down the panel ports. Restrict WHM and cPanel ports — 2082/2083, 2086/2087, 2095/2096, 2077/2078 — to trusted IP addresses at the firewall, and enforce MFA on every WHM and cPanel account.
  • Hunt for pre-patch compromise. Because exploitation ran for months, review authentication logs and look for unexpected account creations, new SSH keys, unfamiliar cron jobs, and changed admin credentials dated before your patch. Treat a previously-unpatched, internet-exposed server as suspect until checked.
  • Retire EOL versions. No patch is coming for end-of-life cPanel. Schedule the upgrade as urgent, not routine.

Open Questions

A few threads are worth watching. cPanel has not attributed the exploitation to a named actor, and the full list of who was compromised during the February–April window is not public — the 1.5-million figure is an exposure estimate, not a confirmed victim count. And with technical details held back at disclosure, defenders worked from provider descriptions rather than a root-cause writeup; the security-research analyses now appearing (watchTowr and others) are what will firm up detection guidance.

Primary Documents

Read more