[Updated] Critical cPanel Authentication Vulnerability (28th April 2026) – Immediate Server Update Required
Updates about the critical security vulnerability identified in cPanel and WHM (28th April 2026) that allows unauthenticated attackers to gain full administrative access to affected servers.
Latest Article Changes:
- 23:10 GMT: Added instructions for CentOS 6/7 Patching
- 23:10 GMT: Updated Mitigation Steps instructions
- 23:10 GMT: Added Detection Script
A critical security vulnerability has been identified in cPanel and WHM that allows unauthenticated attackers to gain full administrative access to affected servers. If you are running cPanel on a managed or self-managed server, immediate action is required.
What Has Been Discovered
A severe authentication bypass vulnerability, now tracked as CVE-2026-41940 with a CVSS score of 9.8 out of 10, has been disclosed in all currently supported versions of cPanel and WebHost Manager (WHM). The flaw exists in the login and session handling processes of cpsrvd, the core cPanel service daemon.
The root cause is a CRLF (Carriage Return Line Feed) injection vulnerability in the authentication flow. By sending a specially crafted request with a malicious Authorization header, an attacker can inject arbitrary session properties — including user=root — into session files written to disk before any authentication takes place. Upon reloading that session, the attacker effectively gains root-level administrative access to the server without ever providing valid credentials.
In plain terms: an unauthenticated remote attacker can take full control of your server.
Scope and Active Exploitation
This vulnerability affects cPanel and WHM versions after 11.40. Security researchers have identified over 2 million cPanel instances exposed to the internet — and reports confirm it has been actively exploited as a zero-day for at least 30 days prior to the public disclosure.
Indicators of active compromise include:
- Sessions containing both token_denied and cp_security_token with method=badpass
- Pre-authenticated sessions carrying authenticated attributes
- Sessions with tfa_verified but no valid origin
- Password fields containing newline characters
Moreover, our team identified that compromised servers include the following commands. You can check by executing the command history from your server’s CLI:
Check If Your Server is Compromised
Run the following script on your server to detect if it is compromised.
Save the below in file /root/ioc_checksessions_files.sh
#!/bin/bash
# Scan for compromised session files
SESSIONS_DIR="/var/cpanel/sessions"
COMPROMISED=0
echo "[*] Scanning session files for injection indicators..."
for session_file in "$SESSIONS_DIR"/raw/*; do
[ -f "$session_file" ] || continue
session_name=$(basename "$session_file")
# Check if this session is/was pre-auth
preauth_file="$SESSIONS_DIR/preauth/$session_name"
# IOC 0: Session has both token_denied AND cp_security_token and method=badpass origin (strong indicator of exploitation)
#
# token_denied is set by do_token_denied() in cpsrvd when a request
# supplies an incorrect security token. cp_security_token is the
# attacker-injected token value. This combination indicates:
#
# 1. Attacker injected a cp_security_token via newline payload
# 2. Attacker attempted to use the injected token
# 3. cpsrvd recorded the token mismatch (token_denied counter)
# during the exploitation window before the session was
# fully promoted
#
# In a legitimate session:
# - token_denied is only present after a user-initiated
# security token failure (rare, typically from expired bookmarks)
# - It would never co-exist with a badpass origin AND an
# attacker-controlled cp_security_token
#
# This IOC catches BOTH successful and failed exploitation attempts.
if grep -q '^token_denied=' "$session_file" && \
grep -q '^cp_security_token=' "$session_file"; then
# Extract values for triage context
token_val=$(grep '^cp_security_token=' "$session_file" | head -1 | cut -d= -f2)
denied_val=$(grep '^token_denied=' "$session_file" | head -1 | cut -d= -f2)
origin=$(grep '^origin_as_string=' "$session_file" | head -1 | cut -d= -f2-)
used=$(grep -a "$token_val" /usr/local/cpanel/logs/access_log | grep -m1 " 200 ")
external_auth=$(grep '^successful_external_auth_with_timestamp=' "$session_file")
# High confidence if origin is badpass (session was pre-auth)
if grep -q '^origin_as_string=.*method=badpass' "$session_file"; then
if [ -z "$external_auth" ] && [ -z "$used" ]; then
echo "Found possible injected session file: $session_file"
echo " - No sign of usage"
else
echo "[!] CRITICAL: Exploitation artifact - token_denied with injected cp_security_token: $session_file"
echo " - cp_security_token=$token_val"
echo " - token_denied=$denied_val"
echo " - origin=$origin"
echo " - Verdict: Session was pre-auth (badpass origin) with attacker-injected token"
echo " - USED: $used"
COMPROMISED=1
fi
# Medium confidence but still suspicious for any session
else
echo "[!] WARNING: Suspicious session with token_denied + cp_security_token: $session_file"
echo " - cp_security_token=$token_val"
echo " - token_denied=$denied_val"
echo " - origin=$origin"
echo " - Review manually: may be legitimate token expiration or exploitation attempt"
fi
fi
# IOC 1: Pre-auth session with authenticated attributes
if [ -f "$preauth_file" ]; then
if grep -qE '^successful_external_auth_with_timestamp=' "$session_file"; then
echo "[!] CRITICAL: Injected session detected: $session_file"
echo " - Contains 'successful_external_auth_with_timestamp' in pre-auth session"
COMPROMISED=1
fi
fi
# IOC 2: Any session with tfa_verified but no valid origin
if grep -q '^tfa_verified=1' "$session_file" && \
! grep -q '^origin_as_string=.*method=handle_form_login' "$session_file" && \
! grep -q '^origin_as_string=.*method=create_user_session' "$session_file" && \
! grep -q '^origin_as_string=.*method=handle_auth_transfer' "$session_file"; then
echo "[!] WARNING: Session with tfa_verified but suspicious origin: $session_file"
COMPROMISED=1
fi
# IOC 3: Password field containing newlines (corrupted session file)
if grep -qzP '(?m)^pass=.*\n.' "$session_file" 2>/dev/null; then
echo "[!] CRITICAL: Multi-line pass value detected: $session_file"
COMPROMISED=1
fi
done
if [ "$COMPROMISED" -eq 0 ]; then
echo ""
echo "[+] No indicators of compromise found."
else
echo ""
echo "[!] INDICATORS OF COMPROMISE DETECTED - IMMEDIATE ACTION REQUIRED"
echo " 1. Purge all affected sessions"
echo " 2. Force password reset for root and all WHM users"
echo " 3. Audit /var/log/wtmp and WHM access logs for unauthorized access"
echo " 4. Check for persistence mechanisms (cron, SSH keys, backdoors)"
fi
Then run it as follows:
root@localhost:~$ bash ioc_chesessions_files.shImportant: The script will not disinfect your server. It will just provide you an indication whether it has been compromised or not.
Immediate Mitigation Steps – What You Need To Do
Official instructions by cPanel: https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026
Step 1: Update cPanel/WHM
Run the forced update script via SSH:
root@localhost:~$ /scripts/upcp --forcePatched versions are:
| Branch | Patched Version |
|---|---|
| 11.86 | 11.86.0.41 |
| 11.110 | 11.110.0.97 |
| 11.118 | 11.118.0.63 |
| 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 |
Step 2: Verify Build Version
Confirm your server is on one of the patched versions as of Table 1.0 and then restart the cPanel service:
root@localhost:~$ /usr/local/cpanel/cpanel -V
root@localhost:~$ /scripts/restartsrv_cpsrvdNotice to CentOS/CloudLinux 6/7 Users
If you are using CentOS 6/7 or CloudLinux 6/7, following these instructions as per latest cPanel’s article:
For customers still on CentOS 6 or CloudLinux 6 using v110.0.50, cPanel released v110.0.103 as a direct update. To upgrade to this version, run the following command to set the upgrade tier.
root@localhost:~$ whmapi1 set_tier tier=11.110.0.103If your server uses CentOS 7 or CloudLinux 7, you will need to set the version to 11.110, as below:
root@localhost:~$ whmapi1 set_tier tier=11.110Once you run the above commands you can then continue with the steps as per the “Immediate Mitigation Steps” section above.
cPanel Update Doesn’t Work?
If you cannot patch immediately, block inbound traffic on ports 2083, 2087, 2095, and 2096 at your firewall, or stop the cpsrvd and cpdavd services until you can apply the patch.
Depending on what firewall you are using, you may allow access to the above ports only to specific, trusted IPs of yours.
Need Further Help?
If you’re unsure whether your server is affected, need assistance applying the patch, or want to discuss upgrading to a managed hosting plan where we handle security updates on your behalf, contact us immediately. Our engineers are on standby to assist.
