Fix CVE-2026-41940: How to Patch the Critical cPanel Authentication Bypass Vulnerability (2026)

CVE-2026-41940 is a critical authentication bypass vulnerability in cPanel & WHM that allows an unauthenticated remote attacker to gain full root-level administrative access to any affected server without a username or password. With a CVSS v3.1 score of 9.8 and confirmed in-the-wild exploitation dating back to February 23, 2026, two months before a patch was available, this is one of the most severe web hosting vulnerabilities in recent years.

cPanel released an emergency patch on April 28, 2026. CISA added CVE-2026-41940 to its Known Exploited Vulnerabilities catalog on April 30, 2026. If you manage a cPanel or WHM server and have not applied the patch, this guide walks you through every step: verifying your current version, applying the update, restarting the affected service, running the official indicator-of-compromise scan, and locking down your server going forward.

---

Table of Contents

---

1. Vulnerability Overview

Detail	Value
CVE ID	CVE-2026-41940
Severity	Critical
CVSS v3.1 Score	9.8
CVSS v4.0 Score	9.3
CWE	CWE-306: Missing Authentication for Critical Function
Exploit Type	Pre-authentication remote authentication bypass
Authentication Required	None
User Interaction Required	None
Patch Released	April 28, 2026
CISA KEV Added	April 30, 2026
Exploitation Observed Since	~February 23, 2026
Estimated Exposed Instances	~1.5 million (Shodan / Rapid7)

What an attacker can do if this vulnerability is successfully exploited:

• Gain full root-level WHM administrative access without credentials
• Access and exfiltrate all databases, email accounts, and website files on the server
• Modify DNS records, SSL certificates, and server configuration
• Create new privileged accounts or SSH keys for persistent access
• Deploy malware, web shells, or ransomware across every hosted site on the server
• Use compromised infrastructure for phishing, spam, or further attacks

The Shadowserver Foundation observed approximately 44,000 unique IP addresses actively scanning for or exploiting CVE-2026-41940 within 24 hours of public disclosure. Censys subsequently identified 8,859 hosts with open directories containing files with the .sorry extension, the marker of the “Sorry” Go-based ransomware, with 7,135 of those confirmed as running cPanel or WHM.

If your server was internet-facing and unpatched at any point after February 23, 2026, treat it as potentially compromised until a full audit confirms otherwise.

---

2. Affected Versions

CVE-2026-41940 affects all cPanel & WHM versions released after v11.40, including all currently supported release tracks. DNSOnly installations are also affected. WP Squared (cPanel’s managed WordPress platform) is affected on versions prior to 136.1.7.

Patched Builds

Update your installation to one of the following versions or higher on your release branch:

Release Branch	Vulnerable (below)	Patched (at or above)
cPanel & WHM 86.x	below 11.86.0.41	11.86.0.41
cPanel & WHM 110.x	below 11.110.0.97	11.110.0.97
cPanel & WHM 118.x	below 11.118.0.63	11.118.0.63
cPanel & WHM 126.x	below 11.126.0.54	11.126.0.54
cPanel & WHM 130.x	below 11.130.0.19	11.130.0.19
cPanel & WHM 132.x	below 11.132.0.29	11.132.0.29
cPanel & WHM 134.x	below 11.134.0.20	11.134.0.20
cPanel & WHM 136.x	below 11.136.0.5	11.136.0.5
WP Squared	below 136.1.7	136.1.7

Note: Servers running cPanel versions that have reached end-of-life (EOL) and do not appear in the table above did not receive a patch. If your server is running an EOL cPanel release, upgrading to a current, supported version is the only path to full remediation.

Note: Servers with automatic updates disabled or version pinning enabled will not self-update. These must be patched manually using the steps below.

---

3. How the Exploit Works

Understanding the mechanism helps you verify whether your audit findings are genuine and recognize what indicators of compromise look like in session files.

cPanel’s cpsrvd daemon, the process that handles all cPanel, WHM, and Webmail logins on ports 2082, 2083, 2086, 2087, 2095, and 2096, writes a temporary session file to disk before authentication is completed. This pre-authentication session file is what the attacker targets.

The exploit chains three weaknesses:

1. CRLF Injection via the Basic Auth header. The Basic Auth password handler in cpsrvd does not sanitize Carriage Return (\r) and Line Feed (\n) characters. An attacker can inject these characters into the password field of a crafted login request, embedding arbitrary key-value pairs into the session file that cpsrvd writes to /var/cpanel/sessions/raw/.

