On April 28, 2026, cPanel released an emergency security update for a vulnerability in cPanel and WHM that had been actively exploited in the wild since at least late February 2026. The vulnerability, CVE-2026-41940, is a critical-severity authentication bypass that lets an attacker take over a cPanel server remotely with no credentials at all. A public proof-of-concept exploit is available, the bug has been used in real attacks for over two months, and roughly 1.5 million cPanel servers are visible on the public internet according to standard search engine telemetry.
If you are a Gotekky managed cPanel customer, your server has already been patched. We deployed the update across our infrastructure within hours of the cPanel release and verified that no session compromise had occurred on managed servers in the exposure window. The rest of this guide walks through what the vulnerability is, how it was exploited, what Gotekky did, and what you should do if you operate self-managed cPanel servers anywhere else.
What CVE-2026-41940 actually is
cPanel and WHM share a single internet-facing daemon called cpsrvd that handles all six of cPanel's HTTP and HTTPS endpoints: the cPanel user interface on ports 2082 and 2083, the WHM administrator interface on ports 2086 and 2087, and Webmail on ports 2095 and 2096. The vulnerability lives in the part of cpsrvd that creates and saves session files before authentication completes. By sending a specially crafted HTTP Basic authentication header containing newline characters in the password field, an attacker can inject fake session data into the on-disk session file. When that session is reloaded, attacker-controlled values like user=root and tfa_verified=1 promote what should have been a failed login attempt into a fully authenticated root session, including bypassing two-factor authentication.
The technical category is CWE-306, missing authentication for a critical function, expressed as a CRLF injection. The CVSS v3.1 score is 9.8 out of 10. The attack is unauthenticated, requires no user interaction, and works against any cPanel or WHM instance reachable on its standard ports. The codebase contained a sanitization helper that would have prevented the injection, but it was not invoked at the relevant code path. The patch wires that helper into the session-saving code itself so the vulnerability cannot recur.
How long this was a zero-day in the wild
According to KnownHost and other major hosting operators, exploitation against cPanel servers was confirmed beginning February 23, 2026, more than two months before the cPanel advisory and patch on April 28. The disclosure timeline is contested: per published reporting, security researchers reported the bug to cPanel approximately two weeks before the public advisory, and cPanel's initial response indicated the issue was not a vulnerability. The patch was eventually released as an emergency update across all supported versions on April 28 with a same-day public CVE.
This means that any cPanel server that was reachable on the standard cPanel ports between late February and April 28 must be treated as potentially compromised. The exploitation was not theoretical. It was happening, against real servers, for two months.
What Gotekky did and what managed customers need to know
We deployed the cPanel patch on every managed server in our Toronto infrastructure within hours of the April 28 release. We force-ran upcp on every node, verified the build numbers matched the patched versions cPanel published, restarted cpsrvd, and ran cPanel's published detection script against the session storage on every server. No managed Gotekky server in our infrastructure showed evidence of session compromise during the exposure window. Customer accounts were not affected.
For customers on Gotekky managed plans, no action is required. The patch is applied. The detection script returned clean. Your sessions and credentials were not part of the at-risk population.
We also took the opportunity to apply two additional cPanel security updates that landed in the same patch cycle (described below), so managed customers are now current on the entire cPanel ecosystem patch round, not just the one CVE.
The patched cPanel and WHM build numbers
If you operate self-managed cPanel servers, the patched versions you need are:
- 11.86 (legacy): 11.86.0.41
- 11.110 (LTS): 11.110.0.97
- 11.118: 11.118.0.63
- 11.126: 11.126.0.54
- 11.130: 11.130.0.19
- 11.132: 11.132.0.29
- 11.134: 11.134.0.20
- 11.136 (current): 11.136.0.5
- WP Squared: 136.1.7
Any cPanel version older than 11.86 is end-of-life, will not receive a patch, and must be migrated. If you are running such a version, treat the server as compromised and rebuild on a current version.
If you operate self-managed cPanel servers, do this today
Step one: update immediately. Run /scripts/upcp --force as root. This forces an immediate update through cPanel's normal upgrade flow, ignoring any scheduled delay. Verify the build number with /usr/local/cpanel/cpanel -V. Restart cpsrvd with /scripts/restartsrv_cpsrvd.
Step two: run cPanel's official detection script. The script checks /var/cpanel/sessions/ for the specific markers that indicate exploitation: session files containing both token_denied and cp_security_token, pre-authentication sessions carrying authenticated attributes like hasroot=1, sessions with tfa_verified that lack legitimate origin markers, and multi-line pass= values. If any of these are flagged, you have evidence of attempted or successful exploitation.
Step three: if the detection script flags compromise, or if you cannot rule out exploitation during the exposure window, rotate every credential. This means root password, every WHM user password, MySQL passwords, FTP passwords, email account passwords for every customer, and any API tokens. Audit /var/log/wtmp and WHM access logs for unexpected logins. Check for persistence: cron entries you did not create, SSH authorized_keys you did not add, modified .bashrc files, unfamiliar WHM accounts, and modified wp-config.php across hosted WordPress sites. Treat the server as untrusted until you have completed a full audit.
If you cannot patch within the next few hours for change-control reasons, the workaround is to firewall the cpsrvd ports (2082, 2083, 2086, 2087, 2095, 2096) so they are reachable only from your administration IP ranges, and stop cpsrvd entirely with /scripts/restartsrv_cpsrvd --stop. Two-factor authentication on WHM does not block this attack on its own, because the exploit injects tfa_verified=1 directly into the session file.
Two additional cPanel patches that landed the same week
Alongside the CVE-2026-41940 release, cPanel shipped two other security updates that affect almost every cPanel server. Managed Gotekky customers received both as part of the same maintenance window. If you self-manage, these are worth applying.
EasyApache 4 update to v25.57. The ea-apache24 package was updated from version 2.4.66 to 2.4.67, addressing 11 Apache HTTP Server CVEs. The most significant is CVE-2026-23918, a remote code execution flaw in mod_http2 with a CVSS of 8.8. mod_http2 is not enabled by default but is commonly enabled on cPanel servers running modern HTTP/2 configurations, which makes this functionally near-universal. CVE-2026-24072 affects mod_rewrite, which is part of the core Apache build and enabled by default on every cPanel server. The remaining nine CVEs range from moderate to low and apply variably depending on which modules are loaded. Apply via the standard EasyApache 4 package update process in WHM, or via the command line. No configuration changes or downtime are required. The release covers CentOS 7, AlmaLinux 9, and Ubuntu 20.04, 22.04, and 24.04.
Exim 4.99.2 update. Four Exim CVEs were addressed in this update, the most critical being CVE-2026-40685 with an upstream CVSS rating of 9.8 (critical) and CVE-2026-40684 at 7.5 (high). Apply via the standard cPanel update mechanism. No configuration changes are required.
At the time of writing, the EasyApache and Exim CVEs do not have known active exploits, but the cPanel security team is releasing them proactively. Both updates ship through the standard cPanel update mechanisms, so any server with automatic updates enabled and not version-pinned will receive them on the next update cycle without intervention.
Why this matters even more in combination with the Linux kernel CVE this week
CVE-2026-41940 grants an attacker an authenticated WHM root session remotely, but it does not on its own give them shell access to the underlying Linux host. That distinction matters less than it sounds, because once you have WHM root, you have the ability to create cPanel users, modify configuration, deploy custom code, and schedule cron jobs that run as those users.
The harder problem is the combination with two Linux kernel vulnerabilities disclosed in the same window: CVE-2026-31431 (Copy Fail) on April 29, and the Dirty Frag family (CVE-2026-43284 and CVE-2026-43500) on May 7. Both let any local user on a Linux server escalate to root in seconds, and they are separate problems requiring separate mitigations. Combined with the cPanel bug, the chain looks like this: an attacker exploits CVE-2026-41940 to get into WHM with no credentials, creates a cPanel user with shell access, and immediately runs either Copy Fail or Dirty Frag to take over the underlying Linux host as root. Patching cPanel without also addressing both kernel vulnerabilities leaves your servers vulnerable to this exact chain.
Gotekky has applied the cPanel patch and both kernel mitigations across all managed servers. We have separate guides on Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284 and CVE-2026-43500) covering the kernel side in detail. If you operate self-managed cPanel servers, treat all three as a single emergency response and apply them this week.
Audit and credential rotation guidance for the exposure window
If your cPanel server was internet-reachable between February 23 and April 28, 2026, the conservative posture is to assume the auth-bypass window may have been used against you, even if the detection script returns clean. The detection script catches the most common exploitation patterns but cannot prove a server was not exploited. Specifically, you should rotate WHM root and every administrator account password, rotate every cPanel user account password, rotate database passwords for any MySQL or PostgreSQL credentials accessible from WHM or the cPanel user interface, audit authorized_keys in every cPanel home directory, audit cron tabs for every user, audit hosted WordPress installations for unfamiliar admin accounts and modified core or theme files, and review the WHM Reseller Manager and Account Manager for accounts you did not create.
This is a meaningful amount of work and is the realistic cost of a 60-day zero-day window in critical infrastructure. The Canadian Centre for Cyber Security has published an alert on this CVE under reference AL26-008 with similar guidance. If you need help executing the audit, Gotekky's management service includes incident response work for cPanel environments.
The pattern this represents
CVE-2026-41940 is the kind of vulnerability that the hosting industry will be processing for months. The 60-day zero-day window is unusually long for a critical authentication bypass and represents either a coordination failure between researcher and vendor or active exploitation that outpaced disclosure. Either way, the operational lesson is that single-perimeter trust in any internet-facing control plane is no longer adequate. Defense in depth (firewalled admin ports, restricted IP ranges for WHM access, monitoring on session files, prompt patching with verified rollout) is now the minimum standard for cPanel infrastructure, not an optional hardening step. We are deploying additional monitoring on managed servers as a result of this incident and will publish more on that work in a future guide.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.