cPanel Had an Authentication Bypass. Exploits Were Already in the Wild.

On April 28, 2026, cPanel disclosed a critical authentication vulnerability in cPanel and WHM affecting nearly all known versions, including end-of-life releases. The flaw allowed authentication bypass at the login level, meaning an attacker could access a WHM or cPanel interface without valid credentials. KnownHost, one of the first providers to publicly respond, confirmed that “successful exploits were seen in the wild” before the patch was released. cPanel characterized it as an “industry-wide issue.”

Within hours of the advisory going public, hosting providers across the industry took cPanel and WHM access offline globally. hosting.com, Namecheap, KnownHost, HostPapa, and InMotion Hosting all blocked cPanel ports at the network level while awaiting the patch. cPanel released a fix approximately 2-3 hours after the public advisory. Full deployment across major providers took 6-7 hours. No CVE has been publicly assigned to the vulnerability as of publication.

What the Vulnerability Was

The cPanel advisory, published at support.cpanel.net, describes a critical vulnerability in cPanel and WHM login authentication. The exact technical mechanism has not been publicly detailed by cPanel. Based on provider communications and community reports, the flaw operated at the authentication layer of the control panel login, enabling unauthorized access without a valid password. KnownHost described it as a “zero-day authentication/privilege escalation bug affecting almost all known cPanel versions, both end-of-life and supported.”

Providers blocked the following ports as an emergency measure: 2082 and 2083 (cPanel HTTP/HTTPS), 2086 and 2087 (WHM HTTP/HTTPS), 2095 and 2096 (Webmail), and 2077 and 2078 (WebDisk). Websites, applications, databases, and email continued operating normally throughout the incident. cPanel access was the specific attack surface.

How the Day Unfolded

KnownHost was among the first providers to move, announcing the vulnerability and implementing network-wide port blocks at 2:39 PM local time on April 28. The scope expanded over the following hour as webmail and WebDisk ports were added to the block list. hosting.com took cPanel and WHM offline across all managed servers and extended restrictions to webmail, blocking access at the network level. The company’s post on LinkedIn confirmed the action was taken based on direct communication from cPanel about the vulnerability.

Namecheap posted its first public status update at 3:37 PM EDT and began maintenance at 3:45 PM EDT, blocking TCP ports 2083 and 2087. cPanel released the patch at approximately 5:10 PM. Namecheap confirmed patch availability at 6:35 PM EDT with a projected 2-3 hour deployment window. By 10:42 PM EDT, Namecheap confirmed all servers had been patched and service was restored. KnownHost restored ports at 10:21 PM after the majority of its network was updated. hosting.com moved to recovering status at approximately 11:40 PM CST. HostPapa completed Shared and Reseller servers by 11:49 PM EST, with VPS servers completing shortly after.

Was This Reported Earlier?

An industry source who contacted webhosting.today directly stated that the vulnerability had been reported to cPanel approximately two weeks before the April 28 public advisory, and that cPanel’s initial response was that nothing was wrong. If accurate, the timeline between private disclosure and patch availability raises significant questions about cPanel’s vulnerability response process.

hosting.com’s incident communications referenced the vulnerability as having been “responsibly disclosed to cPanel,” confirming that private disclosure preceded the public advisory. The gap between private disclosure and patch availability, and what happened during that window, is not addressed in any public cPanel communication.

webhosting.today has contacted cPanel directly with questions about the disclosure timeline and is awaiting a response. We will update this article when cPanel responds.

Provider Responses

hosting.com was among the most transparent in its public communications, posting on LinkedIn: “Earlier this evening, we took cPanel and WHM offline on all managed servers due to reports from cPanel of a security vulnerability in their software. We have now extended this restriction to online webmail and blocked access at a network level.” Engineer Hernan R. described the action in the company’s status page as responding to “a possible authentication vulnerability with the cPanel control panel system which was responsibly disclosed to cPanel and on their advice we have blocked access.” Later that night, engineer Sam S. confirmed: “The root cause of this incident has been identified as an issue originating from cPanel and is outside of our direct control. It has impacted cPanel users globally across all vendors.”

InMotion Hosting described it as a “critical authentication vulnerability affecting all currently supported versions of cPanel and WHM” and closed cPanel and WHM ports while preserving all website, application, database, and email functionality. The company’s Account Management Panel login remained unaffected throughout the incident.

For unmanaged server customers, KnownHost advised running /scripts/upcp via SSH directly to apply the cPanel patch manually.

What Hosting Providers Should Do Now

If you operate cPanel servers and have not yet confirmed patch deployment, the immediate action is to verify that your cPanel installation is running the patched version released on April 28. The update is available via the standard /scripts/upcp upgrade script. Given that active exploits were confirmed in the wild before the patch was released, any server running an unpatched version during the April 28 window should be treated as potentially compromised pending investigation.

Review server access logs covering the period before port blocks were implemented. Authentication logs for WHM and cPanel interfaces should be audited for access attempts and successful logins that did not correspond to known legitimate users. The absence of a CVE means automated vulnerability scanners may not flag this incident; manual verification is necessary.