1.5 million control panels, no password required: the cPanel and WHM login bypass

cPanel and WHM sit at a specific and dangerous point in the hosting stack. The panel is not the website. It is the thing that owns the website: it provisions accounts, resets passwords, edits DNS, reads mail, and issues database credentials for every tenant on the box. A single WHM login is often the administrative root of dozens or hundreds of customer domains. That is exactly why an authentication bypass here is not a website bug. It is a hosting-provider bug, and its blast radius is every tenant behind the panel. Verifiable security.

What the flaw is

According to the NVD entry, CVE-2026-41940 is an authentication bypass in the cPanel and WHM login flow, classified as Missing Authentication for Critical Function (CWE-306). In plain terms, a function that should require proof of identity can be reached without it. The advisory scopes the affected software broadly: cPanel and WHM in every version after 11.40, up through the 11.136.0.x line, plus WP Squared before 136.1.7. The fix ships as a set of patched builds along each supported tier, listed below.

The severity numbers reflect the position, not just the mechanics. NVD records CVSS 3.1 at 9.8 and CVSS 4.0 at 9.3, both Critical, driven by a network attack vector, no privileges required, no user interaction, and a full compromise of confidentiality, integrity, and availability once the session is obtained. The reason those metrics all pin to the worst case is that the target is an administrative control plane. There is no lower-privilege version of taking over WHM.

The critical function is "start an authenticated session." When it can be reached without the credential check, identity stops being enforced. Illustrative, not from any specific host.

The mechanism, and where to be precise

Be careful to separate what the vendor-neutral advisory asserts from what independent analysis describes, because the two operate at different levels of detail. NVD's fact is the class: this is an authentication bypass in the login flow, CWE-306. That is the claim we stand behind without qualification.

The deeper chain is described in Rapid7's analysis, and we attribute it to them rather than to NVD. Rapid7's write-up characterizes the exploited path as a CRLF-style injection into the component that writes session state, combined with an encryption-skip triggered by a malformed session cookie. With the session write no longer protected the way the design assumed, the attacker abuses cPanel's session caching to promote an injected session into a privileged, authenticated login. The three parts reinforce each other: the injection places content into session state, the encryption-skip removes the integrity that would have rejected it, and the caching layer serves the poisoned session back as legitimate. The net effect matches the NVD class exactly, arrived at from the other direction: an unauthenticated attacker ends up holding an authenticated control-panel session.

We stay at the defender level here. Naming the moving parts is not a recipe, it explains why patching is the only real fix. Each step alone might look like a minor robustness issue; chained, they defeat the login boundary completely, which is why no configuration change or firewall rule substitutes for the corrected build.

Why the timeline matters

This one was not caught at disclosure. Public reporting, including Help Net Security, indicates the flaw was exploited in the wild as a zero-day for roughly two months before a patch was available. CISA added it to the Known Exploited Vulnerabilities catalog on 30 April 2026, with a remediation due date of 3 May 2026, one of the tightest windows the catalog assigns, which is the government's way of saying this is being used right now.

A two-month pre-patch window means the right question is not only "are we patched," it is "were we already touched." Patching closes the door. It does not tell you who walked through it first.

That window changes the remediation math. For a bug fixed the day it went public, patching is nearly the whole job. For one live and exploited for two months, patching is the first step, not the last. Any account, session, or configuration change made through the panel during that window is suspect, because the attacker had the panel's own authority to make it. Rotating secrets and hunting for rogue artifacts is part of the fix, not optional cleanup.

How to recognize your exposure

You can assess this without reproducing anything, because exposure comes down to three readable facts.

How Celvex catches this

The uncomfortable part of this vulnerability is not the exploit chain, it is the trust placement. A control panel is filed under infrastructure, so it inherits the assumption that its login is solid and gets less adversarial scrutiny than the public website it hosts. CVE-2026-41940 is a reminder that the login boundary of the thing that owns everything else deserves the most scrutiny, not the least. Find the exposed panels, confirm the build, close the window, and prove the window is closed.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.