The Floor Keeps Dropping: DirtyFrag & Three More cPanel CVEs

By Salvador Aguilar, Threat Research Manager — Monarx

A week ago I wrote that it had been "two bad weeks for the stack underneath your website." That framing was generous. Today, May 8, the situation is materially worse than it was when that post went up — and I want to be honest with the people reading this about what's happening, what we're doing, and where we can help.

In the space of about thirty-six hours, three things have landed on top of an already-stretched industry:

1. DirtyFrag, a second Linux kernel local privilege escalation, public as of yesterday, with a working exploit, CVE-2026-43284 , major distributions actively working on patches, and — this is the part that matters — ⚠️the mitigation everyone applied for Copy Fail does not block it.
   
   
2. Three new cPanel & WHM vulnerabilities (CVE-2026-29201, CVE-2026-29202, CVE-2026-29203) have been patched today. This comes ten days after CVE-2026-41940 and the two months of in-the-wild exploitation that preceded it.
   
   
3. Continued exploitation of the issues we already knew about — Copy Fail variants are still showing up on customer infrastructure, and CVE-2026-41940 will keep being exploited against unpatched cPanel installs for as long as those installs exist.

‍

This is, frankly, a brutal stretch for security and engineering teams in the hosting industry. I want to walk through what's new, share what we sent our customers earlier this week, and make a direct offer to our hosting partners about how we can help.

DirtyFrag — same blast radius as Copy Fail, with two complications

Researcher Hyunwoo Kim (@v4bel) reported DirtyFrag through coordinated disclosure on April 29 with an embargo set to expire May 12. On May 7, an unrelated third party broke the embargo by publishing part of the exploit. Kim released the full write-up on May 8 rather than let a partial, potentially misleading disclosure stand. Webhosting.today has a clear walkthrough of the disclosure timeline and technical details if you want the full picture.

The technical shape will feel familiar to anyone who read our Copy Fail piece. DirtyFrag is a local privilege escalation in the Linux kernel — any unprivileged user with the ability to execute code on the machine can become root on a single command. It chains two separate kernel bugs in the network encryption path (xfrm/IPsec, present since January 2017; RxRPC, present since June 2023) to give itself a write-anywhere primitive against on-disk files. Kim's exploit uses that primitive to either overwrite /usr/bin/su with shellcode or strip the password requirement from the root entry in /etc/passwd. Either route produces a root shell on the first attempt, deterministically, with no timing dependency and no kernel crash on failure.

It affects CloudLinux, Ubuntu, RHEL, Fedora, CentOS Stream, AlmaLinux, and openSUSE Tumbleweed — which is to say, essentially every distribution running production hosting infrastructure today.

Two complications matter, and they're both bad:

The Copy Fail mitigation does not help. A lot of operators responded to Copy Fail by blacklisting the algif_aead kernel module — a clean, low-risk mitigation that preserved most operational use cases. DirtyFrag uses entirely different code paths. If you're sitting on algif_aead-blacklisted servers thinking you've handled the kernel-LPE risk, you haven't. The interim DirtyFrag mitigation is to additionally blacklist esp4, esp6, and rxrpc — but that breaks IPsec VPN tunnels running on strongSwan or Libreswan. Operators running IPsec infrastructure now have a real tradeoff to make: lose the tunnels and close the kernel hole, or keep the tunnels and wait for patched kernels. There is no comfortable answer.

‍

The CVEs are assigned, and distributions are rushing to publishing patches and instructions. DirtyFrag now has CVE-2026-43284 for the xfrm/IPsec bug and CVE-2026-43500 for the RxRPC bug, so vulnerability scanners and patch-management systems have something concrete to track against. Patches have been submitted to the Linux kernel mailing list, and the major distributions are publishing advisories and working on shipping fixes:

• CloudLinux — Dirty Frag mitigation and kernel update
• Ubuntu — Dirty Frag Linux vulnerability fixes available
• Red Hat — RHSB-2026-003
• AlmaLinux — Dirty Frag advisory
• openSUSE — Dirty Frag security flaw discussion

If you run hosting infrastructure on any of these, treat the corresponding advisory as your authoritative source for patch availability and timing on your specific kernel branch. The work to roll patched kernels out across a fleet is still substantial — but at least the tracking infrastructure is in place, which is more than we could say twelve hours ago.

‍

Three new cPanel CVEs landed today

This morning, cPanel issued advance notification that three vulnerabilities — CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203. At the time of this writing, they have been patched as we can learn from their changelogs. Our friends at Webhosting.today have the operator notification details and what's currently known.

cPanel stated it delayed the disclosure of  to avoid handing attackers a roadmap before defenders have a fix. After the disclosure history of CVE-2026-41940 — sixty-four days of in-the-wild exploitation before any public advisory — that posture is, in my view, the right call. Knowing a patch is coming without yet knowing what it fixes is meaningfully more defensible than the inverse.

