CRITICAL: cPanel Authentication Bypass CVE-2026-41940 Exploited Against MSPs and Government Targets

If you run cPanel anywhere in your stack, stop reading this article, log into your servers, and check your version. Then come back. Because CVE-2026-41940 is exactly the kind of vulnerability that ruins quarters, and right now somewhere between forty thousand IP addresses and a handful of nation-state operators are scanning the internet for unpatched hosts.

The flaw is a pre-authentication bypass in cPanel and WebHost Manager that earns a CVSS score of 9.8, which puts it a hair below the maximum severity rating in the Common Vulnerability Scoring System. CISA added it to the Known Exploited Vulnerabilities catalog on April 30, 2026, which is bureaucratic shorthand for "people are getting popped right now, patch immediately." The vendor shipped fixed builds on April 28, but evidence pulled together by researchers at Ctrl-Alt-Intel and watchTowr suggests active exploitation began as early as February 23, more than two months before anyone outside the attacker community had a name for it.

Here is how it works in practical terms. The cpsrvd daemon, the long-running process that handles the cPanel and WHM web interfaces on ports 2083 and 2087, has a session-loading routine that writes session state to disk before the authentication flow finishes verifying the user. An attacker who sends a basic authorization header containing raw carriage return and line feed bytes can inject arbitrary key-value pairs into the resulting session file, including the trivially abusable user=root field. A second request with the manipulated session cookie reloads that file, and suddenly the attacker is the root user of the server. No password required. No clever timing tricks needed. CRLF injection is a textbook 2007-era class of bug, the kind nobody finds anymore because developers and frameworks learned to sanitize control characters two decades ago. Apparently nobody told cpsrvd.

The blast radius is enormous because cPanel runs almost everywhere a small or midsize business hosts a website, an email server, or a database. Every version released after 11.40 is affected, which covers more than a decade of installs. The fixed branches are 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, and 11.136.0.5, with WP Squared customers needing 136.1.7 or later. If your version string is older than the corresponding fix on that list, you are exposed. If you have port 2083 or 2087 reachable from the public internet, you are not just exposed, you are very likely already being scanned. Honeypot data captured on April 30 logged roughly 44,000 distinct source IPs hammering the management plane, and that was before the patch even had a chance to land in most production environments.

Who is doing the hammering matters too. The Ctrl-Alt-Intel writeup attributes one of the more interesting clusters to a previously unknown actor that has been working its way through Southeast Asian government and military infrastructure. In the Philippines and Laos, the operators used the cPanel foothold as a beachhead before pivoting through internal networks with OpenVPN, Ligolo, and a sprinkling of systemd services for persistence. The same campaign reportedly chained the bug with a custom zero-day against an Indonesian defense portal and walked out with more than four gigabytes of sensitive Chinese railway documentation, which is the sort of detail that tells you this is not a kid in a basement. A second, noisier set of attackers operating from IP 95.111.250.175 has been deploying the AdaptixC2 framework against managed service providers and hosting companies in the Philippines, Laos, Canada, South Africa, and the United States, again using OpenVPN and Ligolo to maintain access after the initial compromise. Predictably, the Mirai operators showed up to weaponize the bug for botnet expansion within twenty-four hours of public disclosure, with at least one ransomware crew dropping a strain called Sorry on whatever hosts were not interesting enough for the more targeted actors.

If you are an MSP, a hosting provider, or a security team responsible for any cPanel environment, the response order is straightforward even if the work is unpleasant. Start with the patch. The vendor releases were available before the public disclosure, and most cPanel installations support the upcp utility for in-place upgrades. Run it now. Do not wait for your next maintenance window. If you genuinely cannot patch immediately because of an application compatibility test, restrict access to ports 2083 and 2087 to known administrative IP ranges, but treat that as a stopgap rather than a fix. Several providers tried port blocking as a workaround and discovered that some attacker tooling reaches the daemon through proxies or chained access that does not respect their network access control lists. Patching is the only durable solution.

Next, assume compromise on anything that was reachable from the internet between February 23 and the moment your patch landed. Hunt for new local accounts, especially those with shells and sudo privileges. Look for systemd services you do not recognize, and read the unit files rather than just listing the names. Search for OpenVPN and Ligolo binaries that did not come from your package manager. Review the cPanel session directory for files with timestamps that predate your patch and contain user=root entries that should not exist. Pull authentication logs and look for successful logins from cookie material rather than credentials, paying special attention to anything originating from 95.111.250.175 or unusual hosting provider ranges. WatchTowr and Ctrl-Alt-Intel both published indicators of compromise that are worth ingesting into your SIEM if you have one, and worth grepping through with awk if you do not.

Then rotate credentials. Anything an attacker with root could have touched, which is to say everything, should be considered burned. API keys for downstream systems, database passwords, SSH keys stored in admin home directories, two-factor backup codes, billing system credentials, and customer cPanel passwords if you suspect lateral movement into hosted accounts all need to roll. This is grunt work, and it is also the difference between an embarrassing patching cycle and a regulator-attracting incident.

For the MSPs reading this, and ThreatForge knows that is most of you, this is one of those rare moments where a vulnerability in an upstream product creates an obvious commercial conversation with your customers. Every business that has a cPanel-fronted website or email server is now a candidate for an emergency patching engagement, a managed compromise assessment, and probably a follow-on conversation about why their hosting provider does not include this kind of work as a baseline. Pair the technical response with a darkweb monitoring service to detect leaked credentials and a threat protection tier that watches for cookie reuse and impossible travel, and you have a three-line proposal that practically writes itself. The MSPs who acted within twenty-four hours of the CISA listing already had those conversations on Friday. The ones who wait until next week will be having them anyway, but from a less flattering position.

The broader lesson here is the one we keep relearning. Internet-exposed administrative interfaces are catnip for adversaries, and panel software whose authentication code has not been seriously audited since the early 2010s is a category-wide risk, not a one-vendor problem. The same energy that drove the Citrix Bleed, Fortinet, and Ivanti cycles is now pointed at cPanel, and there is no reason to believe Plesk, ISPConfig, Webmin, and the rest of the long tail are any safer. If your standard build still permits direct internet access to port 2083, this is the week to redesign that around a zero-trust gateway, a VPN, or at the very least an allowlist. The patch closes today's hole. The architecture conversation closes the next one.