cPanel & WHM Authentication Bypass (CVE-2026-41940), Patch Now and Hunt for Pre-Patch Compromise

cPanel (WebPros) published an emergency security update on April 28, 2026 for what its release notes called "an issue with session loading and saving." The issue was assigned CVE-2026-41940 the following day and rated CVSS 9.8: an unauthenticated authentication bypass in cPanel & WHM that lets a remote attacker promote a pre-auth session to a fully authenticated root session, bypassing both the password and the 2FA gates without ever hitting an authentication code path. Per cPanel's advisory the flaw affects cPanel software, including DNSOnly, across all versions after 11.40, which in practice is every currently supported cPanel & WHM line plus many older deployed systems; WP Squared is also affected. watchTowr Labs published a full technical write-up and a public detection artifact on April 29, and KnownHost (managed cPanel host) reports execution attempts in the wild as early as February 23, 2026, well before the public advisory. Searchlight Cyber / Assetnote separately documented that simply firewalling cPanel/WHM ports may not be sufficient, since cPanel's per-vhost Apache config exposes the same management endpoints through a /___proxy_subdomain_whm/ path on every virtual host. If your cPanel/WHM management surface was reachable during the disclosure window through any path, treat the host as potentially compromised until proven otherwise.

Status checked: April 30, 2026. Fixed-version guidance and advisory text may change; verify against cPanel's current advisory before remediation. Framing note: this is a vendor-acknowledged code vulnerability with a public PoC and researcher-attributed in-the-wild exploitation. The response is patch plus session-file forensics plus credential rotation, in that order. The cPanel advisory is the operative source for patched build numbers; the watchTowr write-up is the operative source for the technical mechanism; the Searchlight / Assetnote write-up is the operative source for accurate exposure assessment beyond direct port reachability.

Why this one matters

cPanel & WHM is the management plane for a very large fraction of the shared-hosting internet. watchTowr's framing of "north of 70 million domains" is not hyperbole; Rapid7's Shodan figure of roughly 1.5 million internet-exposed cPanel instances captures the directly-reachable WHM/cPanel logins specifically. WHM gives root-level administration of the server (SSL, accounts, mail, DNS, shell access, the lot); cPanel gives per-account control of every hosted website and database on that server. A successful exploit of CVE-2026-41940 against a WHM port effectively yields root on the host and, transitively, control of every customer site and database it manages. On a typical shared-hosting box, that is dozens to hundreds of customer sites per compromised server.

The bug is also unusually clean. It does not require an account, it does not require a memory corruption primitive, it does not require defeating ASLR or sandboxes, and the exploit fits in a handful of HTTP requests. Once watchTowr published the chain, the barrier to incorporation into mass scanners dropped to roughly the time it takes to translate Perl-flavored prose into a Python loop. Hadrian's Nuclei template (cited above) and watchTowr's own Detection Artifact Generator make detection trivial; weaponized scanners will not be far behind, if they are not already in flight.

Am I affected?

Quick checks

Confirm the running build:

/usr/local/cpanel/cpanel -V

Compare against the patched-version table in the IOC block. If the build is older than the patched threshold for its release track, the host is vulnerable.

cPanel ships a session-file IOC scan as part of its updated advisory; per the advisory it scans /var/cpanel/sessions/ for the indicator patterns described below. Run the vendor script first if it's available on your patched build, then do the manual hunt for completeness:

