Critical cPanel/WHM/WP2 Vulnerability — CVE-2026-41940 (Authentication Bypass)

An unauthenticated remote attacker can bypass authentication and gain administrative access to cPanel/WHM, including every site the server hosts. cPanel has issued an emergency security update, and BinaryLane is observing active exploitation against cPanel servers on our network. Patch every cPanel/WHM/WP2 server you operate today.

⚠️ Critical — Active Exploitation: This is a CVSS 9.8 authentication-bypass vulnerability with confirmed in-the-wild exploitation. If you operate a cPanel/WHM/WP2 server on BinaryLane, treat this as a same-day operational priority.

At a glance

Read this article if you operate any cPanel, WHM, DNSOnly, or WP2 server on BinaryLane. This affects unmanaged VPS customers running cPanel.

ℹ️ cPanel's advisory is a moving target: The official cPanel advisory has been updated several times since first publication and may be updated again. After working through this article, please check the cPanel advisory for the most current detection script and any new guidance.

Table of Contents

• Step 1 — Check whether you're patched
• Step 2 — Apply the patch
• Special cases (CentOS 6/7, pinned versions, very old builds)
• If you can't patch within hours — mitigations
• Step 3 — Check for prior compromise
• What BinaryLane is doing
• If your server has already been compromised
• Need help
• References

Step 1 — Check whether you're patched

SSH into your cPanel server as root and run:

/usr/local/cpanel/cpanel -V

Compare the output to the patched build for your release tier:

If your build is older than the patched version for your tier, you're vulnerable — proceed to Step 2.

⚠️ Even if you're already patched, do not skip Step 3. The exploit predates the patch, and BinaryLane is observing active exploitation. Servers that look fully patched today may have been compromised before the patch existed. cPanel has published a detection script specifically for this purpose — running it is part of completing the response.

Step 2 — Apply the patch

For most servers, three commands are all that's needed. Run on every cPanel host:

# 1. Force the cPanel updater to run immediately
/scripts/upcp --force

# 2. Verify the new version
/usr/local/cpanel/cpanel -V

# 3. Hard-restart cpsrvd to load patched binaries
/scripts/restartsrv_cpsrvd --hard

After the third command, re-check /usr/local/cpanel/cpanel -V against the table in Step 1 to confirm.

Special cases

CentOS 6 / CloudLinux 6 on v110.0.50

cPanel has released v110.0.103 as a direct update path for these end-of-life systems:

whmapi1 set_tier tier=11.110.0.103
/scripts/upcp --force

Then run the verify and restart commands from Step 2.

Auto-updates disabled or version pinned

If you've disabled auto-updates or pinned to a specific version, the standard upcp will not move you forward. You need to manually set the upgrade tier.

On CentOS 7 / CloudLinux 7:

whmapi1 set_tier tier=11.110
/scripts/upcp --force

On other tiers: substitute the tier number from the patched-versions table above into tier=.

For full guidance on managing update preferences from the CLI, see cPanel's article: How to customize cPanel's Update Preferences from the Command Line.

Versions older than 11.86

No patch is currently available. cPanel is working on patching these older tiers but has not committed to a date. You should:

1. Apply the mitigations below immediately
2. Begin planning your upgrade to a supported tier as a priority
3. Re-check the cPanel advisory periodically — they may release back-ports

If you can't patch within hours — mitigations

These are stopgaps, not fixes. Both will degrade or block your customers' access. Apply one only if patching is going to take longer than a few hours.

Option A — Block the cPanel ports at the firewall

Block inbound TCP 2083, 2087, 2095, and 2096. This prevents the exploit reaching the vulnerable service, but also blocks all legitimate cPanel/WHM/Webmail access for your end users.

Option B — Stop cpsrvd and cpdavd

Run as root:

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 stops the vulnerable daemons. cPanel/WHM/Webmail/CalDAV will be offline until you re-enable them.

⚠️ Patch as soon as you possibly can. Mitigations are time-buyers, not fixes.

Step 3 — Check for prior compromise

Because the exploit predates the patch by some weeks, every cPanel server in this version range needs to be reviewed — even if it's now patched. cPanel publishes a bash script (ioc_checksessions_files.sh) that scans /var/cpanel/sessions/raw/ for indicators of compromise. You can copy the script verbatim from the cPanel advisory page under the Detection Script heading.

