cPanel/WHM Triple CVE Disclosure: CVE-2026-29201, CVE-2026-29202, CVE-2026-29203 (May 8, 2026)

Share
cPanel/WHM Triple CVE Disclosure: CVE-2026-29201, CVE-2026-29202, CVE-2026-29203 (May 8, 2026)

Published: May 8, 2026
Affected Products: cPanel & WHM, WP Squared (WP2)
Patch Status: Available — apply immediately
Context: Second emergency Technical Security Release (TSR) within 10 days

Executive Summary

WebPros (cPanel) released a coordinated patch on May 8, 2026 at 12:00 EST addressing three distinct vulnerabilities affecting cPanel & WHM and WP Squared. This is the second emergency TSR in 10 days, following CVE-2026-41940 — the CVSS 9.8 CRLF authentication bypass that drove an estimated 44,000 server compromises and a wave of .sorry ransomware deployments since late February 2026.

While none of the three new CVEs appear to be unauthenticated remote code execution at the level of CVE-2026-41940, they represent a significant local-access attack surface and should be patched within the maintenance window today.

The three vulnerabilities at a glance:

CVE Component Type Pre-Auth?
CVE-2026-29201 feature::LOADFEATUREFILE adminbin Arbitrary file read (path traversal) No (authenticated)
CVE-2026-29202 create_user API → plugin parameter Perl code injection No (authenticated)
CVE-2026-29203 Symlink handling in privileged context Arbitrary chmod → DoS + LPE No (authenticated)

CVE-2026-29201 — Arbitrary File Read via LOADFEATUREFILE

Technical Details

An arbitrary file read was found in the feature::LOADFEATUREFILE adminbin call where it does not adequately validate the feature file name. A relative path may be passed as the argument to this call, causing an arbitrary file to be made world-readable.

Attack flow:

  1. Attacker has cPanel user-level access (any cPanel account)
  2. Issues an adminbin call to feature::LOADFEATUREFILE with a relative path argument (e.g., ../../../etc/shadow)
  3. cPanel's privileged adminbin process services the request without proper sanitization
  4. Target file's permissions are modified to world-readable (0644 or similar)
  5. Attacker (and any other user on the system) can now read sensitive files

Real-World Impact

⚠️ This is worse than a typical file-read bug. The vulnerability doesn't just leak content to the requesting user — it changes file permissions, exposing the file to every user on the system and potentially leaving the permission change in place even after exploitation.

