cPanel’s CVE-2026-41940: an auth bypass that skips MFA on 1.5 million servers

If you run websites on shared hosting, there is a good chance the control panel behind them is cPanel and WHM, and there is now a critical reason to check its version. CVE-2026-41940 is an authentication bypass in cPanel, WHM and WP Squared rated CVSS 9.8, and it lets an unauthenticated attacker walk past the login, multi-factor prompt included, to reach administrative access. Worse, attackers were seen exploiting it since 23 February, months before many operators even knew it existed, and a public proof-of-concept is now circulating. With roughly 1.5 million servers running cPanel, this is a broad, ugly problem.

How the bypass works

The flaw is a CRLF injection in the login and session-loading logic. Before authentication even happens, the cPanel service daemon, cpsrvd, writes a session file to disk. The vulnerability lets an attacker manipulate the whostmgrsession cookie by omitting an expected segment of its value, which sidesteps the encryption normally applied to attacker-supplied data. In practice it combines two weaknesses: a CRLF injection in Basic Auth password processing that lets the attacker inject arbitrary key-value pairs into the server-side session store, and a race condition in how cPanel stores session data in both a raw text file and a JSON cache.

The attacker-injected data survives that race window and gets trusted by the authentication layer. The net effect is blunt: password verification and multi-factor authentication can both be bypassed, and the attacker lands with administrative access to WHM. From there they own the host, its configuration, its databases, and every website it manages. On shared hosting that is not one site at risk but every tenant on the machine.

Why hosting panels are such a prize

A control panel is a master key. It does not guard one application; it guards all of them, plus the mail, the databases, the DNS and the file store underneath. That concentration of power is convenient for administrators and irresistible to attackers. One bypass turns into full control of dozens or hundreds of sites, which is exactly the leverage a criminal wants for mass defacement, malware injection, spam operations or data theft.

The timeline makes this one especially nasty. Exploitation was observed since late February, likely earlier, which means many servers may already have been touched long before the patch conversation started. When a bug is exploited quietly for months and then a public exploit drops, the risk profile changes overnight: opportunistic scanning follows the PoC within hours, sweeping the internet for anything still unpatched.

If you rent hosting rather than run it

Not everyone affected operates their own cPanel server; many simply rent space on one. If that is you, the vulnerability is still your problem, because your site lives on a machine you do not patch. The practical move is to press your hosting provider for a straight answer: has this specific CVE been patched, and when? A vague “we take security seriously” is not an answer. Ask about the exploitation window too, since a server compromised in the spring may have had client data or credentials taken long before any patch went on. Where you can, rotate the passwords and API keys you use with the host, and check your own sites for injected content, unfamiliar admin users and unexpected files. You cannot fix the panel yourself, but you can limit what a compromise of it costs you.

Why multi-factor did not help

The most unsettling part of this flaw is that it walks straight past multi-factor authentication, and it is worth understanding why. MFA protects the login process, but this bypass never really logs in. It manipulates the session store directly, planting a trusted session before authentication runs, so the code that would demand a second factor is simply never reached. That is a useful reminder that MFA is a control on one specific path, not a shield draped over the whole application. When a bug lets an attacker forge the very state that authentication is supposed to produce, the strength of your login prompt becomes irrelevant. Defence in depth exists precisely for the day a single control is bypassed, and this is that day.

What to do now

• Update cPanel and WHM to a patched build immediately. If you rely on a hosting provider, confirm in writing that they have patched, do not assume it.
• Assume prior compromise given the long exploitation window. Look for unfamiliar WHM users, unexpected sessions, new cron jobs, modified files and injected content across hosted sites.
• Rotate credentials broadly: WHM and cPanel accounts, API tokens, database passwords and any secrets that lived on the host. A bypass this old means secrets may already be gone.
• Bring in outside eyes. A source code review of what runs on the host and continuous vulnerability management catch both the injected surprises and the next critical patch before it is weaponised.

The takeaway for anyone on shared hosting

Authentication bypass is the quietest kind of catastrophe: no crash, no obvious break, just an attacker holding the same keys you do. When the bypass sits on a control panel that governs every site on a server, the blast radius is the whole machine and everyone on it. Patch now, hunt for what may already have happened, and rotate the secrets that could have leaked. Because stolen credentials tend to surface in dumps before they are used at scale, dark-web monitoring gives you early warning that yours are circulating, and managed detection and response shortens the gap between a suspicious login and a contained incident. If you host client sites and are not certain every panel is patched, get in touch and make certain before the next scan does it for you.