cPanel Authentication Bypass Added to CISA KEV

Published: May 1, 2026

Remote management planes are having a bad week.

Two days after CISA added ConnectWise ScreenConnect to the Known Exploited Vulnerabilities catalog, the agency added another management interface: CVE-2026-41940, a critical authentication bypass in cPanel and WebHost Manager (WHM). This one carries a CVSS score of 9.8, has 16 public proof-of-concept exploits on GitHub, and was being actively exploited in the wild for months before anyone issued a patch.

This is not a vulnerability that defenders can defer. This article covers what happened, why cPanel is such a high-value target, and what administrators should do right now.

The Threat at a Glance

Threat Type Critical authentication bypass allowing unauthenticated remote attackers full administrative access to cPanel and WHM control panel environments
Severity Critical — CVSS 9.8; confirmed in-the-wild exploitation since at least February 2026; 16 public PoC exploits available
Affected Products cPanel and WHM, including DNSOnly, all versions after 11.40; WP Squared versions up to and including 136.1.7
CVE CVE-2026-41940
KEV Added April 30, 2026
Patch Available Yes — update via the standard cPanel update script; verify the build version and restart cpsrvd
Federal Remediation Deadline Binding Operational Directive 22-01 applies; check the CISA KEV catalog for the exact deadline
High-Risk Environments Shared hosting providers, MSPs, web agencies, and any organization running self-managed cPanel or WHM instances
Primary Detection Surface cPanel session files, WHM access logs, and the cPanel-provided IoC detection script
Exposure Approximately 1.5 million cPanel instances exposed on the internet according to public exposure datasets; exact number of vulnerable systems is unknown

Why cPanel Is a High-Value Target

cPanel and WHM are among the most widely deployed web hosting control panels on the internet. cPanel provides the user-facing interface for managing hosted websites, email, databases, and files. WHM sits above it, giving hosting providers and administrators root-level control over multiple cPanel accounts on a single server.

That layered administrative model is what makes it so valuable to attackers. A compromised cPanel account gives access to one website and its data. A compromised WHM instance gives access to every cPanel account the server hosts — all the websites, all the databases, all the configurations, and all the credentials stored within them.

For shared hosting environments and MSPs managing infrastructure on behalf of clients, the blast radius extends further. A single vulnerable WHM server can become a pivot point into dozens or hundreds of customer environments simultaneously.

CVE-2026-41940 is a missing authentication vulnerability in the cPanel login flow. The technical root cause is a CRLF injection flaw in how the cPanel service daemon, cpsrvd, writes session files before authentication is complete. An attacker can manipulate the whostmgrsession cookie to bypass the encryption process applied to session values, inject arbitrary properties into the session file, including user=root, and trigger a reload of that session to establish administrator-level access without providing valid credentials.

No account. No password. No MFA. If exploitation succeeds, the attacker can reach administrator-level access through the control panel itself.

The patch was released April 28, 2026. The exploitation started no later than February 23 — over two months earlier.

The Disclosure Timeline Is Worth Noting

The circumstances around how this vulnerability came to light are relevant context for anyone thinking about vulnerability disclosure and vendor response.

According to reporting from webhosting.today, the vulnerability was reported to cPanel approximately two weeks before the April 28 public advisory. The initial response from cPanel was that nothing was wrong. The vulnerability was already being exploited in the wild at that point.

WatchTowr Labs subsequently published a detailed technical analysis and proof-of-concept on April 29, the day after the patch was released. Within hours, 16 PoC implementations had appeared on GitHub. The combination of a management-plane target, unauthenticated exploitation, and an immediately available PoC created exactly the conditions that drive rapid attacker opportunism.

Hosting provider KnownHost’s CEO noted that in the cases reviewed on their network, exploitation attempts appeared to be reconnaissance-level — attackers testing access rather than immediately deploying payloads. That pattern is consistent with the early stages of widespread opportunistic scanning, not the final stage. It does not mean compromised systems are safe.

Immediate Response: What to Do Now

Step 1 — Patch immediately

Update cPanel and WHM to a patched version using the standard update script:

/usr/local/cpanel/scripts/upcp

After updating, verify the installed build version confirms the patch is applied and restart the cPanel service, cpsrvd. For WP Squared environments, update to a version beyond 136.1.7.

Servers with disabled automatic updates or versions pinned for operational reasons will not receive the patch automatically. These systems must be manually updated as a priority.

Step 2 — Block management ports if patching is delayed

If immediate patching is not possible, block inbound traffic to cPanel and WHM management ports at the firewall as a temporary measure:

  • Port 2083 — cPanel SSL
  • Port 2087 — WHM SSL
  • Port 2095 — Webmail SSL
  • Port 2096 — Webmail SSL alternate

