cPanel Had a Critical Authentication Bypass on April 28

cPanel Authentication bypass

If your cPanel was unavailable on April 28, your host didn’t break. They shut it down on purpose.

In this article
  1. What Is cPanel, and Why Does a Flaw Matter So Much?
  2. What the Vulnerability Actually Did
  3. Exploits Were Already in the Wild Before the Patch Existed
  4. How the Industry Responded on April 28
  5. What You Should Do Now
  6. What This Incident Reveals About Your Host
  7. Questions About the April 2026 cPanel Vulnerability

That was the right call. A critical authentication bypass vulnerability had just been disclosed in cPanel and WHM, affecting virtually every version in existence, supported or not. Attackers already had working exploit code before the patch existed. Providers had roughly two choices: lock the door or leave it open.

This post covers what happened, why it matters even if your site never went down, and what you should check right now.

What Is cPanel, and Why Does a Flaw Matter So Much?

cPanel is the control panel most shared hosting customers use to manage their accounts. It’s where you add email addresses, install WordPress, manage files, and configure databases. If you’ve ever logged in to your host and seen a grid of icons, that was probably cPanel.

WHM (Web Host Manager) sits one level above it. Server administrators use WHM to manage the physical server itself: creating accounts, configuring security, and controlling everything running underneath. Think of cPanel as the key to your apartment. WHM is the master key to the entire building.

That framing matters because cPanel runs somewhere north of 70 million domains worldwide. It accounts for around 94% of the web hosting control panel market. When a vulnerability hits cPanel, it doesn’t affect one website. It potentially affects every website on every server running an unpatched version, and there are millions of those.

What the Vulnerability Actually Did

The flaw, now assigned CVE-2026-41940 with a CVSS severity score of 9.8 out of 10, was an authentication bypass. That means an attacker didn’t need a password.

Here’s how it worked without the jargon. Before a user logs in, cPanel creates a temporary session file on disk. The vulnerability allowed an attacker to inject malicious data into that file before the password check even ran. The injected data told the system the session was already fully authenticated as root. The system believed it. The password was never consulted.

Root access to a WHM server means full control over everything on it. Every hosted website. Every email account. Every database. An attacker with that level of access could install malware, steal customer data, create hidden backdoor accounts, redirect traffic, or use the server as a launchpad for further attacks. On a shared server hosting hundreds of small business sites, a single compromised WHM instance is a significant event.

Exploits Were Already in the Wild Before the Patch Existed

When KnownHost went public on the afternoon of April 28, it confirmed the worst part of the story: “successful exploits were seen in the wild” before any patch existed. KnownHost described it as a “zero-day authentication/privilege escalation bug affecting almost all known cPanel versions, both end-of-life and supported.”

That makes the CVE-2026-41940 designation fit the most literal definition of a zero-day. A flaw actively being used by attackers while the vendor was still building a fix.

The situation runs deeper still. According to reporting from webhosting.today, the vulnerability was reportedly disclosed to cPanel privately around two weeks before the April 28 advisory. cPanel’s initial response was reportedly that nothing was wrong. hosting.com’s own incident communications described the flaw as having been “responsibly disclosed to cPanel,” which confirms that private disclosure came first.

The gap between “we told them” and “patch available” is the window during which active exploitation occurred. cPanel has not publicly addressed this timeline. webhosting.today contacted the company directly and was awaiting a response at publication.

How the Industry Responded on April 28

Within hours of the advisory going live, providers across the industry pulled the plug on cPanel access. The response was fast and unusually coordinated.

The table below shows how major providers handled the incident:

Provider Action taken Access restored
KnownHost First provider to act publicly; blocked all cPanel and WHM ports; confirmed active exploits in the wild 10:21 PM EDT
Namecheap Blocked ports 2083 and 2087; communicated clearly via public status updates; patched all servers 10:42 PM EDT
InMotion Hosting Closed cPanel and WHM ports immediately; Account Management Panel was unaffected throughout April 29
hosting.com Took cPanel, WHM, and webmail offline across all managed servers; most transparent public communications ~11:40 PM CST
HostPapa Completed shared and reseller server patching by 11:49 PM EST; VPS servers shortly after April 29

