cPanel CVE-2026-29201, 29202, 29203: arbitrary file read, Perl code injection, DoS. three bugs in one disclosure, and the perl one is RCE.

# CVE-2026-29201, 29202, 29203: three cpanel bugs that just dropped, and one of them is ungated rce

every shared-hosting operator we've ever worked with has cpanel in their footprint somewhere. even the shops that swear they're "all kubernetes now" still have that one legacy reseller box paying the colo bill. so when cpanel ships three cves in a single advisory on may 8, with one of them being perl code injection that lands as the cpanel user, you stop what you're doing and you patch.

three bugs in one disclosure is rare for cpanel. they usually space these out. the fact that they batched 29201, 29202, and 29203 together tells you the internal audit found something structural, or someone external reported a chain. the file-read primitive feeds the perl injection feeds the dos. that's not three independent bugs, that's almost certainly the same code path getting hit three different ways.

there's no public poc yet. that window closes fast. file-read + perl injection in a public-facing control panel is the exact bug class that ends up in a metasploit module within two weeks and on shodan-scanned mass-exploitation lists within a month. if you operate cpanel boxes you are on the clock right now, not next maintenance window.

#CVE-2026-29201. arbitrary file read

the cpanel daemon runs as root for most of its lifecycle and drops privileges per-request to the calling cpanel user. an arbitrary file read in that context means an unauthenticated or low-privileged attacker can pull anything the cpanel process can touch. that's a long list.

the obvious targets:

• /var/cpanel/users/*. per-tenant config including quotas, mail accounts, addon domains, ip assignments
• /var/cpanel/accounting.log. account creation history
• /var/cpanel/whostmgr/passwd and the whm root token cache
• /root/.accesshash if hash auth is still enabled (it shouldn't be in 2026 but plenty of boxes still have it)
• /etc/userdomains and /etc/trueuserdomains. the entire customer map
• per-user ~/.my.cnf files containing mysql credentials in cleartext
• /etc/proftpd/* or /etc/pure-ftpd/* depending on your ftp stack

the worst-case read here isn't a single file, it's the discovery primitive. once an attacker can read /etc/userdomains they have every customer username, every domain, every alias. that becomes the targeting list for the next bug.

api tokens are the other landmine. cpanel api tokens live in /var/cpanel/authn/api_tokens_v2/whostmgr/ and per-user equivalents under /home/*/var/cpanel/. those tokens don't expire by default. if any of them were created by an admin who never set an expiration, the attacker has persistent api access even after you patch.

#CVE-2026-29202. perl code injection

this is the one. cpanel is perl. whm is perl. the templating system, the api dispatcher, the addon plugin loader. perl all the way down. when cpanel says "perl code injection leading to rce as the cpanel user," what they mean is an attacker can register or invoke a handler that gets eval'd in the context of the requesting user's cpanel session.

on a shared box that's catastrophic for tenant isolation. yes, the rce is as the cpanel user, not root. yes, suexec and cagefs (if you have cloudlinux) should contain it to the home directory. but the cpanel user can:

• read and write every file in /home// including the mail spool
• access the user's mysql databases via the cached .my.cnf
• call back into the cpanel api with that user's auth context
• modify cron entries, .htaccess, addon domain configs
• drop files into public_html/ of every addon and parked domain on that account

and here's where it gets nasty for multi-tenant. if the attacker can chain 29202 with any local privesc on your box (and there are plenty in unpatched kernels), they go from one customer to root, then to every customer. the perl injection is the foothold. the privesc is whatever your kernel is missing patches for.

the pivot pattern an offensive operator would run:

1. exploit 29202 to land in one cpanel user context
2. enumerate /etc/passwd and /etc/shadow (if readable, often not from cpanel uid)
3. drop a perl reverse shell into ~/public_html/ named something boring like wp-include.pl
4. enumerate other tenants via /etc/userdomains (read with 29201)
5. find a kernel exploit. dirtypipe variants are still working on plenty of unpatched boxes
6. now you're root, and root on a cpanel box means every customer's mail, every customer's database, every customer's wordpress wp-config.

the perl handler thing matters because cpanel's plugin architecture lets third-party vendors ship handlers (whmcs, softaculous, jetbackup, imunifyAV all do this). a third-party plugin that exposed a custom handler is a separate attack surface. don't assume the cpanel patch covers them.

