cPanel Pre-Discloses Three New CVEs (CVE-2026-29201, 29202, 29203) — Second Emergency TSR in 10 Days

On May 7, 2026, cPanel sent another TSR pre-disclosure email to registered customers — the second such emergency notice in ten days. Three new CVEs (CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203) are scheduled for patch release on May 8, 2026, at 12:00 EST. This comes directly on the heels of CVE-2026-41940, a CVSS 9.8 auth bypass that spent nearly three months in active exploitation before cPanel issued a fix. The hosting industry's confidence in legacy control panels is being tested in real time.

What just happened: cPanel's pre-disclosure email

cPanel has used a standardized TSR (Technical Security Release) pre-disclosure format since 2019. When a qualifying vulnerability is identified and a patch is ready for scheduled release, cPanel notifies registered customers in advance so they can prepare: update windows, maintenance notices, and manual intervention plans. This is normal procedure — the CVE numbers are reserved through Mitre, but full NVD entries and severity details are typically published at the moment the patch goes live, not before.

What the May 7 pre-disclosure tells us:

• CVE-2026-29201, CVE-2026-29202, CVE-2026-29203 — Three distinct vulnerabilities across the cPanel/WHM stack. Details are embargoed until patch release.
• Patch date and time: May 8, 2026, 12:00 EST. cPanel's automated update system will distribute the fix through the usual tier mechanism.
• Manual update path: If your server does not have automatic updates enabled, or if you are on a pinned tier, run /scripts/upcp from the command line after 12:00 EST on May 8.
• CloudLinux 6 note: If your server runs CloudLinux 6, verify your tier setting before patching. The recommended adjustment is: sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf — then proceed with /scripts/upcp.

As with all TSR pre-disclosures, no technical exploitation details will be released before the patch ships. If you are on automated updates, your servers should receive the fix automatically once cPanel pushes the release through the tier pipeline.

The bigger picture: two emergency TSRs in ten days

To understand why this second TSR landing in such quick succession matters, it helps to look back at what happened on April 28, 2026.

CVE-2026-41940 was classified CVSS 9.8 — the near-maximum score reserved for unauthenticated remote exploits with high impact across confidentiality, integrity, and availability. The vulnerability was rooted in CRLF injection that allowed an unauthenticated attacker to poison session files, effectively bypassing authentication entirely on affected cPanel/WHM installs. The exploitation window was not days or weeks — 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 consequences were documented and severe:

• Compromise estimates exceeded 44,000 servers, with the cPanelSniper proof-of-concept driving mass exploitation.
• Mirai botnet variants leveraged the vulnerability to recruit new nodes.
• Ransomware operators deployed ".sorry" extension payloads across affected hosting infrastructure.
• CISA added CVE-2026-41940 to the Known Exploited Vulnerabilities (KEV) catalog, with a mandatory remediation deadline of May 3, 2026 for Federal Civilian Executive Branch (FCEB) agencies.
• Exposed attack surface included ports 2083 (cPanel), 2087 (WHM), 2095, and 2096 — the standard cPanel management ports that tens of thousands of hosting servers leave open by default.

Ten days after that crisis, a second pre-disclosure arrives with three more CVEs. Even if CVE-2026-29201 through 29203 turn out to be lower severity than CVE-2026-41940, the pattern itself is the story. When a platform's security posture requires two emergency TSRs within a two-week window, something structural is at work — not just an isolated bug.

Monolithic hosting panels built on decades-old foundations are showing the strain. 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. When authentication logic, session management, and privileged system calls all live in the same runtime context, a single injection flaw can unravel the entire security model. That is the class of bug CVE-2026-41940 represented. It is not the kind of vulnerability you patch once and forget.

Affected versions and update paths

cPanel's full TSR post — with specific minor version numbers and CVSS scores for each of the three new CVEs — will be published at patch time on May 8, 2026. Until then, the specific branch and minor version details remain under embargo.

For reference: CVE-2026-41940 affected cPanel branches 11.132.x, 11.134.x, and 11.136.x across the RELEASE, CURRENT, and EDGE tiers. The May 8 patch is expected to follow a similar pattern, addressing vulnerabilities across multiple active branches simultaneously. Watch cPanel's TSR disclosure post on May 8 for the exact version matrix.

General guidance before the patch lands:

• Identify which cPanel tier your servers are on: RELEASE, CURRENT, or EDGE. Each has a separate update stream.
• Confirm whether automatic updates are enabled. Servers with CPANEL auto-update set to never or pinned to a specific build will not receive the patch automatically.
• Schedule a maintenance window for May 8 starting at 12:00 EST in case manual intervention is required.

What server operators should do right now