What we sent customers about Copy Fail — and what's still useful for DirtyFrag

Earlier this week we sent Monarx customers a follow-up to our Copy Fail notification with practical guidance for using the Monarx platform to assess and respond to root-level malware activity on affected servers. The core of it is worth restating publicly because most of it applies just as cleanly to DirtyFrag — the post-exploitation footprint of a kernel LPE is the kernel LPE; what changes is how attackers got there, not what they leave behind.

Surface root-owned malware in the directories you're already scanning. Within the paths Monarx is configured to monitor, the dashboard already gives you the views you need. The "Most Infected Users" list filtered by file.owner: root surfaces hosts with root-owned core AV detections. The "Files" view filtered for recently created malicious or compromised files owned by root surfaces what's actively landing on your environment. These are the first views to check when you're trying to understand whether a given server has been touched.

Expand scan coverage for servers where you need deeper visibility. Our agent's default paths cover the directories where customer websites and applications live. They do not, by default, scan everything. For servers you suspect have been compromised at the root level — whether through Copy Fail, DirtyFrag, the cPanel auth bypass chained into a root pivot, or anything else — Monarx can be configured to look at additional root-owned and system-level paths. There's an Advanced Agent Configuration guide in our support docs for the specifics.

‍

A few things to understand before you expand coverage:

• We can identify and help remediate malicious files on disk. We cannot un-root a compromised server. That distinction matters. Monarx is one tool in a broader incident response — important, but not the whole picture.
• Scanning everything (/) increases server overhead. We monitor for changes and re-scan accordingly, which gets expensive in directories with high file activity. Scope coverage back down once the affected areas have been addressed, and exclude virtual filesystem and device-node paths like /proc, /sys, and /dev — they yield no security value and significant overhead.
• Active Protection extends to expanded paths. If a server is eligible for AP, our agent will clean and quarantine filesystem malware in any of the enabled locations.
• We do not terminate root-owned processes. We can still find and help remediate on-disk issues, but root-owned processes need to be checked separately. For DirtyFrag in particular — where the exploit ends with an attacker holding a root shell — this matters. The artifacts on disk are findable; the active session is something you'll need to identify and kill through other means.

On fully rooted servers, the industry best practice is to restore from a known-good backup and repopulate with known-safe data. I know that isn't always immediately feasible. Monarx can help bridge the gap with on-disk cleanup while you're staging that work, but a rooted server may have persistence well beyond files alone — active processes, in-memory implants, stolen credentials, kernel-level modifications — and those need to be addressed as part of a real IR process.

An offer to our hosting partners

I want to be direct with the hosting providers reading this.

Your security teams and engineering teams are working twice as hard right now. You're patching kernels. You're patching cPanel — twice in ten days, with another patch landing in a few hours. You're triaging customer reports of compromised sites. You're trying to figure out which of your servers have already been touched during the months of CVE-2026-41940 in-the-wild exploitation that nobody knew about. You're explaining to your customers why the floor keeps dropping. That's a lot. We see it.

If your team is dealing with post-exploitation on machines that may have been rooted via Copy Fail, DirtyFrag, the cPanel auth bypass, or some combination — Monarx is willing to help. Specifically, we can assist with:

• Finding the malware that got dropped. Webshells, backdoors, modified system binaries, malicious cron entries, persistence mechanisms in user directories. The on-disk artifacts that survive after the attacker is done.
• Identifying cryptominers. XMRig variants and the broader family of mining payloads that follow root compromises on shared hosting are something we see often enough to recognize quickly.
• Surfacing backdoors planted at the application layer. Modified WordPress core files, malicious mu-plugins, theme-file injections, fake admin users, suspicious modifications to wp-config.php.
• Helping you scope the blast radius. When you've got a rooted host in shared hosting, the question isn't just "what did the attacker do here" — it's "which of these tenants did they touch." We have experience with that triage.

This is what we do every day, and right now is when that experience is most useful to the people running this industry. If you're a Monarx customer, reach out to your account team or contact us directly. If you're not a customer and you're staring at a stack of compromised servers wondering where to start, reach out anyway. We'll find a way to help.

A note for the people doing the work

I'll close with something I rarely write in a post like this. The disclosure timing of the past two weeks has been genuinely difficult — DirtyFrag's broken embargo, the cPanel exploitation window we didn't know about, the kernel patch lag, the triage work piling up on teams that were already stretched. None of that is anyone's fault in particular, and all of it lands on the same people: the security and operations engineers keeping hosting infrastructure running.
‍
Thank you for the work. It's not invisible to us. 🙏‍

We'll keep tracking what's in the wild. We'll keep updating our detection logic. And we're available if you need a hand.

‍