HIGH: cPanel Drops Three More CVEs After Sorry Ransomware Wreckage, One Is a Perl Injection in create_user

cPanel just shipped its second emergency Targeted Security Release in ten days, and the timing alone tells you everything about the state of the world's web hosting fleet right now. Three new CVEs landed on May 8, 2026, fixing input validation bugs that range from "uncomfortable" to "set the building on fire," all on the heels of CVE-2026-41940 being weaponized to drop Mirai variants and the "Sorry" ransomware strain on tens of thousands of servers. If you are running cPanel and WHM and you have not run /scripts/upcp --force in the last seventy-two hours, this is your reminder that the threat landscape is not waiting for your maintenance window.

The headline of the new advisory is CVE-2026-29202, a Perl code injection flaw in the create_user API call carrying a CVSS of 8.8. The plugin parameter, which is supposed to identify the plugin handling the user creation flow, never gets validated. Unsanitized input flows directly into the Perl interpreter, which means an authenticated attacker can submit a malicious string and have the server execute arbitrary Perl code under the system account associated with the calling user. Cybersecuritynews flagged it as "the second and most severe flaw" of the three, and the description is exactly the pattern that turns a "limited" authenticated bug into a full server takeover when paired with stolen reseller credentials, a leaked WHM admin password, or a compromised WP Squared customer account.

CVE-2026-29203, the second 8.8, is the kind of bug that the security industry has been patching out of Unix since approximately 1989, which makes its presence in production cPanel in 2026 a special kind of frustrating. It is an unsafe symlink handling vulnerability where the daemon performs chmod operations on user-supplied paths without validating that those paths are not symbolic links pointing somewhere they should not. The result is that a local user, or any account with shell-equivalent access, can flip permissions on arbitrary files anywhere on the system. The advisory describes the impact as denial of service or possible privilege escalation, which is the cPanel team being polite. In practice, "let me chmod that suid binary for you" is the kind of primitive that gets chained into root, and a determined attacker who can also write to a useful target file will not be limited to denial of service for long.

CVE-2026-29201 rounds out the trio at a softer CVSS of 4.3. The feature::LOADFEATUREFILE adminbin call accepts a feature file name without sufficient validation, so a relative path like ../../etc/something gets resolved against the server filesystem instead of the intended feature directory. The end result, according to the advisory, is that an arbitrary file on the server gets made world-readable. That is "arbitrary file read" with extra steps, and it is the kind of bug that hands an attacker exactly the recon they need to make the other two vulnerabilities work. SSH host keys, Apache configurations, MySQL credential files, and the entire cPanel user database all live in places that a path traversal makes accessible. The 4.3 score reflects the constraint that the attacker needs an existing authenticated account to call the adminbin, not the operational impact of every secret on the box becoming readable.

Patched versions span the entire cPanel branch matrix the way you would expect from a vendor whose customer base spans two decades of hosting providers. The fixes ship in 11.136.0.9, 11.134.0.25, 11.132.0.31, 11.130.0.22, 11.126.0.58, 11.124.0.37, 11.118.0.66, 11.110.0.116, 11.110.0.117, 11.102.0.41, 11.94.0.30, and 11.86.0.43. WP Squared customers need 11.136.1.10 or higher. There is also a special direct update labeled 110.0.114 for the unfortunate souls still running CentOS 6 or CloudLinux 6, which is itself a story about the long tail of unpatched legacy infrastructure that cPanel customers have to drag along for compliance reasons and customer commitments. The mechanical mitigation is straightforward. Run /scripts/upcp --force on every cPanel and WHM box you operate, then verify the result with /usr/local/cpanel/cpanel -V to confirm you actually moved off a vulnerable build. If you operate at scale across hundreds or thousands of customer instances, the answer is automation, not opening a ticket for each one.

The exploitation status is the part of this story that deserves the most caution. As of publication, there is no public evidence that CVE-2026-29201, CVE-2026-29202, or CVE-2026-29203 have been used in the wild. That is a real fact, and it is also a fact that should not be confused with safety. CVE-2026-41940, the cPanel authentication bypass that watchTowr labs documented in such uncomfortable detail at the end of April, sat in production for months before anyone noticed it was being weaponized. By the time the Sorry ransomware crew had finished their work, more than forty-four thousand servers were either bricked, encrypted, or actively running Mirai botnet payloads. The pattern is not subtle. Attackers who already invested in cPanel exploitation tooling for the previous CVE will dissect the patches for these three within a week, work out which ones can be chained or used post-authentication, and start probing. Reseller accounts, MSP-managed WHM panels, and shared hosting environments where customers can already log in are the most exposed surface area.

Most cPanel servers do not get the same attention as enterprise edge appliances. They run quietly in budget hosting providers, in MSP racks, in legacy single-tenant servers running customer e-commerce sites that no one has touched since 2019. The patch-or-perish reality of this advisory is that the smaller and less staffed the environment, the more likely the operator did not see the email and is still running an ancient build their customer demanded. Those are the systems that will end up on a Mirai operator's target list two weeks from now.

Detection guidance for these specific bugs is light because there are not yet public proof-of-concept exploits to fingerprint. The general case still applies. Watch for unexpected processes spawned by cpaneld, dovecot-auth, or the WHM web user, particularly long-running shells or interpreter processes that have no business being there. Audit your cPanel access logs for create_user API calls from sources that do not match your normal management plane, and pay particular attention to any plugin parameter values that look like Perl code rather than a plugin name. File integrity monitoring across /usr/local/cpanel and /etc, with alerts on permission changes to anything in /etc/security, /etc/sudoers.d, /var/cpanel, or world-readable transitions on anything containing the words "key" or "shadow," will catch the symlink chmod bug after the fact. After the fact is not great, but it is better than not noticing.

The broader picture for cPanel right now is that the platform is in the middle of an exploitation cycle that resembles what Ivanti and Fortinet have been living through for years. The customer base is enormous, the install base is sticky, the patch cadence is now visibly accelerating, and threat actors have stopped treating cPanel as a soft target only worth automated mass scanning. They are reading TSR notes, dissecting the patch diffs, and writing real tooling. Two emergency advisories in ten days is the kind of operational tempo that signals a vendor under sustained pressure.

For MSPs, this is one of those advisories where the offering practically markets itself. A managed cPanel patching service, with documented SLAs around emergency TSRs, is something every shared hosting reseller and small ecommerce operator should already be paying for and most of them are not. Add darkweb monitoring on the cPanel and WHM admin credentials your customers actually use, and you have a recurring revenue line that hangs directly off the news cycle. The post-incident conversation, after a customer comes to you with a Mirai-infected box because they ignored last week's TSR, is also a clean lead-in to a hardening engagement covering WHM admin allowlisting, Argus or osquery for file integrity monitoring, and basic egress filtering on the hosting subnet. None of that is hypothetical. cPanel customers have been getting popped in production for the last two weeks, and every one of those incidents is an unbooked services engagement waiting to happen.

Patch every cPanel and WHM box you operate today. Verify the build afterward instead of trusting the run summary. Rotate any reseller and admin credential that has touched a vulnerable instance in the last month, especially anything with WHM root equivalence, and audit your create_user API call logs for anything that looks unusual. The three new CVEs are not the end of the cPanel story for May 2026. They are the second installment of one that has more chapters coming, and the customers who treat each TSR as an emergency rather than a suggestion are the ones whose servers will still be theirs in June.