High Fidelity Check for the cPanel Authentication Bypass (CVE-2026-41940)

Less than 24 hours ago, an advisory was released for a complete authentication bypass in cPanel. Successful exploitation allows an unauthenticated attacker to get a login session of any user, including the all-powerful root user via WHM.

We have seen PoCs and detections proliferate over Github in the rush to both exploit and defend against the new vulnerability. These PoCs can work, but all of them miss nuances that result in a lot of false negatives; that is, the scanning mechanism used will report targets are not vulnerable when in fact they are. At a time when accuracy and clarity are critical, we are publishing additional information about common security and configuration aspects of cPanel that thwart naive scanning, as well as how to write checks that are more accurate.

If you want to use our high fidelity scanning technique, we’ve open sourced our scanner, which can be found here: https://github.com/assetnote/cpanel2shell-scanner

The Architecture

The typical cPanel installation has many ports open for various services, but the two services that we are concerned with are the ones vulnerable to the bypass:

• The cPanel service itself, which is exposed on port 2082 (HTTP) and 2083 (HTTPS).
• The WHM service, which is exposed on port 2086 (HTTP) and 2087 (HTTPS).

A lot of PoCs floating around assume that if those ports are closed, the website is not vulnerable. However, cPanel provides another mechanism to access the control panel. For each virtual host handled by cPanel, say example.com, the following Apache config is used:

RewriteCond %{HTTP_HOST} =whm.example.com [OR]
RewriteCond %{HTTP_HOST} =whm.example.com:443
RewriteRule ^/(.*) /___proxy_subdomain_whm/$1 [PT]
ProxyPass "/___proxy_subdomain_whm" "http://127.0.0.1:2086" max=1 retry=0

A similar scenario is true for cpanel.example.com and /___proxy_subdomain_cpanel.

Even though the RewriteCond requires that the subdomain be whm.example.com, the ProxyPass happens regardless of the subdomain. This means that even with the management ports inaccessible, accessing /___proxy_subdomain_whm/login on any vhost is enough to reach the management panel. Simply closing or firewalling the management ports is not sufficient to protect against the vulnerability, and scanners that don’t check for these magic paths will miss vulnerable instances.

The Usernames

Both the WHM service and the cPanel service go through cpsrvd.pm, but they both have slightly different behavior. There is one particular check which will foil exploitation attempts:

$user = $server_obj->auth->set_user($user);
$pass = $server_obj->auth->set_pass($pass);
_set_team_user($server_obj, $user);
if (not _validate_username($user) or $Cpanel::App::appname eq 'cpaneld' and not -f '/var/cpanel/users/' . $user) {
    $server_obj->badpass('faillog', 'user name not provided or invalid user');
}

When accessing cPanel through the cPanel ports 2082 and 2083, $Cpanel::App::appname eq 'cpaneld' is true, and so it checks that the cPanel user exists with -f '/var/cpanel/users/' . $user. Unlike WHM, cpaneld requires the supplied username to correspond to an existing cPanel hosting account on disk; root is a system user, not a cPanel user, so it never matches. So trying the exploit with just root will almost never identify the vulnerability on port 2083. We are not aware of any pre-authentication mechanisms that leak valid users in cPanel, so proper scanning will require a wordlist of common usernames for use on port 2083.

The Hulk

cPanel, being a production webpanel used millions of times, has a robust set of anti abuse and access control mechanisms. There are two in particular that interfere with scanning.

The first is called cphulkd; it is an anti-abuse mechanism that locks out accounts that have too many failed password attempts. Since the first step of the exploit is necessarily to send a login request with an invalid password, each scan will cause a password failure which will send the account hurtling towards lockout. Once the account has been locked out, for a certain period of time even successful exploitation attempts will result in no access.

The second is called authorized_whm_root_ips. Since root is so often a target, cPanel provides a commonly used config option that only allows root logins from certain IPs. This also thwarts detection that only tries the user root.

Our solution to this involves two separate mechanisms:

• On the WHM port, the session injection can be achieved without caring about a specific username. Therefore we make the username completely random, to avoid the lockout.
• Even though the username is random, we could inject user=root into the session. Due to Perl’s hash ordering this would result in access 50% of the time, with the other 50% resulting in a session for a user which doesn’t exist (which grants no access). We came up with a better solution: by injecting expired=1 into the session instead, we can test the session injection works with no mess. Visiting the login page with an injected session will have the page contain msg_code:[expired_session], which is a strong indicator our injection worked, without having to worry about the root restrictions or invalid usernames.

You can see the code for this logic here: https://github.com/assetnote/cpanel2shell-scanner

Conclusion

Customers of Searchlight Cyber’s ASM solution, Assetnote, received a notification of this vulnerability across their entire attack surface earlier today via this high-fidelity check. Searchlight Cyber’s Security Research Team continues to dig beyond public PoCs to bring high-quality, high-signal checks to its customers.