What the script catches

Run it

Save the script as ioc_checksessions_files.sh (the cPanel advisory has the full source — copy it verbatim, do not retype) and run:

/bin/bash ./ioc_checksessions_files.sh

Clean output ends with [+] No indicators of compromise found. Any line tagged [!] CRITICAL or [!] WARNING warrants investigation.

If the script reports indicators of compromise

cPanel's official guidance:

1. Purge all sessions (forces all users to log in again):

   rm -f /var/cpanel/sessions/{cache,preauth,raw}/*

2. Force a password reset for root and all WHM users — see cPanel's articles How to change the root user's password using WHM and How to force password changes on users.

3. Audit /var/log/wtmp and WHM access logs for unauthorised access.

4. Check for persistence: cron jobs, SSH keys, backdoors, modified system binaries.

If any of those return positive results, treat the server as fully compromised and follow If your server has already been compromised below.

What BinaryLane is doing

To protect the wider network from active exploitation, BinaryLane is traffic-shaping inbound connections to cPanel servers identified as unpatched. Shaping is automatically lifted once we observe your server on a fixed build.

This is a protective measure, not a service suspension — but performance for your end users will be degraded until you update. Patching to the build in Step 2 is the fastest way to have shaping removed.

If your server has already been compromised

If your detection-script run reports indicators, or you know the server has been compromised, do not simply patch and continue. cPanel's official position is that root-compromised servers should not be cleaned in place — they should be migrated to a clean server, or the OS reinstalled and accounts restored from backups.

⚠️ Lock your last clean backup BEFORE doing anything else. BinaryLane Automated Backups operate on a rolling retention window — without action, the oldest (clean) backup will be overwritten by newer (post-compromise) backups within a few days. Once that happens, the clean copy is gone permanently. Open the BinaryLane control panel → server → Backups → Preserve the most recent backup taken before the suspected compromise date.

Recommended recovery sequence

1. Lock your last known-good BinaryLane Automated Backup (see callout above). This is the single most time-critical step.
2. Contain the running threat. Power off the server, or block all inbound/outbound traffic except your own admin IP via the BinaryLane firewall.
3. Recover data via Rescue Mode. Boots a clean Linux environment with your disk attached as a secondary drive, so you can copy /backup/ and /home/*/backups/ to a clean platform without re-entering the compromised OS.
4. Migrate accounts to a clean server, following cPanel's official guidance: How to move all cPanel accounts from one server to another. This is the cPanel-recommended path.
5. Or reinstall the OS and restore from backups, per cPanel: Restore an account from a backup file on the server. Choose this if you'd rather rebuild from scratch on the same hardware.
6. Rotate every credential that touched the old box — SSH keys, root passwords, WHM passwords, MySQL/MariaDB users, application secrets in /etc/, mail account passwords, FTP creds, anything in ~/.aws/ or ~/.config/. Treat the old server's secret material as fully burned.
7. Scan account backups before restoring. cPanel /backup/ tarballs commonly carry the original breach: webshells in document roots, modified PHP files, malicious cron entries, altered .htaccess. Restore into a sandboxed instance first, scan with ClamAV, maldet, or a reputable malware scanner, and review document roots manually.
8. Notify if required. If the compromised server processed personal information, you may have notification obligations under the Australian Privacy Act / Notifiable Data Breaches scheme. Speak to your privacy or legal advisor.

Need help

Reply to the original advisory email or open a ticket via the BinaryLane Customer Portal. Additional support staff are on call today specifically for cPanel customers affected by this CVE.

Treat this as a same-day operational priority.

BinaryLane VPS is an unmanaged service. Our support can:

• Trigger Rescue Mode for you
• Help you locate the Preserve backup action in the control panel
• Apply traffic shaping or remove it once you've patched
• Provide console / VNC access if SSH is unavailable

Our support cannot:

• Log into your cPanel/WHM or run patching commands inside your OS for you
• Pull files off your server on your behalf
• Investigate or remediate compromise inside the OS

Everything in Steps 1–3 above is something you run yourself.

References

If you require assistance with BinaryLane services, feel free to submit a support ticket at our helpdesk here: Submit a ticket | BinaryLane

Last updated: 1 May 2026 — Sourced from cPanel advisory dated 28 April 2026 (last revised 30 April 2026)