cPanel Patches Three New Vulnerabilities Enabling Code Execution and DoS – Update Your Installations

Ten days. That’s how long it took cPanel to issue a second emergency patch after the worst attack on its platform in recent memory. On May 8, the company pushed fixes for three newly disclosed vulnerabilities – CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203 covering its cPanel & WHM control panel and WP Squared (WP2) platform. Two of the three score 8.8 on the CVSS scale, putting them firmly in the High severity tier.

If you run cPanel on any server, you need to patch it now.

What Got Found, and Why It Matters

CVE-2026-29202 – Perl Code Injection (CVSS 8.8)

This is the most dangerous of the three. The flaw is an insufficient input validation of the plugin parameter in the create_user API call, and it allows arbitrary Perl code to execute on behalf of the already authenticated account’s system user.

To understand why that’s serious, you need to understand where this runs. cPanel is implemented primarily in Perl, and its daemon (cpsrvd) handles requests with elevated system privileges. Perl code running in the context of cPanel has significant system-level access. On a shared hosting server, this means one tenant can potentially run code that affects the entire machine. The attacker doesn’t inject shell commands directly – they inject Perl expressions that get evaluated inside the create_user call’s execution context, bypassing the intended logic entirely. Because the code runs as the system user associated with the hosting account rather than as an isolated process, standard Unix permission boundaries don’t fully contain it.

The practical attack flow: an authenticated user sends a crafted API request to /xml-api/createacct or the equivalent JSON-API endpoint with a malicious plugin value. If the input isn’t sanitized before being passed to Perl’s eval or an equivalent dynamic execution path, the injected code runs. From there, an attacker can read files, write files, establish persistence, or pivot toward root, especially if chained with CVE-2026-29203.

Authentication is required, but on shared hosting, that bar is low – any account holder on the box qualifies.

CVE-2026-29203 – Unsafe Symlink Handling / Privilege Escalation (CVSS 8.8)

This flaw involves how cPanel handles symbolic links during chmod operations. By creating a symlink pointing to a sensitive system file and triggering a chmod operation through cPanel, an attacker can change permissions on files they should not be able to touch which leads to privilege escalation or denial of service if system files are rendered inaccessible.

The mechanics are a classic symlink race: cPanel’s privilege-escalation daemon (part of the suidperl or setuid helper infrastructure) follows a symlink when applying chmod without first verifying that the resolved path is within an expected boundary. An attacker with write access to their own home directory creates a symlink, say, /home/attacker/target pointing to /etc/passwd or /etc/sudoers and then triggers a cPanel file permission operation on that path. The setuid helper executes chmod on whatever the link resolves to, not the link itself.

Used to make a sensitive file world-writable, this opens the door to full root compromise. Used destructively, it can break core system binaries or configuration files, taking the server offline entirely.

In combination with CVE-2026-29202, these two flaws could be chained: inject code via the Perl execution flaw to create or position the symlink, then trigger the chmod escalation to gain deeper access. That combination, on a multi-tenant shared host, amounts to a fairly complete server takeover path from a single unprivileged hosting account.

CVE-2026-29201 – Arbitrary File Read via Path Traversal (CVSS 4.3)

The flaw is insufficient input validation of the feature file name in the feature::LOADFEATUREFILE adminbin call. An authenticated attacker can manipulate the feature file name parameter to read files on the server they should not have access to.

adminbin calls are privileged IPC mechanisms in cPanel – they let the web-facing frontend invoke backend operations that require elevated permissions. The LOADFEATUREFILE call is supposed to read a specific feature configuration file by name. Without proper path canonicalization, an attacker can pass a value like ../../etc/passwd or ../../root/.ssh/id_rsa, and the adminbin helper reads and returns that file’s contents instead.

While this doesn’t directly grant root access, the information gathered, configuration files, credentials, internal paths can be used to stage more damaging follow-up attacks. In an environment where CVE-2026-29202 is also present and unpatched, CVE-2026-29201 becomes an effective reconnaissance tool: read SSH keys or database credentials first, then use the code injection path to act on that information.

In shared hosting environments where multiple tenants run on the same server, CVE-2026-29202 and CVE-2026-29203 together create meaningful exposure to lateral movement and full server compromise.

The Bigger Picture: This Isn’t a Coincidence

CVE-2026-41940 – the auth bypass that preceded all of this was CVSS 9.8. It was rooted in CRLF injection that let unauthenticated attackers poison session files and bypass authentication entirely. Security researchers confirmed it had been actively exploited as a zero-day since at least February 2026, roughly two and a half months before a patch was available.

The compromise estimates exceeded 44,000 servers, with the “cPanelSniper” proof-of-concept driving mass exploitation. Mirai botnet variants used the flaw to recruit new DDoS nodes. Ransomware operators deployed “.sorry” extension payloads across affected hosting infrastructure. CISA added CVE-2026-41940 to its Known Exploited Vulnerabilities catalog and set a May 3 remediation deadline for federal agencies.

Finding CVE-2026-29201, 29202, and 29203 right after CVE-2026-41940 isn’t bad luck. It’s the result of cPanel auditing their codebase under pressure and finding more problems. That’s actually how this is supposed to work after a major incident. The concern is what else that audit might turn up. There may be further disclosures to come.

The broader issue is structural: a PHP and Perl codebase that manages system-level operations, network configuration, DNS, email, and web server settings from a single daemon creates a large, interconnected attack surface. Monolithic hosting panels built on decades-old foundations are showing the strain.

How to Patch

For most servers, this is one command run as root over SSH:

/scripts/upcp --force

After it completes, verify the installed version:

/usr/local/cpanel/cpanel -V

After patching, restart cpsrvd to make sure the daemon is running the updated code: /scripts/restartsrv_cpsrvd

For CentOS 6 / CloudLinux 6 systems, you need to pin to the right update branch first:

sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf
/scripts/upcp --force

CentOS 6 hit end-of-life in 2020. This patch covers it, but it’s a stopgap. Migration to AlmaLinux or Rocky Linux is the only real answer long-term.

Affected versions and their minimum patched builds:

Common Questions

Are these being actively exploited? As of May 11, there are no confirmed cases in the wild. That will change if proof-of-concept code surfaces publicly and given how fast CVE-2026-41940 moved from disclosure to mass exploitation, that timeline can change fast.

What if I’m on managed hosting? Most managed providers (InMotion, KnownHost, HostGator, and others) push these patches automatically through their standard processes. Still worth a support ticket to confirm your server is actually running a patched build.

Can I block ports instead of patching? Restricting access to ports 2083 and 2087 reduces external exposure, but CVE-2026-29202 only requires an authenticated user, which in shared hosting means any customer on the box. Port blocking doesn’t help against that threat model.

What if I was already compromised? Audit access logs retroactively from February 23, 2026 – check /usr/local/cpanel/logs/access_log and /usr/local/cpanel/logs/login_log for unexpected session authentication patterns. Also run a recursive scan of user home directories for files with the .sorry extension. If you find them, you’re in incident response territory, not just patching territory. Rebuilding from a clean, verified off-site backup is the appropriate response at that point.

Two emergency patches in ten days is not a normal release cadence. Patch, verify, and keep watching the cPanel security mailing list.