Stopping the cpsrvd and cpdavd services provides additional isolation. This is a compensating control, not a substitute for patching.

Step 3 — Run cPanel’s IoC detection script

cPanel has provided a detection script that scans session files in /var/cpanel/sessions for indicators of compromise. Administrators should run this against any potentially exposed instance before and after patching.

The script flags:

  • Session files containing both token_denied and cp_security_token, a strong indicator of exploitation attempts
  • Pre-authentication sessions containing authenticated attributes
  • Sessions marked with tfa_verified but lacking legitimate origin markers
  • Multi-line password values indicating possible session file manipulation

Instructions for obtaining and running the script are included in the cPanel security advisory.

Step 4 — Review WHM access logs

Examine WHM access logs for unusual authentication events, especially successful logins from unfamiliar IP addresses, unexpected geographic locations, or accounts that do not correspond to known administrators. Pay particular attention to activity between February 23 and the date patching was confirmed. That is the known exploitation window.

Step 5 — Rotate credentials and check for persistence

If the IoC script or log review indicates potential compromise, treat all root and WHM credentials as compromised. Rotate them immediately.

Then look for persistence mechanisms that would survive a password reset:

  • New administrative accounts
  • SSH keys added to authorized_keys
  • New or modified cron jobs
  • Webshells in web-accessible directories
  • Unfamiliar services or startup items

Step 6 — Notify downstream clients if applicable

For MSPs and hosting providers managing infrastructure on behalf of clients, a compromised WHM instance is a shared risk. If exploitation cannot be ruled out, downstream clients should be informed and their hosted environments should be reviewed for signs of unauthorized access or modification.

What Defenders Need to See

Detection of exploitation for this vulnerability focuses on two distinct questions: was the vulnerability exploited before patching, and does the environment show signs of post-exploitation activity?

Session file analysis is the most direct signal. The cPanel IoC script was built for this. Run it. The session manipulation technique at the core of CVE-2026-41940 leaves specific artifacts in /var/cpanel/sessions that legitimate authentication does not produce.

WHM access logs provide the timeline. Successful WHM logins from unexpected sources during the exploitation window are the clearest post-authentication signal that an attacker established access. Correlate those login events against known administrator IP addresses and expected usage patterns.

File system changes on the hosting server warrant close review if session or log analysis suggests compromise. Attackers who gain root-level WHM access can make changes anywhere on the system. Webshell deployment, new cron entries, SSH key additions, and unauthorized account creation are the persistence patterns most commonly observed following management-plane compromise.

Hosted website integrity should also be considered. A WHM-level compromise gives an attacker access to every website the server hosts. If compromise is suspected, check hosted sites for unauthorized file modifications, injected scripts, or defacements.

Defensive priority:

Do not stop at patch verification. For this vulnerability, administrators need evidence that the system was not accessed before the patch was applied.

The Management Plane Pattern

This KEV addition arrives two days after CISA added ConnectWise ScreenConnect to the same catalog. Both are management-plane targets. Both carry high severity scores. Both were being actively exploited before widespread awareness. The pattern is worth naming explicitly.

Management interfaces — control panels, remote access platforms, administrative portals — represent some of the highest-value targets in any infrastructure. They exist to provide centralized, privileged control. When attackers reach them, they do not need to move laterally host by host. They inherit the administrative reach the tool was designed to provide.

This is why the management plane deserves a distinct place in any organization’s threat model. Not just as a category of software to patch, but as a category of infrastructure to monitor, baseline, and treat with the same scrutiny applied to identity and endpoint security.

For context on how the KEV catalog should inform vulnerability prioritization decisions, see Patch Tuesday and KEV: Prioritizing Real Risk.

For the ScreenConnect KEV coverage published two days ago, see ScreenConnect in KEV: The RMM Lateral Movement Risk.

Conclusion

CVE-2026-41940 is a straightforward patching priority. The fix exists, it is available now, and the exploitation window has been open for months. There is no ambiguity about whether this vulnerability is being actively used.

The harder question is what happened before the patch. Two months of exploitation against a management interface used to control millions of hosted environments is a significant window. Administrators who run cPanel and WHM should not assume their systems were unaffected just because no obvious incidents surfaced. The session IoC script and WHM log review are the tools to answer that question with evidence rather than assumption.

Patch. Review. Rotate credentials if there is any doubt.

References & Original Sources

Support independent security analysis

If you find ByteVanguard useful, you can support the site and help keep the analysis independent.

Support the analysis
Intelligence over headlines. Signal over noise.

Stay Connected

Report Intelligence
© 2026 ByteVanguard. Built for security professionals.