CVE-2026-41940: Emergency Action Plan for cPanel & WHM Authentication Bypass

On April 28, 2026, cPanel published a security advisory — updated on May 1, 2026 — requiring immediate action on CVE-2026-41940. The issue is classified as an authentication bypass affecting the cPanel software (including DNSOnly) for all versions after 11.40.

CVSS v3.1: 9.8 CRITICAL — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0: 9.3 CRITICAL — AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CWE-306: Missing Authentication for Critical Function

The authentication bypass was analyzed and reported by watchTowr Labs. Their technical write-up is available at labs.watchtowr.com. A PoC (watchTowr-vs-cPanel-WHM-AuthBypass-to-RCE.py) is available on GitHub.

This post provides an operational action plan for hosting providers, agencies, system administrators, and teams managing cPanel/WHM on behalf of clients.

Why This Is Urgent

Authentication bypass vulnerabilities directly undermine the trust boundary of the identity and authorization flow. In management panels like cPanel/WHM, this risk extends far beyond a single user account:

• WHM administrative sessions can be hijacked.
• Hosting accounts, domain configurations, and email settings may be compromised.
• Webroot, cron jobs, SSH keys, database credentials, and backup pipelines are at risk.
• In agency or reseller environments, the blast radius can span multiple customer tenants.

The cPanel advisory specifically highlights that servers with disabled updates or pinned versions require manual intervention. The assumption that "auto-update was enabled" is not sufficient evidence in this incident.

CISA added CVE-2026-41940 to its Known Exploited Vulnerabilities (KEV) catalog with a remediation deadline of May 3, 2026. Active exploitation in ransomware campaigns (reported by BleepingComputer) has been confirmed.

Affected and Patched Versions

The following cPanel & WHM versions contain the patch:

| Branch | Patched Version | |--------|----------------| | 11.86 | 11.86.0.41 | | 11.110 | 11.110.0.97 | | 11.118 | 11.118.0.63 | | 11.124 | 11.124.0.35 | | 11.126 | 11.126.0.54 | | 11.130 | 11.130.0.19 | | 11.132 | 11.132.0.29 | | 11.134 | 11.134.0.20 | | 11.136 | 11.136.0.5 |

For WP Squared (WP2), the patched version is 136.1.7.

For servers running CentOS 6 or CloudLinux 6 on v110.0.50, cPanel has separately released v110.0.103 as a direct update path. These legacy platforms should not only receive the patch but also have a medium-term migration plan to a supported OS opened.

Step 1: Apply the Patch

Force a cPanel update on the server:

/scripts/upcp --force

After the update completes, verify the build version and perform a hard restart of the cpsrvd service:

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

For servers running CentOS 7 or CloudLinux 7 that need to move to the appropriate tier:

whmapi1 set_tier tier=11.110

For CentOS 6 / CloudLinux 6 on v110.0.50, refer to the specific tier command in the cPanel advisory.

Verify Auto-Update Status

The most common gap in this incident is overlooked update configuration. Check the following manually:

• Is cPanel automatic updating disabled entirely?
• Is the server pinned to a specific release tier?
• Is a legacy OS preventing upgrade to a supported version?
• Does the WHM panel setting reflect the actual command-line configuration?
• Are all servers in the fleet on a consistent update policy?

In multi-server hosting environments, use centralized inventory tooling rather than individual SSH checks.

Temporary Mitigation If Patching Is Not Immediately Possible

If the patch cannot be applied immediately, the cPanel advisory recommends either closing management ports at the firewall level or stopping the relevant services.

Firewall approach — block inbound traffic to the following ports and disable Service Subdomains:

whmapi1 set_tweaksetting key=proxysubdomains value=0 \
  && /scripts/proxydomains remove \
  && /scripts/rebuildhttpdconf \
  && /scripts/restartsrv_httpd

Ports to block: 2083, 2087, 2095, 2096

Blocking management ports affects customer operations. Weigh this against leaving an authentication bypass exposed on the management surface.

Service stop approach:

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 approach has operational impact and should be executed with a maintenance window and customer communication plan.

Session IOC Check

The cPanel advisory includes a detection script that inspects session files under /var/cpanel/sessions for combinations of fields that indicate exploitation activity.