grep -lE '^(hasroot|user|tfa_verified|cp_security_token|successful_internal_auth_with_timestamp)=' /var/cpanel/sessions/raw/* 2>/dev/null

Look for any pre-auth session (needs_auth=1 or no real origin_as_string=address=...,method=login) that contains any of: user=root, hasroot=1, tfa_verified=1, successful_internal_auth_with_timestamp=..., a cp_security_token the daemon never issued, or a multi-line pass= value. Per cPanel's advisory, a session containing both token_denied and cp_security_token is a strong exploitation indicator (it implies the do_token_denied cache-promotion step landed).

For network-side hunt, audit cpsrvd access logs for the disclosure window. The exploitation signature is a three-request sequence from the same source IP within a short window: a 401 response on POST /login/?login_only=1 (mints the pre-auth session), immediately followed by an Authorization: Basic request to a non-/login URL such as / with a truncated whostmgrsession cookie (no comma in the cookie value, returns 307 to a /cpsess<digits>/ path), followed by a request to a non-login URL without a valid cp_security_token in the URI such as GET /scripts2/listaccts (triggers the do_token_denied cache-promotion). The truncated cookie alone is the highest-signal item; legitimate clients always send the full :<name>,<ob_hex> cookie that the server originally issued, so a whostmgrsession value with no comma is anomalous by construction.

Response, if you ran a vulnerable build with reachable management surface

1. Patch immediately, then verify. Run the cPanel update script as root, then confirm the installed build, then restart the daemon to ensure no in-memory copy of the old code is still serving requests: /scripts/upcp --force /usr/local/cpanel/cpanel -V /scripts/restartsrv_cpsrvd Compare the resulting build against the patched-version table in the IOC block (or, more authoritatively, against the cPanel advisory at remediation time). If the host is on a managed-hosting plan, verify your provider has applied a fixed build for your branch on your specific server, not just rolled it out generally; per cPanel, hosts with automatic updates disabled or pinned to a specific version will not auto-update and must be manually remediated. There is no durable substitute for a fixed build; the items below are containment, not replacement.
2. If you cannot patch immediately, contain completely. Per cPanel's mitigation guidance: block inbound traffic on ports 2083, 2087, 2095, and 2096 at the firewall, or stop the cpsrvd and cpdavd services until the patch is applied. Hosting providers (Namecheap, Hosting.com, InMotion, TPP, and others) used port blocking as the bridge during the patch window; this is the right pattern for any operator who cannot deploy the update inside the next few hours. Critically, port blocking alone is not a complete containment per Searchlight Cyber's finding: the /___proxy_subdomain_whm/ and /___proxy_subdomain_cpanel/ proxy paths remain reachable through any cPanel-managed virtual host's normal HTTPS service (typically ports 443, often also 80). Operators relying on port blocking should either also stop cpsrvd/cpdavd outright, add WAF rules that block requests matching /___proxy_subdomain_whm and /___proxy_subdomain_cpanel on every vhost, or restrict access to those paths to a known admin IP range. If WHM access from a specific admin IP is required, firewall to that IP only, do not leave WHM open globally.
3. Hunt session files for indicators of exploitation. Run the IOC scans above against /var/cpanel/sessions/raw/ and /var/cpanel/sessions/cache/. Any pre-auth session containing top-level user=root, hasroot=1, tfa_verified=1, or successful_internal_auth_with_timestamp is a high-confidence exploitation indicator. Multi-line pass= values are the artifact of the CRLF injection itself. Per cPanel, the combination of token_denied and cp_security_token in the same session is a strong signal that the cache promotion step ran. Preserve the session files (cp -a, do not edit in place) before purging anything; if you find evidence of compromise, you will want the originals for incident-response work.
4. Audit cpsrvd access logs for the exploit signature. Look for the three-request sequence described above (POST /login/?login_only=1 returning 401, then Authorization: Basic on a non-/login URL with truncated whostmgrsession cookie returning 307, then a request to a non-login URL without a valid cp_security_token in the URI). Scope the review to the disclosure window and earlier. KnownHost reports execution attempts from February 23, 2026, so cap your log review window at least to that date if your retention reaches it; consider going further back, since the actual zero-day window may precede observed probing. The truncated cookie (no comma, missing ob_hex tail) is the highest-signal fingerprint and the one to grep for first.
5. If you find evidence of compromise, treat as full root compromise of the host. The bug produces a WHM session as root, which is equivalent to root on the cPanel host. A password reset alone is not sufficient containment; an attacker who reached root could have planted SSH keys, cron entries, systemd units, or shell-init backdoors that survive a password change. Preserve evidence before any cleanup (snapshot /var/cpanel/sessions/, the cpsrvd access and error logs, /var/log/wtmp, and full disk if practical). Then run the standard post-root-compromise audit: check /etc/passwd and /etc/shadow for unexpected accounts; /root/.ssh/authorized_keys and every customer's ~/.ssh/authorized_keys for unauthorized keys; crontab -l for root and every system user, plus /etc/cron.*/; /etc/systemd/system/ for unauthorized services; ~/.bashrc, ~/.profile, and /etc/profile.d/ for shell-init persistence; WHM accounts list for accounts you did not create; reseller accounts; new API tokens; new WHM users; modified web roots and plugin/theme files for every hosted site. Audit DNS, mail forwarders, and FTP accounts as well; an attacker with WHM root can pivot into any of these. Per cPanel's own incident-response guidance, after IOC hits: purge affected sessions, force password resets for root and all WHM users, and audit access logs and persistence surfaces. If the host is multi-tenant shared hosting, the blast radius includes every customer site and database on the box. Customer notification is a separate workstream from the technical cleanup.
6. Rotate every credential the host touched. Root password and SSH keys; every WHM/cPanel account password; every reseller password; every API token (WHM, cPanel, integrations like cPanel-WordPress integrations, backup-system tokens, monitoring agents); every database root password and per-customer DB password; mail account passwords; FTP account passwords; any third-party integration credentials stored on the box (S3 backup keys, off-site backup credentials, monitoring tokens). For shared hosting, customer-side credentials reachable from the WHM root view (FTP, mail, DB) should be reset and the customers notified to rotate downstream application credentials (CMS admin, plugin secrets, application .env files) on their side.
7. Rebuild rather than clean for confirmed compromise. If session-file or log evidence confirms exploitation, rebuilding from known-clean media and restoring customer data from backups predating the exposure window is the safer path. The exploit gives attacker code execution as root via WHM; persistence surfaces on a Linux server with WHM root are large and not enumerable cleanly. Forensic-cleaning a confirmed rooted hosting server is not a productive use of time.
8. Push the IOCs into your detection. SIEM/EDR rules for: pre-auth cPanel session files containing any of the privileged top-level keys; multi-line pass= values in /var/cpanel/sessions/raw/; cpsrvd access patterns matching the POST /login/?login_only=1 -> Authorization: Basic + truncated cookie sequence; unexpected new WHM accounts or API tokens; unexpected modifications to /var/cpanel/users/. Push watchTowr's Detection Artifact Generator against any cPanel surface in your estate to confirm patched status; Hadrian's Nuclei template is a cleaner pipeline-friendly check if you already run Nuclei.

