Eight days after Copy Fail shook the Linux server world, another critical vulnerability has arrived — and this one also hands root access to anyone who can run code on your server.

It is called “Dirty Frag”. It was publicly disclosed on May 7, 2026. A working exploit already exists. And if your server has not been patched and rebooted since May 8, it is vulnerable right now.

What is Dirty Frag?

Dirty Frag is the informal name for a chained exploit that combines two Linux kernel vulnerabilities: CVE-2026-43284 and CVE-2026-43500. The first one is already patched; the second is still being rolled out to distributions as of this writing.

The root cause of CVE-2026-43284 lies in how the Linux kernel handles network packet memory in the IPsec/ESP path. When MSG_SPLICE_PAGES attaches pages from a pipe directly to a network buffer (skb), the IPv4/IPv6 datagram paths failed to mark those pages as shared.

This left an ESP-in-UDP packet made from shared pipe pages appearing to the kernel like an ordinary, privately-owned buffer — so ESP decryption would happen in-place directly over memory the skb does not own. An attacker who knows how to manipulate this behavior can achieve a controlled write into the kernel page cache and ultimately escalate to root.

In plain terms: the kernel trusted memory it should not have trusted, and an attacker can use that misplaced trust to take over the entire machine.

Unlike the previous DirtyPipe vulnerability, which relied on a narrow race condition in pipe buffer flag handling, Dirty Frag is a deterministic logic flaw. Researcher Hyunwoo Kim reports very high success rates and minimal kernel panic risk, with no timing window to lose. This makes it unusually reliable as exploits go.

How it connects to Copy Fail

Copy Fail (CVE-2026-31431), disclosed on April 29, exploited a logic bug in the Linux kernel’s cryptographic subsystem — specifically a flaw in the authencesn AEAD template that allowed a controlled 4-byte write into the kernel page cache. A 732-byte Python script was enough to gain root on every major Linux distribution built since 2017.

Dirty Frag follows the same fundamental pattern — a page cache write primitive turned into a root escalation — but through a completely different code path. Both vulnerabilities turn long-lived in-place processing optimizations into deterministic root primitives: Copy Fail through userspace crypto, Dirty Frag through IPsec receive.

The connection is not accidental. Researcher Hyunwoo Kim explicitly built on the bug class that Copy Fail introduced. Some in the security community have already started referring to CVE-2026-43284 as “Copy Fail 2.0.” What was presented as a rare kernel bug ten days ago is becoming a repeatable class of attack.

An interesting factor of Dirty Frag is that chaining the two sub-vulnerabilities (CVE-2026-43284 and CVE-2026-43500) covers each other’s blind spots. Neither flaw alone provides a sufficiently reliable primitive for full root escalation. However, when combined, the chained exploit achieves immediate root on most distributions.

Who is affected?

Every server running a mainstream Linux kernel built from roughly 2017 onwards is affected. Every supported AlmaLinux release is affected. CVE-2026-43284 affects AlmaLinux 8, 9, and 10 through the esp4/esp6 modules, which are part of the standard kernel package on every release.

The full list of affected distributions includes Red Hat Enterprise Linux, AlmaLinux, Debian, Ubuntu, Fedora, Arch Linux, CentOS, CloudLinux, and Amazon Linux.

For web hosting environments specifically, the threat vector is the same as Copy Fail: the attacker does not need to break in remotely. The danger is that once an attacker gets in — through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container — Dirty Frag lets them immediately escalate to root and then disable security tools, read credentials, tamper with logs, move laterally, or persist on the server.

On shared hosting servers, a single compromised account could become a full server compromise.

The fix — step by step

Step 1: Update the kernel

Patched kernels are now available in production repositories as of May 8, 2026. This is the only real fix.

For AlmaLinux, CloudLinux, Rocky Linux, CentOS Stream, RHEL:

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

For Debian / Ubuntu:

sudo apt update && sudo apt upgrade
sudo reboot

For CloudLinux with KernelCare (no reboot required):

kcarectl --update

After rebooting, confirm you are running the patched kernel:

uname -r

Compare the output against the patched version in your distribution’s security advisory before considering the server protected.

Step 2: Interim mitigation (if you cannot reboot immediately)

If a reboot is not immediately possible, you can block the vulnerable modules from loading. The Dirty Frag technical writeup offers a mitigation that removes the modules containing the vulnerabilities and clears the page cache:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches

Important before applying this: verify that your server does not use IPsec VPN tunnels, site-to-site encrypted networking, or Kubernetes network policies that depend on esp4 or esp6. Disabling these modules on a server with active IPsec will break those connections. If in doubt, apply the kernel update instead.

After the patched kernel is installed and the server is rebooted, revert the mitigation by removing the /etc/modprobe.d/dirtyfrag.conf file.

Step 3: Combine with Copy Fail remediation

If you have not yet addressed Copy Fail (CVE-2026-31431), treat both vulnerabilities as a combined remediation effort, given their similarity and overlapping mitigation steps. A single kernel update and reboot covers both. Check that your running kernel is patched for both CVE-2026-31431 and CVE-2026-43284 before considering the server clean.

What this means going forward

Two universal Linux kernel privilege escalation vulnerabilities in eight days is not normal. Dirty Frag is the second in this period, following Copy Fail. With a working public proof-of-concept released ahead of patches and exploitation reduced to a handful of standard syscalls, defenders should assume any local foothold on an unpatched host can become root within seconds.

The disclosure of Dirty Frag also went badly: an unrelated third party leaked the exploit details before distributions had finished packaging patches, forcing a premature public disclosure while CVE-2026-43500 was still unpatched. This is the same pattern that made Copy Fail so dangerous in its first hours.

The practical lesson is that the time between a vulnerability being known to attackers and being exploited in the wild is now measured in hours, not days. Kernel updates must be treated with the same urgency as application security patches — applied as soon as they are available, not during the next scheduled maintenance window.

For any server running web hosting workloads: patch today, reboot, verify. Then set up alerting so the next time this happens, you know within the hour.

Sources

Help Net Security: https://www.helpnetsecurity.com/2026/05/08/dirty-frag-linux-vulnerability-cve-2026-43284-cve-2026-43500/

AlmaLinux security advisory: https://almalinux.org/blog/2026-05-07-dirty-frag/

Tenable Research FAQ: https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe

Sysdig detection guide: https://www.sysdig.com/blog/dirty-frag-cve-2026-43284-and-cve-2026-43500-detecting-unpatched-local-privilege-escalation-via-linux-kernel-esp-and-rxrpc

SUSE CVE entry: https://www.suse.com/security/cve/CVE-2026-43284.html

Ubuntu CVE page: https://ubuntu.com/security/CVE-2026-43284

Ubuntu blog (fixes available): https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

CloudLinux blog (Dirty Frag): https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update

Knightli mitigation guide: https://www.knightli.com/en/2026/05/09/dirty-frag-cve-2026-43284-linux-lpe-mitigation/