cPanel Authentication Bypass CVE-2026-41940 Gave Attackers 64 Days of Root Access

For 64 days, attackers had root access to cPanel servers managing over 70 million websites, and nobody had to know a single password to get in. A crafted HTTP request was enough, and two-factor authentication made no difference. The company behind the software was told about it two weeks before the patch dropped. Their first response was that nothing was wrong.

Whoever gets in walks away with root access to the entire server through WHM: the hosted sites, the databases behind them, the email accounts, the certificates, and every credential stored on that machine. With that level of access, someone can read every hosted account, modify files and databases, create permanent backdoor accounts, install malware, steal credentials, and potentially pivot from there into customer networks. Compromising one cPanel server does not mean compromising one website. It means compromising everyone sharing that machine.

cPanel and WHM are the web-based control panels that most shared hosting providers use to manage their servers and give customers a way to control their websites, email accounts, and databases without touching the command line. cPanel is the customer-facing interface. WHM, which stands for Web Host Manager, sits above it and gives hosting providers root-level control over the entire server, including every customer account on it. According to W3Techs, cPanel is the most widely deployed web hosting control panel in the world. Rapid7 ran a Shodan scan and found approximately 1.5 million cPanel instances directly reachable from the internet. Every one of them running a version after 11.40 was affected, and version 11.40 is old enough that practically every active installation fell inside that range.

The first confirmed exploitation attempts were logged on February 23, 2026. KnownHost CEO Daniel Pearson stated publicly that his company had seen execution attempts as early as that date and that the vulnerability had been used in the wild for at least 30 days before any disclosure. The public advisory came on April 28, 2026. The vulnerability was formally assigned CVE-2026-41940 the following day, with a CVSS score of 9.8 out of 10. Webhosting.today reported that the vulnerability had been flagged to cPanel roughly two weeks before that date, and that cPanel’s initial response was that nothing was wrong.

The patch arrived 2 to 3 hours after the advisory. The attackers had a 64-day head start.

The technical details came to light through watchTowr researcher Sina Kheirkhah, who went looking for the answer the same way most serious vulnerability research starts: by comparing what changed. When cPanel pushed the emergency patch, Kheirkhah pulled both the old and the patched version of the code and looked at the differences. Three files had been modified: Cpanel/Session.pm, Cpanel/Session/Load.pm, and Cpanel/Session/Encoder.pm. Inside Session.pm, one change stood out. A function called filter_sessiondata had been moved. It had always existed in the codebase, always designed to strip dangerous characters from session data, but it was not being called from inside saveSession, the function that actually writes session files to disk. From that single observation, Kheirkhah worked backwards to the full exploit.

When cPanel processes a login attempt, the component responsible is called cpsrvd, the cPanel service daemon. This is the process that manages sessions and controls access to the panel. When a login attempt fails, cpsrvd does not just reject the request and move on. Before it checks whether the credentials are correct, it creates a temporary file on the server called a pre-authentication session file. Session files are how cPanel tracks request state across multiple connections. This pre-authentication file gets written to disk at a path like /var/cpanel/sessions/raw/ and stores things like the originating IP address, an assigned security token, and whether two-factor authentication has been verified.

The format of that file is simple. One property per line, written as key=value:

1
2
3
4

local_ip_address=172.17.0.2
needs_auth=1
tfa_verified=0
ip_address=172.17.0.1

The attack relies on something called CRLF injection. CRLF stands for Carriage Return and Line Feed, two invisible control characters written in code as \r\n. On most systems, \r\n signals the start of a new line. In a session file where each line is a separate key-value property, injecting \r\n creates a new property. If an attacker can get those characters into values being written to that file, they can insert properties that were never supposed to be there, including user=root.

cPanel had a function called filter_sessiondata specifically designed to strip out \r\n characters and prevent exactly this kind of injection. The function existed in the codebase. It just was not being called from inside saveSession, the function that writes session files to disk. Every code path calling saveSession was expected to run filter_sessiondata first. One code path inside cpsrvd never did.

A second problem made it worse. When the session cookie is sent without its per-session encryption secret, cpsrvd skips the encoding of the password field entirely and writes it to the session file as raw plaintext. That combination, unsanitized input and no encoding, gave attackers a clean path to write anything they wanted into the session file.

