CVE-2026-41940: the cPanel & WHM auth bypass, and how to check for it

CVE-2026-41940 is a CVSS 9.8 authentication bypass in cPanel & WHM, disclosed 28 April 2026 after roughly two months of undetected in-the-wild exploitation starting around 23 February 2026. It's unauthenticated, needs no user interaction, and grants full root access to WHM — not a foothold, the whole box. CISA added it to the Known Exploited Vulnerabilities catalog within days. If you run cPanel and haven't confirmed your build number since April, do that before reading the rest of this article.

This isn't a retrospective for its own sake — the same session-handling pattern (writing unsanitised input to a session file that gets re-parsed as trusted data) shows up across control panels, so the mechanics are worth understanding even if you patched in April. And if you're auditing a fleet you inherited, or buying a used VPS with cPanel preinstalled, this is exactly the kind of thing you check for before trusting the install.

Affected versions

Every branch from 11.86 through 11.136 shipped the flaw, along with WP Squared prior to 136.1.7:

Ports in scope: 2082/2083 (cPanel), 2086/2087 (WHM), 2095/2096 (Webmail) — anywhere cpsrvd answers. Around 1.5 million cPanel instances were internet-reachable on these ports at disclosure time, per the researchers who first wrote it up.

How the bypass works

The root cause is cpsrvd writing unsanitised input into a session file and later trusting that file's contents as authenticated state.

1. Pre-auth session creation. A failed login against /login/?login_only=1 still creates a session file on disk before any credential is verified.
2. CRLF injection via Basic auth. The attacker sends a request to a non-login URL with an Authorization: Basic header whose decoded password contains raw \r\n characters. saveSession() writes that password straight to the session file without filtering — the sanitisation lives in a wrapper function the write path skips.
3. File fragmentation. The literal newlines split what should be one pass=... line into several lines, each parsed as an independent key=value pair when the file is re-read.
4. Promotion to authenticated state. A URL-token mismatch forces a re-parse in "nocache" mode. The injected keys — user=root, hasroot=1, tfa_verified=1, a forged cp_security_token, and a fake successful_internal_auth_with_timestamp — get promoted to top-level session properties. WHM now believes this is an authenticated root session, with no password ever having been verified.

No exploit code is reproduced here — the point is the pattern: never trust re-parsed session state that includes attacker-controlled bytes, and sanitise at the write boundary, not just at known read call sites.

Check if you're patched

/usr/local/cpanel/cpanel -V

Compare the output against the fixed-versions table above. If your build number is below the fixed point for your branch, you are exposed right now — this isn't a "patch during your next maintenance window" item.

# force an immediate update check instead of waiting for the nightly cron
/scripts/upcp --now

Look for indicators of compromise

Even patched servers are worth a quick look if they were exposed between February and April.

grep -rl "user=root" /var/cpanel/sessions/raw/ 2>/dev/null
grep -rlE "hasroot=1|tfa_verified=1|successful_internal_auth_with_timestamp" /var/cpanel/sessions/raw/ 2>/dev/null

A raw session file with more than one pass= line, or any of the promoted keys above in a session that never completed a real login, is a strong signal of exploitation attempts. Also check the cPanel access logs for a 401 on /login/?login_only=1 immediately followed by an Authorization: Basic request to an unrelated URL from the same source IP — that sequence is the attack signature.

If you can't patch immediately

Patching is the only complete fix, but if you're waiting on a maintenance window:

• Restrict 2082/2083/2086/2087/2095/2096 to known administrative IP ranges at the firewall — see CSF country and IP blocking for the cc.deny/cc.allow mechanics.
• Forward /usr/local/cpanel/logs/access_log and login_log to external log storage so you keep evidence even if the box is later compromised.
• Don't rely on cPHulk alone — it throttles repeated failed logins, but this bypass doesn't need a successful login attempt in the way cPHulk's brute-force detection expects.

None of these are a substitute for the update. Blocking ports at the firewall still leaves you exposed to anyone already inside your network perimeter or connecting through a VPN you trust.

Why this took two months to surface

The gap between first exploitation (23 February) and disclosure (28 April) is the real lesson here, independent of the technical bug. A CVSS 9.8 unauthenticated root bypass sat undetected on the single most widely deployed hosting control panel for roughly nine weeks. If your monitoring stack doesn't already alert on unexpected root-level cron jobs, new SSH authorized_keys entries, or WHM sessions that skip the normal login flow, this is the concrete argument for adding it — not "in case," but because it already happened once at scale. A current cPanel license keeps you eligible for emergency patches the moment they ship; a lapsed or cracked license means finding out about the next one from a forum post instead of /scripts/upcp.

Next steps

• cPanel & WHM v136 release notes — the release this CVE's final patches landed alongside.
• Fixing the License invalid banner in WHM — if /scripts/upcp is failing because of a license problem, resolve that first.
• WHM cPHulk tuning — brute-force protection that complements, but doesn't replace, staying current on patches.