The broader pattern

Three observations worth flagging.

First, the disclosure-window math is the part that should worry hosting operators. The CVE was assigned April 29 and the public PoC dropped the same day, but execution attempts were reportedly already underway since late February per KnownHost. The window for "patched and not exploited" was effectively never available to anyone whose ports were exposed; the meaningful question is whether any given host was hit during the pre-disclosure period. Session-file forensics is the operative answer because the exploit's injection artifacts (top-level hasroot=1, multi-line pass=, successful_internal_auth_with_timestamp on a session that did not legitimately authenticate) are durable on disk in /var/cpanel/sessions/ until the session expires. Run the scan even if you patched promptly.

Second, the root cause is a textbook example of a sanitizer that exists but is not consistently called. filter_sessiondata was already in the codebase; cpsrvd's Basic-auth path simply did not call it before invoking saveSession directly. The patch moves the sanitizer inside saveSession itself rather than relying on every caller to remember. That's a structural fix, and it's the right shape; the caller-must-remember pattern is a recurring source of this class of bug across long-lived codebases. Worth flagging in your own internal review patterns: any sanitizer that lives at the call site rather than at the sink is one missed caller away from a CVE.

Third, the chain illustrates a stacked-defenses failure mode that's worth internalizing separately from "the sanitizer was missing." There were several mechanisms that each, on their own, should have prevented exploitation: the per-session encoder would have hex-mangled the injection past usefulness; the JSON cache reads would have kept the injected lines bundled inside a single pass string rather than top-level keys; docheckpass_whostmgrd would have failed the forged password against /etc/shadow on every request. Each was bypassed by a separate, individually modest defect: the encoder fails open on a malformed cookie; the cache is rewritten by an unauthenticated do_token_denied path that re-parses the raw file; the password check is short-circuited by a session-set successful_internal_auth_with_timestamp flag intended for legitimate external-auth flows. None of these is a dramatic individual flaw; together they compose into pre-auth root. Defense-in-depth that depends on attackers respecting the intended call sequence is the kind that fails this way.