cPanel released the patch roughly two to three hours after the public advisory, at approximately 5:10 PM EDT on April 28. Full deployment across major providers took six to seven hours from initial disclosure.

One point worth being clear on: your website was never at risk of going offline. The ports that were blocked are specific to the cPanel, WHM, webmail, and WebDisk login interfaces. Sites continued serving visitors normally throughout. Email delivery continued. Databases kept running. The only thing affected was the ability to log in to the control panel itself.

The ports blocked as an emergency measure were:

  • 2082 and 2083 — cPanel (HTTP and HTTPS)
  • 2086 and 2087 — WHM (HTTP and HTTPS)
  • 2095 and 2096 — Webmail
  • 2077 and 2078 — WebDisk

What You Should Do Now

If you’re on shared or managed hosting: Your host almost certainly handled this. By now, every competent managed cPanel provider has applied the patch and restored access. Check your host’s status page for a post from April 28 or 29 confirming the patch was deployed. You don’t need to do anything to your website itself.

If you manage your own cPanel server on a VPS or dedicated box: Run this command as root to force the update: /scripts/upcp --force. Then verify your installed version using /usr/local/cpanel/cpanel -V. The patched builds you’re looking for are:

  • 11.110.0.97
  • 11.118.0.63
  • 11.126.0.54
  • 11.132.0.29
  • 11.134.0.20
  • 11.136.0.5
  • WP Squared: 11.136.1.7

If you’re on an end-of-life cPanel version: No patch is coming. End-of-life releases are confirmed vulnerable and will stay that way indefinitely. The only path forward is upgrading to a supported version or migrating to a host running a patched install. This isn’t something to defer.

If your server was exposed during the April 28 window: Audit your authentication logs covering the afternoon of April 28, before port blocks were implemented. Look for unexpected successful logins, new user accounts you didn’t create, unfamiliar SSH keys, and any changes to cron jobs or server configuration. The absence of an earlier CVE assignment means automated security scanners may not flag the specific window, so manual verification is the only reliable check.

What This Incident Reveals About Your Host

Security incidents this serious are rare. But how a provider responds when one lands tells you more about their operations than any marketing page will.

The providers who blocked access immediately, communicated clearly, and deployed the patch within hours made the right call. A few hours of restricted panel access is a reasonable trade for keeping customer accounts out of an active exploit window.

It’s also worth noting that this doesn’t come in isolation. cPanel has had a difficult few years, with price increases causing ongoing friction across the hosting industry. And this incident arrived just a couple of weeks after a separate attack compromised 30 WordPress plugins through their update infrastructure. The pattern of trusted infrastructure being used as the attack surface is a recurring theme right now.

If you’re evaluating hosting providers and your current host went quiet on April 28, or restored access without confirming the patch was applied, that’s useful information to have.

Questions About the April 2026 cPanel Vulnerability

Was my website taken offline during this?

No. Websites, databases, and email delivery continued operating normally throughout the incident. The only thing affected was access to the cPanel, WHM, webmail, and WebDisk login interfaces. Providers blocked those specific ports as a protective measure while the patch was prepared and deployed.

How do I know if my host has patched CVE-2026-41940?

Check your host’s status page for a post dated April 28 or 29, 2026. Most providers who acted quickly also communicated publicly. If you can’t find one, contact their support team and ask them to confirm which cPanel version is running on your server. Patched versions are 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, and 11.136.0.5.

What could an attacker do with WHM access?

A compromised WHM instance gives root-level access to an entire server. That means full control over every website, email account, and database hosted on that machine. Attackers could install malware, steal credentials, create backdoor admin accounts, modify files, or use the server to distribute spam or launch further attacks. On a shared hosting server, that blast radius extends across every customer account on the box.

Does this affect people still running old, unsupported versions of cPanel?

Yes. The vulnerability affects end-of-life releases as well as all currently supported versions. No patch will be issued for unsupported builds. If your server is running an EOL version of cPanel, it is vulnerable and will remain so until you upgrade or migrate.

This article will be updated if and when cPanel responds publicly to questions about the private disclosure timeline.