Three cPanel Patches and DirtyFrag Fixes in One Day. Here Is Where Things Stand.

If your server runs cPanel on Linux, May 8 required patching at two separate layers simultaneously. cPanel published technical details and fixes for three new vulnerabilities that had been pre-announced without details earlier that morning. On the same day, patches for DirtyFrag, the Linux kernel local privilege escalation disclosed on May 7 without CVE numbers or available fixes, began reaching stable repositories across major distributions. One set of patches closes gaps in the cPanel application layer. The other closes a gap that has existed in the kernel since 2017. Here is where both stand.

The April 28 cPanel Patch: Applied or Not?

The cPanel authentication bypass, tracked as CVE-2026-41940 (CVSS 9.8), was disclosed on April 28 with a patch available on the same day. In the weeks that followed, the Shadowserver Foundation confirmed at least 44,000 servers compromised. Censys separately identified more than 7,000 cPanel and WHM hosts with artifacts consistent with a Go-based Linux ransomware strain, dubbed .sorry, on disk. The ransomware encrypts files in compromised home directories and web roots, appends the .sorry extension, and directs victims to contact operators via Tox messenger.

For any provider running cPanel, the April 28 patch is now overdue. Applying it closes the specific entry point, but a server compromised during the open window requires a separate investigation. The patch does not address anything that may have been installed on the server during the 64 days the flaw was actively exploited before disclosure.

The disclosure approach cPanel used for the May 8 CVEs was an explicit departure from the handling of CVE-2026-41940. For the May 8 batch, the company pre-announced that patches were coming without releasing technical details, then published both the patches and the full vulnerability information simultaneously. For CVE-2026-41940, no advance notice preceded the disclosure of an already-active exploitation campaign. The three new CVEs do not appear to have been exploited before the patch was available.

May 8: What the Three New cPanel CVEs Actually Are

CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203 were patched on May 8 at 12:00pm EST as announced. All three require an attacker to hold a valid account on the server. The technical details published alongside the patches describe three distinct vulnerabilities at different severity levels.

CVE-2026-29201 (CVSS 4.3, Medium) is an insufficient input validation flaw in the feature::LOADFEATUREFILE adminbin call. A relative path can be passed as the argument to make an arbitrary file world-readable. The attack requires an authenticated session, but the consequence, arbitrary file read, is broader than the Medium score suggests in environments where sensitive configuration data is stored in reachable paths.

CVE-2026-29202 (CVSS 8.8, High) is a Perl code injection vulnerability in the create_user API call via the plugin parameter. An authenticated attacker can execute arbitrary Perl code with the privileges of the authenticated account’s system user. This is a remote code execution path that requires authentication, which keeps the CVSS at 8.8 rather than 9.x, but the practical bar for exploitation on any server where attacker-controlled accounts exist is low.

CVE-2026-29203 (CVSS 8.8, High) is an unsafe symlink handling flaw that allows an authenticated user to chmod an arbitrary file via a crafted symlink. The documented consequences are denial-of-service or privilege escalation depending on which file is targeted.

A sequence using CVE-2026-29201 for reconnaissance, CVE-2026-29202 for code execution, and CVE-2026-29203 for privilege escalation is plausible from a single authenticated account. Whether this chain has been assembled in the wild is not yet documented.

Providers running auto-updates on cPanel’s recommended tier should have received these patches automatically on the day of release. Those on manual update schedules need to apply them explicitly.

DirtyFrag: CVE Numbers Assigned, Patches Available

DirtyFrag was disclosed publicly on May 7 with no CVE numbers and no patches for any distribution. Both of those conditions changed on May 8. The two underlying vulnerabilities have now been assigned official identifiers: CVE-2026-43284 covers the IPsec ESP path in the xfrm subsystem (CVSS 8.8), and CVE-2026-43500 covers the RxRPC module (CVSS 7.8). The absence of CVE numbers in the first 24 hours after disclosure was not a technicality: without identifiers, vulnerability scanners and patch management systems had nothing to match against. Organizations relying on automated tooling to surface DirtyFrag during that window would not have seen it flagged.

DirtyFrag sits at the operating system layer beneath cPanel. A server can be fully updated on cPanel and still be vulnerable if the underlying Linux kernel has not been patched. The two patch tracks are independent and both need to be applied.

Patch availability as of May 12, 2026:

• Red Hat Enterprise Linux 8, 9, and 10: patches available in main repositories as of May 8. A standard dnf update kernel installs the fix.
• AlmaLinux 8, 9, and 10: patched kernels rolled to production repositories May 8 at 15:22 UTC. AlmaLinux 8 requires kernel-4.18.0-553.123.2.el8_10 or newer; AlmaLinux 9 requires kernel-5.14.0-611.54.3.el9_7 or newer; AlmaLinux 10 requires kernel-6.12.0-124.55.2.el10_1 or newer.
• CloudLinux 8, 9, and 10: patches available. CloudLinux 7 Hybrid is affected and should be treated as the el8 family for remediation. Standard CloudLinux 7 is not affected.
• Ubuntu, all supported LTS versions from 14.04 onward: fixes available through standard kernel image package updates, rolling out via stable update channels.
• Fedora, Debian, and openSUSE: patches in progress. Apply the latest available kernel package from the respective distribution’s security update channels.

For providers using KernelCare for live kernel patching without reboots: patches for the RHEL 8 family, covering CL7h, CL8, and AlmaLinux 8, were promoted to the main feed on May 8. RHEL 9 family livepatches became generally available by May 11. To confirm a server is patched via KernelCare, the command kcarectl --info | grep kpatch-build-time should return a date of May 8, 2026 or later.

The module blacklist mitigation published when DirtyFrag was first disclosed, blacklisting esp4, esp6, and rxrpc via modprobe, remains effective for servers where a kernel reboot is not immediately possible. The caveat applies: IPsec VPN tunnels via strongSwan or Libreswan will break if those modules are blacklisted. On servers where a patched kernel is available, the kernel update is the correct remediation. The blacklist is a temporary measure for environments where rebooting into the patched kernel requires a maintenance window.

Microsoft published a parallel advisory on May 8 confirming that DirtyFrag is actively being used in attacks on hybrid and cloud-connected Linux workloads. The advisory does not change the remediation path but confirms that exploitation has moved beyond the initial proof-of-concept publication.

Three Patch Tracks to Confirm with Your Provider

For businesses whose websites and data sit on shared hosting infrastructure, none of these patches can be applied on the customer side. Three separate confirmations are needed from the provider:

• CVE-2026-41940 (cPanel, April 28): the authentication bypass patch
• CVE-2026-29201, CVE-2026-29202, CVE-2026-29203 (cPanel, May 8): the three authenticated-access patches
• CVE-2026-43284 and CVE-2026-43500 (Linux kernel, DirtyFrag): the kernel patch for the distribution in use, with confirmation of which distribution and version the server runs

A provider unable to confirm all three in writing has not completed the remediation. For businesses whose providers were confirmed affected by the April campaign, patch verification is the second step. The first is confirming that backups taken before the compromise window are intact and accessible. Patching stops future exploitation of these specific flaws. It does not reverse what may have happened during the period the original vulnerability was open.