#CVE-2026-29203. whm daemon dos

dos is the least scary of the three in isolation. crash the whm daemon, customers can't log into their control panels until you restart it. annoying, not fatal.

it matters because of timing. if 29202 gets exploited in the wild and you're doing incident response, the attacker can crash whm to lock you out of the admin interface while they finish exfiltrating. or they crash it to mask the audit log writes. or they crash it because mass-scanner bots are dumb and the scanner spams the dos vector across the internet, and now your customers can't access their email config during the panic.

dos bugs in admin daemons are force multipliers for the other bugs in the same disclosure. patch all three together, don't get cute and triage.

#detection. what to grep for right now

first, what version are you running:

/usr/local/cpanel/cpanel -V
# or
rpm -qa | grep cpanel

if you're below the may 8 build, you're vulnerable. cpanel ships these as point releases on every active lts, check the patched build numbers on their advisory page and match against your -V output exactly.

find perl handlers and check ownership/permissions:

find /usr/local/cpanel -type f -name "*.pm" -perm /o+w 2>/dev/null
find /var/cpanel -type f -name "*.pl" -perm /o+w 2>/dev/null
find /usr/local/cpanel/whostmgr -type f \( -name "*.pl" -o -name "*.pm" \) -newer /etc/cpanel/version 2>/dev/null

any world-writable perl in the cpanel tree is already game over independent of these cves. fix that first.

audit your scriptalias and rewriterule directives for anything calling perl with unfiltered request data:

grep -r "ScriptAlias" /etc/apache2/conf.d/ /var/cpanel/conf/ 2>/dev/null
grep -rn "RewriteRule.*\.pl" /etc/apache2/ 2>/dev/null
grep -rn "perl" /usr/local/apache/conf/includes/ 2>/dev/null

check the cpanel access log for suspicious file-read attempts already happening (pre-disclosure 0day window is a thing):

grep -E "(\.\./|%2e%2e|/etc/|/var/cpanel/|accesshash)" /usr/local/cpanel/logs/access_log | tail -200
grep -E "GET.*\?.*=/" /usr/local/cpanel/logs/access_log | awk '{print $1}' | sort -u

look for anomalous perl process spawns from cpanel uids:

ps -eo uid,pid,cmd | grep -i perl | grep -v "^[ ]*0"

baseline what's normal on your box before you start hunting. on a healthy cpanel host you'll see perl processes owned by cpanel users during their session windows. you should not see perl processes that have been running for days under those uids.

#the patch and how to apply it

cpanel pushes through its own updater, not apt or yum directly:

/usr/local/cpanel/scripts/upcp --force

if you're on a tier that auto-updates (most are by default) you may already have the fix. verify:

/usr/local/cpanel/cpanel -V
/usr/local/cpanel/whostmgr/bin/whostmgr2 --version

cross-reference the build string against the may 8 advisory. if you're on the wp squared / wp2 platform, the patch ships through the same channel but the build numbers differ. check both.

if you've disabled auto-updates because of a previous bad release (we don't blame you, cpanel has shipped breakage before), the command above forces the update. take a snapshot of the vm first. cpanel rollbacks are not fun.

after patching, restart cpanel and whm explicitly rather than trusting upcp to do it:

/usr/local/cpanel/scripts/restartsrv_cpsrvd
/usr/local/cpanel/scripts/restartsrv_cpanellogd

then re-verify the version. we have seen upcp report success while leaving the old binaries in place because of a stale pid file. trust but verify.

#what to tell your customers

your tenants do not need cve numbers. they need to know three things: is my site safe, do i need to do anything, did anyone get into my account.

draft template:

> on may 8, 2026, cpanel disclosed three vulnerabilities in the control panel software we use to host your account. we patched our servers within [X] hours of disclosure. your website itself was not vulnerable. these bugs affected the admin interface, not your wordpress/joomla/static site. however, as a precaution we recommend you (1) rotate your cpanel password, (2) review your email accounts for any unfamiliar forwarders or filters, (3) check your file manager for files you do not recognize in public_html. if you used the cpanel api with a long-lived token, rotate that token. we will reach out individually if we find evidence specific to your account.