2. Encryption bypass triggered by a malformed cookie. By omitting an expected segment of the whostmgrsession cookie value, the attacker causes cpsrvd to skip the encryption step it would normally apply to the session data. This means the injected key-value pairs are written to the session file in plain text and are parsed by cpsrvd as legitimate session properties on the next read.

3. Session promotion to root. The injected lines include:

• user=root
• hasroot=1
• tfa_verified=1
• cp_security_token=/cpsess[arbitrary token]
• successful_internal_auth_with_timestamp=[timestamp]

When cpsrvd reloads this session, it finds all the properties it expects to see in a fully authenticated root session. Access is granted. No password was checked. Two-factor authentication was bypassed. No failed login appears in the standard authentication log because the session was never submitted to the normal authentication code path.

The result is full, unauthenticated root-level access to WHM and all accounts it manages.

---

Step 1: Check Your Current cPanel Build

Connect to your server via SSH as root and run:

/usr/local/cpanel/cpanel -V

Sample output:

11.134.0.19 (build 19)

Compare this against the patched versions in Section 2. If your build number is lower than the patched version for your release branch, proceed immediately to Step 2.

You can also check via WHM by navigating to WHM > Server Information and reviewing the cPanel Version field at the top of the page.

---

Step 2: Apply the Official Patch

Option A: Update via Command Line (Recommended)

SSH into the server as root and run a forced update:

/scripts/upcp --force

This forces cPanel to update to the latest available patched build on your current release track, regardless of any cached version checks. The update process typically completes in 5–15 minutes depending on server load and connection speed. Your websites, email, and databases remain online during the update. Only the cPanel management interface may be briefly unavailable.

To follow the update log in real time:

tail -f /var/cpanel/updatelogs/update.log

A successful update will produce a line similar to:

[2026-04-29 xx:xx:xx -0000] Running version '11.136.0.5' of updatenow.

Option B: Update via WHM Interface

1. Log in to WHM at https://your-server-ip:2087
2. Navigate to WHM > Upgrades > Update Config
3. Confirm your update preferences allow automatic updates
4. Navigate to WHM > Upgrades > Upgrade to Latest Version
5. Confirm and allow the update to complete

WP Squared Users

If your server runs WP Squared, update separately via the WP Squared admin interface or by contacting your hosting provider to confirm they have deployed version 136.1.7 or higher.

---

Step 3: Restart the cpsrvd Service

cPanel’s official guidance requires a restart of the cpsrvd service after patching to ensure the updated authentication logic is loaded into memory. Skipping this step means the patched code may not be active even after the update completes.

/scripts/restartsrv_cpsrvd

To confirm the service restarted successfully:

/scripts/restartsrv_cpsrvd --status

---

Step 4: Verify the Patch Was Applied

After the update and service restart, confirm the installed build has changed to a patched version:

/usr/local/cpanel/cpanel -V

The output must match one of the patched builds listed in Section 2. If the version did not change, re-run Step 2 with the --force flag and review the update log for errors.

If your server uses version pinning, check and clear it before running the update:

cat /etc/cpupdate.conf

Look for a CPANEL= line that specifies a pinned version. Remove or update it before re-running upcp.

---

Step 5: Run the Official Indicator-of-Compromise Scan

Applying the patch stops new exploitation. It does not remove backdoors, SSH keys, cron jobs, or other persistence mechanisms that an attacker may have planted during the exploit window. The next step is to scan session files for signs that the vulnerability was used against your server.

cPanel released an official indicator-of-compromise (IoC) detection script alongside the patch on April 29, 2026. This script scans /var/cpanel/sessions/raw/ for exploitation artifacts. Run it as root:

/bin/bash ./ioc_checksessions_files.sh

The script is available from cPanel’s official security advisory: CLICK HERE for the script

Interpreting the Output

The script produces a severity-graded summary:

=================================================================
SCAN SUMMARY
=================================================================
CRITICAL findings:   1
WARNING  findings:   0
ATTEMPT  findings:   1
INFO     findings:   0
Total             :  2

Finding Level	Meaning	Action Required
CRITICAL	Exploitation artifact confirmed. Session was promoted to root.	Treat as compromised. See Section 8.
WARNING	Suspicious session data. Possible exploitation attempt.	Investigate further. Purge sessions.
ATTEMPT	Failed exploitation attempt detected in session files.	Patch confirmed. Harden firewall.
INFO	Anomalous but not clearly malicious.	Review and monitor.