1. Review /etc/cpupdate.conf — Check whether CPANEL is set to a tier name (RELEASE, CURRENT) or a pinned build number. Pinned builds will not auto-update. If you are pinned, you must run /scripts/upcp manually.
2. Verify your current cPanel version tier — Run whmapi1 get_tier from the command line to confirm what tier is active and whether it is scheduled for the May 8 update.
3. CloudLinux 6 servers — Before patching, run: sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf to set the correct tier for CloudLinux 6 environments, then proceed with /scripts/upcp.
4. At 12:00 EST on May 8 — If your server is on automatic updates, monitor the update log. If not, run /scripts/upcp immediately after the patch window opens. After the update completes, restart cpsrvd and verify the installed version matches the expected patched build.
5. Interim hardening (before the patch) — If you cannot apply the patch immediately or need time to verify, consider: adding WAF rules to inspect requests on ports 2083, 2087, 2095, and 2096; restricting access to those ports by IP at the firewall level if your operational setup allows it; and ensuring fail2ban or equivalent brute-force mitigation is active and correctly configured.
6. Subscribe to cPanel's TSR mailing list — If you are not already receiving TSR pre-disclosures, sign up through your cPanel account portal. Pre-disclosure emails give you hours of lead time to prepare update windows and mitigation steps before a patch goes public.

Why monolithic hosting panels keep getting hit

It is worth stepping back from the immediate patching guidance and asking a structural question: why does this keep happening?

cPanel's codebase has its roots in the late 1990s. Its core daemons — cpsrvd, whostmgrd — are a mixture of Perl and PHP that has accumulated decades of features, workarounds, and compatibility layers. That heritage is not inherently a problem, but it creates specific architectural challenges that modern security engineering has largely moved away from:

• Single root execution context. Many cPanel operations run as root or rely on setuid helpers with broad privileges. When a vulnerability allows unauthenticated access to these execution paths, the blast radius is the entire server.
• Session and auth logic co-located with privileged operations. The CRLF/session-file class of bug that enabled CVE-2026-41940 exists because session management and privileged system calls share the same execution environment. A parsing error in session handling becomes a root access vector.
• Wide default attack surface. Management ports (2083, 2087, 2095, 2096) are open by default and expected to be internet-accessible. There is no architectural segmentation between the management plane and the data plane.
• Plugin and extension ecosystem. Third-party plugins operate within the same trust boundary as core cPanel code. A vulnerability in a popular plugin is effectively a cPanel vulnerability.

None of this makes cPanel's developers careless or incompetent. It reflects the difficulty of evolving a 25-year-old codebase while maintaining compatibility with millions of production servers. But it does explain the pattern of recurring, high-severity TSRs.

A note on architecture: how Panelica handles this class of risk

Panelica was designed from scratch in Go, with a different threat model than legacy PHP/Perl panels. The backend is a single compiled binary — no interpreter, no script execution path that can be poisoned by CRLF injection. Authentication and session management use JWT with a 15-minute access token lifetime plus an HTTP-only refresh token, with optional TOTP 2FA — there are no session files on disk that can be poisoned. Every user runs in a 5-layer isolation stack: cgroups v2 for resource boundaries, Linux namespaces for filesystem isolation, SSH chroot jails, per-user PHP-FPM pools with open_basedir enforcement, and strict Unix permissions. The management panel runs on a dedicated port (8443) with its own nginx instance, fully separate from customer traffic. The structural class of vulnerability that produced CVE-2026-41940 — session file poisoning via CRLF injection in a Perl/PHP daemon — does not exist in Panelica's architecture. That said, no software is invulnerable, and we do not make that claim. What we can say honestly is that Panelica is structurally less exposed to this specific class of legacy-architecture bugs. If you are currently evaluating alternatives as part of your infrastructure risk review, modern Go-based panels are worth a serious look.

Bottom line

Three things matter here in order of urgency:

1. Do not miss the May 8, 12:00 EST patch window. If your cPanel servers are on automatic updates, verify the setting is active and unobstructed. If they are on pinned builds or have auto-update disabled, schedule a manual /scripts/upcp run for that window. This is not optional — given what the industry saw with CVE-2026-41940, waiting even a day after patch availability carries real risk.
2. Treat this as a pattern, not an incident. Two emergency TSRs in ten days is not a statistical anomaly. It reflects the ongoing security cost of running monolithic, legacy-architecture hosting software on internet-facing infrastructure at scale. Whether you run cPanel for five servers or five hundred, this pattern deserves a place in your risk review conversations.
3. Stay subscribed to TSR notifications. cPanel's pre-disclosure process gives operators valuable lead time. Make sure everyone responsible for server maintenance is on the list before the next advisory lands.

We will update this post once cPanel publishes the full TSR with confirmed CVSS scores and affected version details on May 8.

Further reading

• cPanel Auth Bypass Crisis (CVE-2026-41940): Why Panelica Customers Are Not Affected — Panelica Security Desk
• Inside CVE-2026-41940: The cPanel Vulnerability Behind the .sorry Ransomware Campaign — Panelica Blog