do not promise customers that "no data was accessed." you don't know that yet. you'll know that after the log review.

resellers need a separate message. if you sell whm reseller accounts, those resellers had elevated access and need a stronger heads-up.

#the long-tail problem

here's the thing nobody is going to tell you. the cpanel patch fixes cpanel's perl. it does not fix every customer's perl.

shared hosting is full of decade-old perl cgi scripts that customers installed via fantastico or softaculous or just ftp'd up from some script archive in 2014. formmail, cgiemail, perl-based image galleries, custom cgi-bin scripts. if the bug class in 29202 is "unfiltered user input reaches a perl eval or string-form code dispatch," then every customer-installed perl script in /home/*/public_html/cgi-bin/ is independently auditable for the same pattern. the cpanel patch does not touch them.

find them:

find /home/*/public_html -name "*.pl" -o -name "*.cgi" 2>/dev/null | head -200
find /home/*/public_html -name "*.pl" -exec grep -l "eval" {} \; 2>/dev/null
find /home/*/public_html -name "*.cgi" -exec grep -l -E "(open|system|exec|backtick|qx)" {} \; 2>/dev/null

you cannot patch your customers' code. what you can do is:

1. install or update modsecurity with owasp crs at paranoia level 2 minimum
2. add a custom rule that blocks eval, system, backtick patterns in request bodies hitting /cgi-bin/*.pl
3. consider disabling perl cgi for accounts that don't actively use it (most don't)

example modsec rule to block obvious perl injection patterns:

SecRule REQUEST_URI "@rx \.(pl|cgi)(\?|$)" \
  "id:1029201,phase:2,deny,status:403,log,msg:'perl cgi suspicious payload',\
  chain"
  SecRule ARGS "@rx (eval\s*\{|system\s*\(|`|qx\s*[\/\{\(])"

tune carefully. you will false-positive on legitimate cgi if you're aggressive. but a 403 for a real customer is better than a webshell on your box.

#what to do if you find evidence of compromise

assume worst case until you've ruled it out. ir runbook:

1. snapshot the entire vm before you touch anything. cpanel boxes are stateful in ways that surprise you, and you will want the disk image for forensics.
2. pull /usr/local/cpanel/logs/access_log, /usr/local/cpanel/logs/error_log, and /usr/local/apache/logs/access_log off-box to a write-once location. attackers delete logs.
3. grep access_log for the file-read patterns we listed above. anything reading /etc/userdomains, /var/cpanel/users/, or accesshash that isn't from a known admin ip is a confirmed compromise.
4. hunt for webshells. perl injection lands shells as the cpanel user, so they live in /home/*/public_html/ or /home/*/cgi-bin/. look for:

find /home/*/public_html -type f -newer /etc/cpanel/version \( -name "*.php" -o -name "*.pl" -o -name "*.cgi" \) -mtime -30
grep -rEl "(eval\(base64_decode|str_rot13|gzinflate|passthru|shell_exec)" /home/*/public_html/ 2>/dev/null
grep -rEl "(system|exec|qx)" /home/*/public_html/cgi-bin/ 2>/dev/null

1. check outbound connections from cpanel-uid processes. attackers will have beacons:

ss -tnpa | grep -v "127.0.0.1\|::1" | grep -E "cpanel|perl|httpd"
lsof -i -n | grep -E "cpanel|perl" | grep -v LISTEN

1. rotate everything. whm root password. every customer cpanel password (force-reset on next login is acceptable). every api token. every reseller credential. mysql root and per-user mysql passwords if the attacker had cpanel uid access (they could read .my.cnf).
2. check /var/cpanel/users/* for any account you didn't create. attackers love to add a low-privilege account for persistence.
3. check cron. crontab -u -l for every user in /etc/passwd with a uid above 500. look for anything calling out to a url or invoking perl/python/bash with base64.
4. check ~/.ssh/authorized_keys for every user. that's the persistence path that survives password rotation.
5. if you confirm compromise on one tenant account, treat the whole box as compromised. reinstall the os. restore customer data from backup, not from the live box. it is the only way to be sure.

the timeline is short. patch today. audit tomorrow. customer comms by end of week. if you find blood in the logs, get a forensics partner on the phone before you start rotating things, because rotation destroys evidence.