How to protect your cPanel/WHM server from CVE-2026-41940 (authentication bypass)

What is CVE-2026-41940?

CVE-2026-41940 is a critical authentication bypass vulnerability in cPanel & WHM (including DNSOnly) and WP Squared, with a CVSS score of 9.8. It was disclosed on April 29, 2026, and the official patch was released on April 28, 2026.

It is a CRLF injection flaw in the handling of the whostmgrsession cookie. A remote, unauthenticated attacker can inject CR/LF characters into basic authorization headers, bypass session encryption, and write arbitrary properties (for example user=root) into the session file. The result: full root access to WHM.

It is being actively exploited and a public proof-of-concept exists. If your WHM is internet-exposed and unpatched, treat the server as potentially compromised until you verify otherwise with the detection script at the bottom of this article.

Are you affected?

Yes, if you run cPanel & WHM 11.40 or later unpatched, or any vulnerable version of WP Squared.

Versions containing the fix:

  • cPanel & WHM: 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, 11.136.0.5
  • cPanel & WHM on CentOS 6 / CloudLinux 6 (110.0.50 branch): 11.110.0.103 as a direct update
  • WP Squared: 136.1.7

How to check your installed version

/usr/local/cpanel/cpanel -V

Compare the output to the list above. If your version is lower within the same branch, you are vulnerable.

How to mitigate

Option Best for Durable?
Upgrade cPanel & WHM Everyone, definitive fix Yes
Block ports externally While you schedule the upgrade Temporary
Stop cpsrvd and cpdavd If you cannot upgrade or filter ports Temporary

Option A: upgrade cPanel & WHM (recommended)

If automatic updates are disabled or your configuration pins a specific version, you must upgrade manually. On CentOS 7 / CloudLinux 7 servers, set the supported tier first:

whmapi1 set_tier tier=11.110

On CentOS 6 / CloudLinux 6 servers running 110.0.50:

whmapi1 set_tier tier=11.110.0.103

Run the upgrade and restart cpsrvd when done:

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

Option B: block cPanel/WHM ports (temporary workaround)

Block inbound traffic on ports 2083, 2087, 2095, and 2096 at the firewall until you apply the patch. Example with firewalld restricting access to a known administrative IP:

for p in 2083 2087 2095 2096; do
  firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=YOUR_ADMIN_IP port port=$p protocol=tcp accept"
  firewall-cmd --permanent --add-rich-rule="rule family=ipv4 port port=$p protocol=tcp drop"
done
firewall-cmd --reload

Option C: stop cpsrvd and cpdavd

If you cannot filter ports, disable and stop the affected services:

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && \
whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && \
/scripts/restartsrv_cpsrvd --stop && \
/scripts/restartsrv_cpdavd --stop

This takes WHM, cPanel, and webdav offline. It is an emergency stopgap until you can upgrade.

Detect indicators of compromise

cPanel published a script that scans session files in /var/cpanel/sessions/ for exploitation indicators. Download it from the attached file at the bottom of this article and run it as root:

/bin/bash ./ioc_checksessions_files.sh

The script classifies findings into four severity tiers:

  • CRITICAL: confirmed exploitation artifact (injected session promoted to authenticated). Treat the server as compromised.
  • WARNING: suspicious session with inconsistent markers. Investigate manually.
  • ATTEMPT: failed exploitation attempt (no session promotion). The server was likely not compromised by this attempt, but confirm with log auditing.
  • INFO: minor anomaly, usually no compromise.

For a full dump of each suspicious session, add --verbose. To purge affected sessions after review: --purge --yes.

Exit codes: 0 no findings, 1 only ATTEMPT/INFO, 2 at least one CRITICAL or WARNING.

If the script reports CRITICAL or WARNING findings:

  1. Purge all sessions (this forces all users to log in again):
    rm -f /var/cpanel/sessions/{cache,preauth,raw}/*
  2. Force password reset for root and all WHM users.
  3. Audit /var/log/wtmp, /usr/local/cpanel/logs/access_log, and /usr/local/cpanel/logs/login_log for unauthorized access.
  4. Look for persistence mechanisms: new cron jobs, added SSH keys, suspicious binaries.
  5. If you confirm a root-level compromise, migrate accounts to a clean server or reinstall the OS and restore from backups.

After mitigating

  1. Confirm the version with /usr/local/cpanel/cpanel -V.
  2. Run the detection script at least once after upgrading.
  3. Rotate sensitive credentials (root, MySQL, API tokens) if your WHM was internet-exposed and unpatched at any point before April 28, 2026.

Need help?

Open a ticket at soporte.telecu.cloud and reference: CVE-2026-41940.

Sources

Attached Files
ioc_checksessions_files.sh
404kb
Tags