- April 29, 2026
Critical Vulnerability in cPanel and WHM Under Active Exploitation (CVE-2026-41940)
On April 29th, cPanel published an emergency advisory concerning CVE-2026-41940, a security issue in “various authentication paths” in all supported versions of the cPanel software. cPanel provided security updates along with their public advisory. Well known hosting providers have confirmed that an exploit is already being used in-the-wild and some have taken the extreme step to firewall off access to the software until security patches could be deployed. Additionally, a few hours after the official cPanel advisory security researchers published a blog with details to produce proof-of-concept exploit code.
Executive Summary
On April 29th, cPanel published an emergency advisory concerning CVE-2026-41940, a security issue in “various authentication paths” in all supported versions of the cPanel software. cPanel provided security updates along with their public advisory.
Well known hosting providers have confirmed that an exploit is already being used in-the-wild and some have taken the extreme step to firewall off access to the software until security patches could be deployed. Additionally, a few hours after the official cPanel advisory security researchers published a blog with details to produce proof-of-concept exploit code.
cPanel is a popular web hosting control panel used to manage a large number of websites, and successful compromise of cPanel and WHM could impact all hosted sites on the victim server. Due to expansive implementation of cPanel and active exploitation in the wild, Beazley Security strongly urges affected organizations to update as soon as possible.
This is an evolving situation and Beazley Security labs will update this advisory with new information as it becomes available. Please review the advisory in the portal or via our public sites for additional details.
Affected Systems or Products
This vulnerability affects all currently supported versions of cPanel WHM.
Product | Affected Version | Fixed Version |
|---|---|---|
cPanel & WHM | < 11.110.0.97 < 11.118.0.63 < 11.126.0.54 < 11.132.0.29 < 11.136.0.5 < 11.134.0.20 | >= 11.110.0.97 >= 11.118.0.63 >= 11.126.0.54 >= 11.132.0.29 >= 11.136.0.5 >= 11.134.0.20 |
WP Squared | < 11.136.1.7 | >= 11.136.1.7 |
Mitigations / Workarounds
Upgrading to patched versions of cPanel is the only way to fully mitigate this vulnerability. Major hosting providers that use cPanel like Namecheap and KnownHost blocked login ports 2083 and 2087 for all their downstream clients until patches could be applied.
If fixes cannot be immediately applied for self-hosted implementations, the following steps can be taken to reduce risk of exposure:
Disable or restrict access to WHM and cPanel to trusted IP addresses only to reduce attack surface, typically ports 2083, 2087, 2095, and 2096.
Stop cpsrvd and cpdavd services on affected implementations. cPanel provided the commands below as a temporary mitigation:
whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice
Patches
Security updates were made available at the time of disclosure, along with short steps to apply the patches. Instructions to force an update on affected servers can be found in cPanel’s security advisory.
Indicators of Compromise
Active exploitation of CVE-2026-41940 in the wild has been confirmed by major hosting providers, with the vulnerability having been leveraged as a 0-day against hosting infrastructure prior to public disclosure.
Given active exploitation, internet exposed instances of self-hosted cPanel implementations should be reviewed for compromise. cPanel released a detection script that can be run on affected servers at the bottom of their security advisory to help facilitate hunting.
Additionally, defenders can monitor for these indicators of attack associated with the ongoing exploitation campaign:
39.194.2.152
45.92.1.188
hitreceipts[.]cc
37.49.228.135
193.142.59.50
185.234.9.165
18.143.202.206
34.132.67.199
Technical Details
watchTowr published an excellent article detailing the software bug, which deserves a thorough read-through. We will present a condensed version of the technical details here, with what a malicious, anomalous web request would look like for monitoring purposes.
The bug is twofold:
- 1.
Insufficient input sanitization when processing incoming HTTP header data, and
- 2.
Insufficient input validation when processing session cookies
The attack chain against this vulnerability would be as follows:
- 1.
Threat actor attempts an invalid login
- 2.
This creates an on-disk session file on the server at
/var/cpanel/sessions/raw/ - 3.
Victim server responds to threat actor with valid session data
- 4.
Threat actor sends anomalous request that injects malicious data into the session file created in step 2
- 5.
Threat actor now has an improperly validated session they can login with
The last step provided by watchTowr researchers comes down to crafting a malicious HTTP request similar to this:
GET / HTTP/1.1
Host: <target>:2087
Cookie: whostmgrsession=<encoded data 1>
Authorization: Basic <encoded data 2>
Connection: close
What defenders need to look for is twofold. First, in ‘encoded data 1’, normal traffic will look like ‘%3a<xxx>%2c<xxx>’ in request logs. Malicious traffic will be missing the ‘%2c’ encoding and everything after it. This will trigger bug 2 mentioned above, specifically a part where the login code uses that missing data to encode input to the session file. The missing validation is part of what enabled threat actors to write arbitrary data to the session file.
The second indicator to monitor within web access logs is ‘encoded data 2’. That part will be base64 encoded data, which when decoded, will normally contain a password. Malicious traffic will contain text with newlines and key value pairs. When present, that anomalous content is the malicious payload that will get injected into the session file, bypassing normal authorization and creating a fake session. The example inject that watchTowr demonstrated is as follows:
x\r\n
hasroot=1\r\n
tfa_verified=1\r\n
user=root\r\n
cp_security_token=/cpsess9999999999\r\n
successful_internal_auth_with_timestamp=1777462149
Another necessary step is the ‘successful_internal_auth_with_timestamp’ line included in the payload above, as this inject is required to force the code to process the exploit. Malicious traffic will have a timestamp related key/value pair included.
How Beazley Security is responding
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.