High-value targets on a compromised cPanel server:

  • /etc/shadow — password hashes
  • /var/cpanel/users/* — cPanel account configuration including hashed passwords, package data
  • /etc/cpanel/ea4/server.json — EasyApache 4 configuration
  • /var/cpanel/ssl/installed/keys/* — SSL private keys
  • /root/.my.cnf — root MySQL credentials
  • /etc/csf/csf.conf — firewall rules and exemptions

Forensic Indicators

Look for unexpected permission changes on sensitive files:

# Find recently world-readable sensitive files
find /var/cpanel/users -perm -004 -mtime -10 -ls
find /etc -name "shadow*" -perm -004 -ls
find /root -perm -004 -mtime -30 -ls

# Check adminbin logs
grep -i "LOADFEATUREFILE" /usr/local/cpanel/logs/error_log
grep -i "feature" /usr/local/cpanel/logs/cpanel_php_error.log

CVE-2026-29202 — Perl Code Injection in create_user API

Technical Details

A Perl code injection method was found in the create_user API call, relating to the plugin parameter.

Attack flow:

  1. Attacker has authenticated WHM access (reseller or admin)
  2. Crafts a create_user API call with malicious Perl code embedded in the plugin parameter
  3. cPanel's daemon evaluates the parameter without proper sanitization (likely an eval or string interpolation into a Perl system/exec context)
  4. Code executes in the context of the cPanel daemon — typically root

Real-World Impact

⚠️ This is the most severe of the three CVEs. Perl code injection in a privileged daemon context is functionally equivalent to authenticated RCE-as-root on cPanel servers. Combined with CVE-2026-41940 from 10 days ago (which was a pre-auth bypass), an attacker who exploited the auth bypass and is still resident on a system has a clean privilege path even after the auth bypass is patched.

Particularly concerning for:

  • Multi-tenant hosting providers with reseller accounts (resellers can call this API)
  • Servers where reseller credentials may have been compromised in the CVE-2026-41940 wave
  • Automated provisioning systems with stored WHM credentials

Forensic Indicators

# Audit recent create_user API calls
grep -E "create_user|createacct" /usr/local/cpanel/logs/access_log | \
    awk '$9 == 200' | tail -200

# Look for suspicious plugin parameters
grep -E "create_user.*plugin=" /usr/local/cpanel/logs/access_log | \
    grep -iE "(\`|;|\\$\\(|system|exec|eval|backtick)"

# Check WHM API call logs for anomalies
tail -1000 /usr/local/cpanel/logs/api_log | grep create_user

Technical Details

An unsafe symlink handling error was found that allows a user to chmod an arbitrary file, allowing for denial of service and possible privilege escalation.

Attack flow:

  1. cPanel privileged process performs chmod on a path the user controls (typical pattern: a file in /home/user/ or /tmp/)
  2. Attacker swaps the file with a symlink pointing to a system file (e.g., /etc/passwd, /etc/shadow, /usr/bin/sudo)
  3. The privileged process follows the symlink and applies chmod to the target instead of the original file
  4. Attacker either breaks the system (DoS via chmod 000 /etc/passwd) or sets up further exploitation (e.g., chmod 4755 on a writable binary for SUID escalation)

Real-World Impact

DoS scenarios:

  • chmod 000 /etc/passwd → no logins possible until restored
  • chmod 600 /usr/bin/passwd → users cannot change passwords
  • chmod 000 /etc/csf/csf.conf → firewall reload fails

Privilege escalation scenarios:

  • Make an attacker-writable file SUID root
  • Make a sensitive config file writable (e.g., /etc/sudoers.d/*)
  • Combine with CVE-2026-29201 to first read /etc/shadow, then break it

Forensic Indicators

# Look for unexpected SUID files (created in last 30 days)
find / -perm -4000 -mtime -30 -ls 2>/dev/null | \
    grep -vE "^/usr/(bin|sbin|libexec)/"

# Check for files with unusual permissions in user homes
find /home -perm -4000 -ls 2>/dev/null
find /home -perm -2000 -ls 2>/dev/null

# Audit chmod operations from cPanel processes
ausearch -k chmod_audit 2>/dev/null | grep -i cpanel

Patched Versions

Apply any of the following or higher:

Branch Patched Version
11.136 (current) 11.136.0.9+
11.134 11.134.0.25+
11.132 11.132.0.31+
11.130 11.130.0.22+
11.126 11.126.0.58+
11.124 11.124.0.37+
11.118 11.118.0.66+
11.110 11.110.0.116+ or 11.110.0.117+
11.102 11.102.0.41+
11.94 11.94.0.30+
11.86 11.86.0.43+
WP Squared 11.136.1.10+
CentOS 6 / CloudLinux 6 v110.0.114 (special tier)

Patching Procedure

Standard Servers (CentOS 7+, AlmaLinux, RHEL, Ubuntu)

# 1. Snapshot/backup before patching (highly recommended)
# Proxmox example:
# qm snapshot <vmid> pre-cpanel-tsr-may2026

# 2. Force update
/scripts/upcp --force

# 3. Verify version
/usr/local/cpanel/cpanel -V

# 4. Restart cpsrvd to ensure new code is loaded
/scripts/restartsrv_cpsrvd

# 5. Verify daemon restarted cleanly
/scripts/restartsrv_cpsrvd --status

CentOS 6 / CloudLinux 6 Servers

# 1. Set the upgrade tier to the CL6-specific patched build
sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf

# 2. Verify the tier change
grep -i "^CPANEL=" /etc/cpupdate.conf

# 3. Force update
/scripts/upcp --force

# 4. Verify
/usr/local/cpanel/cpanel -V
# Should report 110.0.114 or higher

⚠️ CentOS 6 users: This is end-of-life territory. Patching this TSR is fine, but plan migration to AlmaLinux 8/9 or CloudLinux 8 — you're accumulating unpatched kernel-level CVEs (including Dirty Frag and Copy Fail) that won't get backports.

WP Squared (WP2)

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
# Should report 11.136.1.10 or higher

Verification Across Multiple Servers (Ansible)

---
- name: Verify cPanel TSR May 2026 patch level
  hosts: cpanel_servers
  tasks:
    - name: Get cPanel version
      command: /usr/local/cpanel/cpanel -V
      register: cpanel_version
      changed_when: false

    - name: Display version
      debug:
        msg: "{{ inventory_hostname }}: {{ cpanel_version.stdout }}"

    - name: Flag unpatched servers
      fail:
        msg: "UNPATCHED: {{ inventory_hostname }} running {{ cpanel_version.stdout }}"
      when: >
        '11.136.0.9' not in cpanel_version.stdout and
        '11.134.0.25' not in cpanel_version.stdout and
        '11.132.0.31' not in cpanel_version.stdout and
        '11.130.0.22' not in cpanel_version.stdout and
        '11.126.0.58' not in cpanel_version.stdout
      ignore_errors: yes

Post-Patch Audit (Critical for Anyone Who Was Vulnerable to CVE-2026-41940)

If your servers were exposed during the late February → late April 2026 window of CVE-2026-41940 active exploitation (CVSS 9.8 CRLF auth bypass), assume potential compromise and audit accordingly. The current TSR may not be enough on its own.

1. Search for .sorry Ransomware Artifacts

# Recursive scan of user homes for ransomware indicators
find /home -name "*.sorry" -ls 2>/dev/null
find /var/www -name "*.sorry" -ls 2>/dev/null
find /opt -name "*.sorry" -ls 2>/dev/null

# Check for known ransom note filenames
find /home -iname "READ*ME*" -mtime -90 -ls 2>/dev/null
find /home -iname "*recover*" -mtime -90 -ls 2>/dev/null

2. Audit Suspicious cPanel Sessions

# Sessions created during the active exploitation window
find /var/cpanel/sessions -mtime -90 -name "*.json" | \
    xargs -I{} sh -c 'echo "=== {} ==="; cat "{}"' 2>/dev/null | \
    grep -E "user|created|ip" | head -200

# Check login_log for unusual auth patterns
grep -E "FAILED|root" /usr/local/cpanel/logs/login_log | \
    awk -F'[][]' '{print $2}' | sort -u

3. Look for Webshells in User Accounts

# Common webshell signatures in user content
grep -RElZ "(eval\(base64_decode|gzinflate.*str_rot13|FilesMan|c99shell|r57shell|WSO|Mister Spy)" \
    /home/*/public_html/ 2>/dev/null