Key indicators the script checks:

• Pre-auth session files containing unexpected authenticated attributes.
• token_denied and cp_security_token appearing together.
• tfa_verified set without a valid login origin.
• Malformed lines (not in key=value format) indicating newline injection.
• badpass origin combined with hasroot=1 or auth timestamps — impossible in a legitimate flow.
• The presence of a pass= line in a badpass-origin session (another injection fingerprint).

Download and run the detection script:

/bin/bash ./ioc_checksessions_files.sh

Before running, ensure root-level access, log retention policy, and an incident response process are ready. A positive IOC finding elevates the event from a patching task to a full incident response.

If IOC Findings Are Positive

If the session IOC check returns CRITICAL or WARNING findings, the following actions must be coordinated:

1. Purge all affected session files and force all users to re-authenticate.
2. Initiate password resets for root and all WHM users.
3. Review /var/log/wtmp, WHM access logs, and cPanel access logs for unauthorized access.
4. Inspect SSH authorized keys, cron jobs, webroot, addon domains, and panel user accounts.
5. Look for suspicious files, backdoors, web shells, and newly created email accounts.
6. Verify backup integrity and validate the last known-good restore points.
7. If root compromise is confirmed, open a migration plan to a clean server or schedule OS reinstallation.

Fleet Action List for Hosting Providers

If you manage multiple cPanel/WHM servers as a hosting provider or agency, a single-server runbook is not sufficient.

Recommended sequence:

• Export full cPanel/WHM host inventory.
• Flag servers with public-facing management ports.
• Collect version and OS information for every host.
• Identify systems with disabled updates or pinned tiers — treat these as highest priority.
• Update internet-facing and multi-tenant servers first.
• Record update completion, restart confirmation, and version output per host.
• Tie IOC script results to a centralized incident case.
• Prepare a clear, low-panic customer notification.

Short Customer Message for Agencies

Clients can be informed in the following framing without causing alarm:

A security update addressing CVE-2026-41940 — an authentication flow vulnerability in cPanel & WHM — has been released. We are applying the cPanel version update, restarting the necessary service, and running a session integrity check on all servers we manage. Management ports may be temporarily restricted if needed. We will share the verification output and any additional actions once completed.

Eresus Perspective

cPanel/WHM incidents often appear to be simple "panel updates" but the impact chain typically extends to webroot, email, DNS, cron, SSH, and customer data. In an authentication bypass event, the right question is not only "is the version current?"

Critical questions to ask:

• Is the panel management surface exposed to the internet?
• Are WHM users and reseller permissions properly scoped?
• Was the session IOC check performed?
• If suspicious sessions exist, have customer accounts potentially been affected?
• Is the backup and restore chain trustworthy?
• Are multiple customer tenants on the same server?

Eresus Security supports organizations through patch verification, log review, web shell hunting, credential rotation, and customer impact classification in this type of incident.

FAQ

Is /scripts/upcp --force alone sufficient?

Applying the patch is the required first step. If suspicious sessions or log entries exist, it is not sufficient on its own. IOC checks and access review must be performed separately.

Must we close the management ports?

If the server cannot be updated immediately, blocking management ports at the firewall is one of the temporary mitigations cPanel recommends. This impacts operations but is preferable to leaving an authentication bypass exposed on the management surface.

Are servers with auto-update enabled safe?

Do not assume. Verify the version output. After the update completes, confirm cpsrvd restart and run /usr/local/cpanel/cpanel -V.

What if IOC findings are positive?

Session cleanup, password reset, log review, persistence check, and a clean-server migration plan must all be executed together. A positive IOC moves the event from a routine patch to an active incident response.

Checklist

• [ ] All cPanel/WHM servers inventoried
• [ ] Current version output recorded per host
• [ ] /scripts/upcp --force executed
• [ ] cpsrvd hard restart completed
• [ ] Post-update version re-verified
• [ ] Servers with disabled/pinned updates identified
• [ ] Temporary firewall decision made for management ports
• [ ] Session IOC check executed
• [ ] Suspicious logs and persistence indicators reviewed
• [ ] Customer notification drafted and incident record opened