cPanel published an emergency security advisory on April 28, 2026 covering CVE-2026-41940 — an unauthenticated authentication bypass in the cPanel & WHM login flow that affects every currently supported release track. The flaw carries a CVSS v3.1 score of 9.8, classified as CWE-306 (Missing Authentication for Critical Function), and was confirmed to be under active exploitation before patches were broadly deployed. Within hours of publication, hosting providers across the industry — including hosting.com, Namecheap, KnownHost, HostPapa, and InMotion Hosting — pulled cPanel and WHM ports off the internet at the network edge while their fleets reconciled with the patched builds.

If your infrastructure includes a cPanel or WHM control panel reachable from the internet and you have not yet applied this update, treat that interface as compromised until proven otherwise.

The Bug

The vulnerability lives in the login flow itself. According to the writeup published by watchTowr Labs (titled, fittingly, “The Internet Is Falling Down, Falling Down, Falling Down”), the chain combines a session-creation primitive with a CRLF injection against the authentication mechanism. An unauthenticated remote attacker can craft a request that bypasses login entirely and lands in a privileged session against either the cPanel user interface or the WHM root interface, depending on which port is exposed.

From there, the attacker has whatever the panel can do: account creation, file management, mail configuration, database access, cron jobs, terminal access where enabled, package installation, and a turnkey path to persistence on the underlying server. watchTowr Labs has published a proof-of-concept exploit (watchTowr-vs-cPanel-WHM-AuthBypass-to-RCE.py) demonstrating the auth bypass chained to remote code execution, and at this point assume the script kiddies have it too.

CWE-306 is the simplest category of authentication failure — a critical function that did not check whether the caller was authenticated. The CRLF wrapper is what made the missing check reachable rather than what made it dangerous. The dangerous part was always there.

Affected Versions and Fixed Builds

cPanel & WHM versions prior to the following are vulnerable:

  • 11.110.0.97 (was 11.110.0.96 — LTS track)
  • 11.118.0.63 (was 11.118.0.61)
  • 11.126.0.54 (was 11.126.0.53)
  • 11.132.0.29 (was 11.132.0.27)
  • 11.134.0.20 (was 11.134.0.19)
  • 11.136.0.5 (was 11.136.0.4 — current track)

cPanel pushed emergency updates across all six supported release branches simultaneously on April 28, which is what you want to see from a vendor on a 9.8. Run /scripts/upcp --force and verify the build with /usr/local/cpanel/cpanel -V afterward.

If you are pinned to an unsupported release for any reason, you are exposed and there is no backport coming. Get to a supported track or take the panel off the public internet.

Why This Matters for Infrastructure

cPanel runs the administrative plane for an enormous slice of the public-facing web — shared hosting accounts, reseller panels, dedicated servers, and the management surface for anything from personal blogs to mid-size SaaS deployments. A pre-auth bypass against the login flow is roughly the worst possible failure mode for that class of system: every panel exposed to the internet was, briefly, an open door into the customer’s filesystem and adjacent tenants on the same machine.

The hosting providers that yanked the ports at the network layer made the right call. It is also the reason this incident did not become a six-figure mass defacement event in its first 12 hours. The provider response is the only thing standing between a disclosed-and-exploited 9.8 and a slow-motion industry-wide breach narrative, and it worked here — but it worked because the affected layer is concentrated in a small number of large operators. Self-managed VPS owners running cPanel without that protective umbrella are the long tail still at risk.

What To Do Right Now

Patch first, then audit. The exploit window opened with the public advisory and ran until your panel was rebuilt against a fixed version. Pull WHM access logs (/usr/local/cpanel/logs/access_log) and login event logs for the period from April 28 onward and look for unfamiliar successful auths, especially from sessions that did not transit a normal login form, and for newly created cPanel accounts, package installs, or modified ~/.ssh/authorized_keys files in user home directories. Rotate any credentials managed through the panel — API tokens, FTP/SSH passwords for hosted accounts, and anything stored in user .env files that an attacker with filesystem read could have grabbed.

If your panel was internet-exposed and you cannot confidently rule out compromise after that audit, treat the host as compromised and rebuild rather than clean. cPanel servers are notoriously hostile to forensic recovery once an attacker has had a privileged shell, and the cost of a fresh install plus restored backups is lower than the cost of missing a webshell tucked into one of several thousand customer document roots.

References