# Recently modified PHP files in unusual locations
find /home/*/public_html -name "*.php" -mtime -30 -size -10k \
    -path "*wp-content*" -ls 2>/dev/null

4. Audit Backdoor Users

# All users with shell access
grep -vE ":(/bin/false|/sbin/nologin|/usr/sbin/nologin)$" /etc/passwd

# Recently added system users (UID < 1000)
awk -F: '$3 < 1000 {print}' /etc/passwd | \
    while IFS=: read user _ uid _; do
        stat -c "%y %n" /home/$user 2>/dev/null
    done

# cPanel users created during exploitation window
find /var/cpanel/users -mtime -90 -ls

5. Check for Persistence Mechanisms

# Cron jobs added recently
find /var/spool/cron -mtime -90 -ls
find /etc/cron.* -mtime -90 -ls

# Systemd services added recently
find /etc/systemd/system /usr/lib/systemd/system -name "*.service" -mtime -90 -ls

# Suspicious processes
ps auxf | grep -iE "(xmrig|kdevtmpfsi|kinsing|donate|stratum)"

Hardening Recommendations

1. Lock Down WHM/cPanel Network Exposure

Most cPanel-related compromises result from the management ports (2083, 2087, 2095, 2096) being exposed to the world.

# CSF: restrict WHM/cPanel ports to admin IPs only
# /etc/csf/csf.conf
TCP_IN = "20,21,25,53,80,110,143,443,465,587,993,995"

# Move management ports to ALLOWLIST only
# /etc/csf/csf.allow
tcp|in|d=2083|s=YOUR.ADMIN.IP.HERE
tcp|in|d=2087|s=YOUR.ADMIN.IP.HERE

# Block management ports for everyone else
# /etc/csf/csf.deny (or via TCP_IN restriction)

⚠️ For shared hosting where you can't lock cPanel (port 2083) to admin IPs only because users need access: at minimum lock WHM (2087) to your office/VPN IPs. WHM is the higher-value target — that's where reseller and root access lives.

2. Enforce 2FA on All WHM Accounts

# Force 2FA for all root/reseller accounts via WHM:
# Home → Security Center → Two-Factor Authentication → Manage Users
# Set "Require 2-Factor Authentication" to ON

# Or via API:
whmapi1 twofactorauth_set_policy is_required=1

3. Restrict Reseller Privileges

CVE-2026-29202 (Perl injection) is exploitable by anyone with permission to call create_user — typically resellers. Audit your reseller permissions:

# List all resellers and their privileges
whmapi1 listresellers
for r in $(whmapi1 --output=json listresellers | jq -r '.data.reseller[].user'); do
    echo "=== $r ==="
    whmapi1 listacls user=$r
done

4. Disable Unused cPanel Features

If you don't use specific features (AFS/RxRPC, IPsec, certain plugins), disable them at the WHM level to reduce attack surface.

5. Centralized Log Forwarding

Forward /usr/local/cpanel/logs/access_log, error_log, and login_log to a SIEM or central syslog. The exploitation timeline of CVE-2026-41940 (3 months in the wild before disclosure) demonstrates that local log retention isn't enough.

# Example rsyslog config: /etc/rsyslog.d/cpanel.conf
$ModLoad imfile
$InputFileName /usr/local/cpanel/logs/access_log
$InputFileTag cpanel-access:
$InputFileStateFile cpanel-access-state
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

local6.* @@your-siem.example.com:514

6. Stay on a Supported Tier

# Check current tier
grep -i "^CPANEL=" /etc/cpupdate.conf

# Tier recommendations (May 2026):
# - 11.136 (CURRENT) for new deployments
# - 11.134 (RELEASE) for production
# - Avoid LTS branches >2 years old unless absolutely required

Why Two Emergency TSRs in 10 Days?

This isn't a coincidence. When a major vulnerability like CVE-2026-41940 surfaces, internal security teams typically conduct a deep audit of adjacent code paths. That re-examination usually surfaces additional issues that were previously undiscovered or deprioritized — exactly what we're seeing here.

The structural reality: cPanel is a monolithic Perl + PHP codebase that handles authentication, session management, system-level operations, network configuration, DNS, email, and web server settings from a single privileged daemon. When a single injection flaw can unravel the entire security model, the auditing dividend after one critical bug is usually several more.

Practical takeaway: Expect more cPanel TSRs in the next 30–60 days. Build your patching pipeline assuming this. If you're managing 10+ cPanel servers and don't have an Ansible playbook for upcp --force rollouts plus version verification, build one this week.


Final Action Checklist

  • [ ] Patch all cPanel/WHM and WP2 servers to a patched version (see table above)
  • [ ] Verify version with /usr/local/cpanel/cpanel -V on each server
  • [ ] Restart cpsrvd with /scripts/restartsrv_cpsrvd
  • [ ] Audit .sorry artifacts if you were exposed to CVE-2026-41940 (Feb–Apr 2026)
  • [ ] Audit recent create_user API calls for suspicious plugin parameters
  • [ ] Audit suspicious file permission changes in /etc, /root, /var/cpanel
  • [ ] Lock down WHM (port 2087) to admin IPs via CSF
  • [ ] Enforce 2FA on all WHM root and reseller accounts
  • [ ] Subscribe to cPanel security mailing list for future TSR pre-disclosures
  • [ ] Build/update Ansible playbook for cPanel patch rollouts
  • [ ] Schedule a CentOS 6 / CloudLinux 6 migration if applicable

References

  • cPanel Security Advisory CVE-2026-29201
  • cPanel Security Advisory CVE-2026-29202
  • cPanel Security Advisory CVE-2026-29203
  • cPanel Changelog: https://docs.cpanel.net/changelogs/
  • Related: CVE-2026-41940 (CRLF auth bypass, CVSS 9.8) — patched April 28, 2026
  • CISA Known Exploited Vulnerabilities Catalog

Last Updated: May 8, 2026, EET
Severity Assessment: Patch within 24 hours. Treat any server unpatched after May 10 as high-risk.