The attacker first sends a failed login to trigger creation of the pre-authentication session file and get back a session cookie:

1
2
3
4
5

POST /login/?login_only=1 HTTP/1.1
Host: target:2087
Content-Type: application/x-www-form-urlencoded

user=root&pass=wrong

The response comes back as 401 Access Denied with a cookie that looks like this:

1

Set-Cookie: whostmgrsession=:Wg_mjzgt1hyfXefK,1bd3d4bf5ecbf83b660789ab0f3198fa

That cookie has two parts separated by a comma. The value after the comma is the per-session encryption secret. In the next request, the attacker sends the cookie back without that secret. With the encryption key gone, cpsrvd skips encoding and writes the password field as plaintext. The attacker loads that password field with \r\n-separated fake session properties:

1

Authorization: Basic [Base64 of: root:x\r\nhasroot=1\r\ntfa_verified=1\r\nuser=root\r\ncp_security_token=/cpsess999999999]

When cpsrvd writes the session file and reloads it, it reads user=root, hasroot=1, and tfa_verified=1 as legitimate session properties. The session is now a fully authenticated root session. Two-factor authentication is marked as already verified. No password was ever checked.

Within hours of the advisory going public, Namecheap, KnownHost, HostPapa, InMotion, and hosting.com all blocked access to cPanel and WHM ports across their own infrastructure. They locked their own customers out of their own control panels because the alternative was watching the entire customer base get compromised in real time. Namecheap had the patch applied by April 29 at 02:42 UTC. The U.S. Cybersecurity and Infrastructure Security Agency added CVE-2026-41940 to its Known Exploited Vulnerabilities catalog on April 30, 2026, with a deadline of May 21 for all federal civilian agencies to apply the fix.

On April 29, watchTowr published a full technical breakdown of the vulnerability along with a working proof-of-concept exploit. With a public exploit available and automated detection templates already built around it, the gap between disclosure and mass exploitation has closed. Anyone with a Shodan query and the PoC can scan and hit 1.5 million exposed instances. If you have not patched yet, assume scanning is already hitting your server.

The patch moved filter_sessiondata into saveSession directly, so sanitization happens automatically regardless of which code path calls the function, and added proper handling for when the per-session encryption key is missing. A function that already existed for years just needed to be called from the right place.

If you manage a cPanel or WHM server, run through these steps:

• → Check your current version: cat /usr/local/cpanel/version
• → Update immediately: /scripts/upcp --force
• → Restart the cPanel service after updating: /scripts/restartsrv_cpsrvd
• → If patching right now is not possible, block these ports at the firewall: 2083, 2087, 2095, and 2096
• → Stop the cpsrvd and cpdavd services if blocking ports is not an option
• → Run cPanel’s official IOC detection script to check whether the server was accessed before the patch

The patched versions for each release track:

1
2
3
4
5
6
7
8

11.86.0.x   →  11.86.0.41
11.110.0.x  →  11.110.0.97
11.118.0.x  →  11.118.0.63
11.126.0.x  →  11.126.0.54
11.130.0.x  →  11.130.0.19
11.132.0.x  →  11.132.0.29
11.134.0.x  →  11.134.0.20
11.136.0.x  →  11.136.0.5

WP Squared users need version 136.1.7 or later.

If the server was running an unpatched version, cPanel released an official script that scans for signs of compromise. The two main things to look for are a pre-authentication session file that already contains user=root or similar authenticated properties, and sessions where a login was rejected but an authenticated security token was still written. WatchTowr also released a Detection Artifact Generator on their GitHub that checks whether a host is still vulnerable.

The function that would have stopped all of this already existed in the codebase. filter_sessiondata was written, tested, and in place for years. It just was not being called from the right location inside saveSession. The patch took 2 to 3 hours to write and ship after the advisory went out. The exploitation window was 64 days. That window opened the day a researcher reported the issue to cPanel and got back the response that nothing was wrong.

How attackers move through session handling, cookie manipulation, and every stage of a login process before it even completes is covered step by step in my ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: cPanel Official Advisory · watchTowr Labs · Rapid7