A clean scan with zero CRITICAL or WARNING findings and a confirmed patched build means the server was not successfully compromised via this vulnerability.

---

Step 6: Manual Session File Audit

If you want to inspect session files directly without running the script, look for the following known exploitation artifacts in /var/cpanel/sessions/raw/:

# Check for injected root session markers
grep -r "user=root" /var/cpanel/sessions/raw/
grep -r "hasroot=1" /var/cpanel/sessions/raw/
grep -r "tfa_verified=1" /var/cpanel/sessions/raw/

# Look for sessions with both token_denied and an injected cp_security_token
grep -rl "token_denied=1" /var/cpanel/sessions/raw/ | xargs grep -l "cp_security_token" 2>/dev/null

# Look for sessions with multiple pass= lines (sign of injection)
grep -rc "^pass=" /var/cpanel/sessions/raw/ | grep -v ":1$"

Any session file containing user=root, hasroot=1, or tfa_verified=1 in a pre-authentication context is an indicator of compromise.

You can also scan the cpsrvd access log for the request pattern associated with exploitation, a failed login to /login/?login_only=1 followed immediately by an authenticated request from the same source IP without a subsequent successful login:

grep "login_only=1" /usr/local/cpanel/logs/access_log | grep "401"

---

Step 7: Firewall Mitigation (If Immediate Patching Is Not Possible)

If you cannot apply the patch immediately, for example, due to version pinning, an EOL cPanel release, or operational constraints, restrict inbound access to cPanel and WHM ports to trusted IP addresses only. This does not fix the vulnerability but prevents external attackers from reaching the affected service.

Using iptables

# Block cPanel (2082/2083) and WHM (2086/2087) from all sources
iptables -I INPUT -p tcp --dport 2082 -j DROP
iptables -I INPUT -p tcp --dport 2083 -j DROP
iptables -I INPUT -p tcp --dport 2086 -j DROP
iptables -I INPUT -p tcp --dport 2087 -j DROP

# Allow access only from a trusted admin IP (replace with your IP)
iptables -I INPUT -p tcp --dport 2082 -s YOUR.ADMIN.IP.HERE -j ACCEPT
iptables -I INPUT -p tcp --dport 2083 -s YOUR.ADMIN.IP.HERE -j ACCEPT
iptables -I INPUT -p tcp --dport 2086 -s YOUR.ADMIN.IP.HERE -j ACCEPT
iptables -I INPUT -p tcp --dport 2087 -s YOUR.ADMIN.IP.HERE -j ACCEPT

Also block the Webmail ports if Webmail is not required from external networks:

iptables -I INPUT -p tcp --dport 2095 -j DROP
iptables -I INPUT -p tcp --dport 2096 -j DROP

Using CSF (ConfigServer Security & Firewall)

If you run CSF, add your admin IP to /etc/csf/csf.allow and add the cPanel ports to /etc/csf/csf.ignore or block them in /etc/csf/csf.deny for external access, then reload:

csf -r

Important: Restricting these ports will prevent external access to cPanel, WHM, and Webmail. Ensure you have SSH access and an alternative management path before applying these rules. This is a temporary containment measure — patching remains the only full remediation.

---

What to Do If Your Server Was Compromised

If the IoC scan in Step 5 returns CRITICAL or WARNING findings, or if you have other evidence of unauthorized access, work through the following incident response steps. If any doubt remains about the completeness of the cleanup, rebuilding from a clean backup predating February 23, 2026 is the safest option.

1. Purge All Active cPanel Sessions

This immediately terminates any attacker-controlled sessions:

rm -rf /var/cpanel/sessions/raw/*
rm -rf /var/cpanel/sessions/preauth/*

This logs out all legitimate users as well. It is a necessary step.

2. Force-Reset All Passwords

Change the root system password:

sudo passwd

Reset all WHM and reseller passwords via WHM → Account Functions → Password Modification, or via the command line:

# Reset a cPanel account password
/scripts/change_user_password username newpassword

Rotate all API tokens under WHM > Development > Manage API Tokens.

3. Audit for Backdoor SSH Keys

# Check root's authorized keys
cat /root/.ssh/authorized_keys

# Check all home directories for unexpected authorized keys
find /home /root -name authorized_keys -exec cat {} \; -print

Remove any SSH keys you do not recognize.

4. Check for Unauthorized Cron Jobs

# List root cron jobs
crontab -l

# Check all user cron entries
for user in $(cut -f1 -d: /etc/passwd); do echo "--- $user ---"; crontab -u "$user" -l 2>/dev/null; done

# Check system-level cron files
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/

5. Review WHM for Unauthorized Accounts

In WHM, navigate to WHM > Account Functions > List Accounts and verify every account is legitimate. Check WHM > Security Center > Security Advisor for any configuration anomalies.

6. Scan for Web Shells and Malware

# Scan with ClamAV (install if not present)
clamscan -r /home --infected --remove

# Or use Maldet (Linux Malware Detect)
maldet --scan-all /home

7. Audit Recent Login History

# Check recent successful logins
last -20

# Check failed login attempts
lastb | head -40

# Review WHM access log for unauthorized admin activity
tail -200 /usr/local/cpanel/logs/access_log | grep "WHM"

8. Check for sudoers Modifications

cat /etc/sudoers
ls -la /etc/sudoers.d/

Remove any entries that were not placed there intentionally.

9. Verify Core Binary Integrity

# Check for modified RPM-managed binaries (AlmaLinux/CentOS/Rocky)
rpm -Va --nofiles --nodigest 2>/dev/null | grep "^..5"

# Check recently modified files in sensitive directories
find /usr/bin /usr/sbin /bin /sbin -newer /tmp -type f -ls

---

Long-Term Prevention and Hardening

After patching and completing the compromise audit, apply the following hardening measures to reduce exposure to this and future vulnerabilities.

Enable Automatic cPanel Updates

Ensure cPanel is configured to update automatically so future security patches are applied without manual intervention:

1. Navigate to WHM > Server Configuration > Update Preferences
2. Set Update Tier to STABLE or RELEASE
3. Set Automatic Updates to Daily
4. Save changes

To verify and set this from the command line:

cat /etc/cpupdate.conf

The file should contain:

CPANEL=stable
RPMUP=daily
SARULESUP=daily

Restrict WHM and cPanel Ports to Trusted IPs

Even with the patch applied, exposing WHM (port 2087) to the entire internet is unnecessary for most deployments. Add a permanent firewall rule allowing only known admin IP ranges:

# In CSF: add your admin IP to csf.allow
echo "YOUR.ADMIN.IP.HERE # Admin workstation" >> /etc/csf/csf.allow
csf -r

In WHM, you can also use WHM > Security Center > Host Access Control to restrict access by IP using TCP Wrappers.

Enable Two-Factor Authentication for WHM

Navigate to WHM > Security Center > Two-Factor Authentication and enable 2FA for the root account and all reseller accounts. Note that CVE-2026-41940 bypasses 2FA, but once the patch is applied, 2FA provides a critical additional layer for future authentication attempts.

Enable cPHulk Brute Force Protection

WHM > Security Center > cPHulk Brute Force Protection: enable this and configure it to lock accounts after a defined number of failed login attempts. Default settings (5 failed attempts within 15 minutes) are a reasonable starting point.

Shorten Session Lifetimes

Navigate to WHM > Server Configuration > Tweak Settings > Security and reduce the session timeout to 15 minutes for WHM. Long-lived sessions increase the risk window if a session token is stolen or compromised.

Implement a Web Application Firewall

Cloudflare released an emergency WAF rule for CVE-2026-41940 on April 30, 2026. If your cPanel server’s public-facing sites run behind Cloudflare or another WAF provider, confirm that the CVE-2026-41940 rule is active. This provides a network-layer block against exploitation attempts even for unpatched installations, though it is not a substitute for patching.

Subscribe to cPanel Security Advisories

Monitor cPanel’s official security advisories at https://docs.cpanel.net/knowledge-base/security/ and subscribe to CISA’s Known Exploited Vulnerabilities feed to receive notice of critical vulnerabilities before widespread exploitation begins.

---

Conclusion

CVE-2026-41940 is an authentication bypass that requires no credentials and no user interaction. It was actively exploited as a zero-day for roughly two months before a patch was available, and weaponized exploit code is now publicly available. Patching alone is not sufficient if your server was internet-facing before April 28, 2026, the IoC scan and the post-compromise audit steps in this guide are equally necessary.

If you are on a managed Veeble cPanel Hosting or VPS plan and need assistance verifying patch status, running the IoC scan, or applying post-compromise hardening, open a support ticket from your Veeble Client Zone. Our team can confirm your server’s build version and walk through the remediation steps with you.

---