CVE-2026-43284 Dirty Frag: One-Command Root on Every Linux Server Built Since 2017

TL;DR

A new Linux kernel local privilege escalation chain named Dirty Frag — tracked as CVE-2026-43284 (xfrm-ESP) and CVE-2026-43500 (RxRPC) — lets any unprivileged local user gain root with a single command. A working public proof of concept is already live, and Microsoft has confirmed limited in-the-wild exploitation. Every Linux kernel released since January 2017 is affected. Patch your kernels today, or apply the module blacklist mitigation if you cannot reboot.

What Is Dirty Frag?

Dirty Frag is a chain of two distinct Linux kernel bugs that share a common root cause in the in-place decryption path of three networking modules: esp4, esp6, and rxrpc. When the kernel receive path decrypts data over paged buffers that are not privately owned by the kernel — for example, pipe pages reaching a socket through splice(2), sendfile(2), or vmsplice(2) — an unprivileged process can keep references to the resulting plaintext. That gives the attacker a write primitive into the page cache, and from there straight to root.

The vulnerability was reported by security researcher Hyunwoo Kim (@v4bel) to upstream kernel maintainers on April 30, 2026. Technical details became public on May 7, 2026, and the embargo fully collapsed on May 8 when third parties published exploit details. The mainline ESP fix landed the same day as commit f4c50a4034e6.

The two CVEs in the chain:

• CVE-2026-43284 — the IPsec ESP half. Affects esp4 and esp6. Introduced in January 2017 by commit cac2661c53f3, which moved IPsec ESP receive into an in-place decryption fast path.
• CVE-2026-43500 — the RxRPC half. Introduced in June 2023 by commit 2dc334f1a63a. Affects systems where the rxrpc module ships and is loadable.

Researchers and several public write-ups also refer to Dirty Frag as CopyFail2 or "Copy Fail 2: Electric Boogaloo," because it follows the same conceptual playbook as the Copy Fail (CVE-2026-31431) bug published just days earlier.

Why It Matters For Hosting Servers

Local privilege escalation bugs are dangerous in any environment, but they are catastrophic on shared hosting and any server that allows untrusted local code execution. That includes:

• Shared hosting accounts with SSH or SFTP access
• WordPress, Joomla, or PHP application servers exposed to web shells
• Multi-tenant developer or staging boxes
• Container hosts where a container escape would otherwise be limited
• Low-privileged service accounts (www-data, nobody, nginx)

On any of these, Dirty Frag turns a contained foothold into full root in one step. There is no race window, no spraying, no heap grooming. As reported by security researchers analyzing the public proof of concept, the exploit relies only on standard syscalls (socket, setsockopt, bind, vmsplice, splice, sendmsg) and modules that ship enabled by default on every major enterprise distribution. As reported by Microsoft, attackers in the wild are already chaining SSH access with a small ELF dropper to escalate via su immediately after landing.

If you operate a hosting panel, a VPS fleet, or a multi-tenant Linux server, treat this as an emergency.

Affected Systems

Every supported Linux distribution is affected. The list below summarizes what we have verified from vendor advisories.

Distributions confirmed affected

• Ubuntu — 14.04 LTS, 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, 24.04 LTS, 25.10, and 26.04 LTS
• AlmaLinux — 8, 9, 10, and Kitten 10 (CVE-2026-43500 only impacts AL 9 and 10 when the kernel-modules-partner package is installed; AL 8 does not ship rxrpc)
• CloudLinux — CL7 Hybrid (CL7h), CL8, CL9, CL10. Plain CloudLinux 7 is not affected.
• RHEL 8, 9, 10
• Rocky Linux 8, 9, 10
• CentOS Stream 9, 10
• Fedora 43, 44
• Debian 11, 12
• openSUSE Leap and Tumbleweed
• Amazon Linux 2, 2023

If your kernel was built from a tree younger than January 2017, it is in scope for CVE-2026-43284. The RxRPC half (CVE-2026-43500) only matters where rxrpc is buildable and loadable.

Patched kernel versions

Distribution	Patched kernel (or newer)
AlmaLinux 8	kernel-4.18.0-553.123.2.el8_10
AlmaLinux 9	kernel-5.14.0-611.54.3.el9_7
AlmaLinux 10	kernel-6.12.0-124.55.2.el10_1
CloudLinux 7h / 8	kernel-4.18.0-553.123.2.lve
CloudLinux 9	kernel-5.14.0-611.54.3.el9_7
CloudLinux 10	kernel-6.12.0-124.55.2.el10_1
Ubuntu (all supported)	Ship via the regular kernel package update channel as of May 8, 2026

Always confirm the exact build with uname -r after the update.

How To Patch

Option 1 — Update the kernel and reboot (recommended)

This is the only complete fix.

RHEL / AlmaLinux / Rocky / CloudLinux / CentOS Stream / Fedora:

sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

Debian / Ubuntu:

sudo apt update
sudo apt full-upgrade
sudo reboot

Verification after reboot:

uname -r

Confirm the running kernel is at or above the patched version listed in the table above.

Option 2 — KernelCare livepatch (no reboot)

If you run KernelCare on CloudLinux, AlmaLinux, RHEL, Ubuntu, Debian, or any other supported distribution, the livepatch ships through the standard update channel and does not require a reboot. Trigger an immediate update with:

sudo kcarectl --update
sudo kcarectl --info

KernelCare livepatching is the cleanest path for production hosting nodes where downtime is expensive — patching a hundred shared hosting boxes one by one is not realistic during business hours.

Option 3 — Temporary mitigation (when patching now is impossible)

If you cannot patch and reboot immediately, blacklist the three vulnerable modules. Do not apply this on systems that actively use IPsec tunnels — it will break VPN connectivity.

sudo sh -c "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; true"

Then verify the modules are not loaded:

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules

The command should return nothing. If rmmod failed because the modules were in use, regenerate the initramfs and reboot:

sudo update-initramfs -u   # Debian / Ubuntu
sudo dracut -f             # RHEL / AlmaLinux / CloudLinux
sudo reboot

If you suspect the host was already compromised, also drop the page cache to remove any tampered pages:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This is not a substitute for forensics — if you see signs of exploitation, treat the host as compromised and rebuild.

What To Look For (Detection)

As reported by Microsoft, the in-the-wild attack pattern is:

1. Inbound SSH connection establishing an interactive shell
2. Drop and execute a small ELF binary (observed name: ./update)
3. Immediate escalation to root via the kernel exploit
4. Post-compromise: tampering with PHP session files, GLPI LDAP authentication files, and reconnaissance for sensitive data

Defensive signals to monitor:

• Unexpected setuid/setgid process launches from non-system paths (/tmp, /dev/shm, user homes)
• New ELF binaries written by web-server or shared hosting users immediately followed by an exec
• rxrpc, esp4, esp6 modules being autoloaded on hosts that have no IPsec or AFS workload
• Anomalous splice / vmsplice syscall patterns from unprivileged users
• Audit logs showing a non-root user transition into root sessions without a corresponding sudo event

Microsoft Defender users will pick up the public PoC as Exploit:Linux/DirtyFrag.A and .B, and observed droppers as Trojan:Linux/DirtyFrag.Z, .ZA, .ZC, and .DA!MTB.

Panelica-Specific Guidance

Panelica panels run on a hardened, isolated stack — every customer site lives inside its own cgroup slice, namespace, and chrooted SSH jail. That isolation does not make Dirty Frag harmless, but it does buy you containment and detection time:

• The host kernel is shared across every isolated tenant. Patching the host kernel is mandatory regardless of isolation.
• Panelica's panelica-user.slice cgroup tree limits CPU, memory, and PID counts per tenant, which raises the noise floor of an exploit attempt and makes it more visible.
• SSH chroot jails (sshjailed and sshfull) limit reach but do not block kernel-level exploits.
• ModSecurity and fail2ban rulesets in Panelica catch the common web-shell delivery paths that precede a Dirty Frag drop.

If you operate a Panelica node, the action list is:

1. Update the host kernel using your distribution's package manager.
2. If you cannot reboot during the maintenance window, apply the modprobe blacklist mitigation above (only if the node is not running IPsec).
3. Reboot the host. Confirm uname -r matches the patched build.
4. Review journalctl -k --since "2026-05-01" for unexpected esp4 / esp6 / rxrpc autoload events.
5. Re-run your audit and security review from the Panelica admin panel.

We are not changing Panelica's binary distribution in response to this CVE — Dirty Frag is a kernel issue, not a panel issue. The fix lives in your distribution's kernel package and in KernelCare.

Frequently Asked Questions

Is Dirty Frag a remote vulnerability?

No. Dirty Frag is a local privilege escalation. The attacker needs the ability to run code on the system, even as an unprivileged user. On hosting servers, that bar is low — every shared SSH account, every web shell, every container escape qualifies.

Does the modprobe blacklist mitigation break IPsec VPNs?

Yes. Blacklisting esp4 and esp6 will stop IPsec ESP traffic. If your server terminates an IPsec tunnel, do not apply that mitigation — patch the kernel and reboot instead.

Is KernelCare a complete fix or only a mitigation?

KernelCare livepatches are full fixes for the running kernel, equivalent in effect to installing the patched kernel package and rebooting. KernelCare livepatches do not require a reboot.

My distro is not on the affected list above. Am I safe?

Almost certainly not. Every Linux kernel that includes the 2017 ESP commit is affected. Check your kernel version against the upstream commits referenced earlier. If you cannot find a vendor advisory yet, apply the module blacklist mitigation while you wait.

How is Dirty Frag different from Dirty Pipe?

Both are deterministic page-cache write primitives, both are reliable, and both let unprivileged users escalate to root. Dirty Pipe (CVE-2022-0847) abused pipe buffer flags. Dirty Frag abuses in-place decryption over externally-backed pages in three different networking modules. Different code paths, same class of bug, same severity in practice.

Are containerized workloads safe?

Containers share the host kernel. A successful Dirty Frag exploit inside an unprivileged container will land you root on the host kernel, which in most container runtimes means a full host compromise. Patch the host.

Is shared hosting more at risk than a dedicated server?

Yes, materially. Shared hosting hands out unprivileged shell access by design. If even one tenant runs a vulnerable web application or weak SSH password, Dirty Frag turns that single foothold into root over every other tenant on the box.

Action Checklist

• Identify every Linux server in your fleet — including container hosts, build agents, and developer machines
• Patch the kernel to the version listed in the table above (or newer)
• If you run KernelCare, force a livepatch update with sudo kcarectl --update
• If you cannot reboot, apply the esp4 / esp6 / rxrpc blacklist (only if no IPsec is in use)
• Verify with uname -r after reboot
• Review SSH and web logs for the past two weeks for the attack pattern documented above
• Drop the page cache on any host you suspect was tampered with, and treat it as compromised until proven otherwise

Dirty Frag is one of the most impactful Linux kernel vulnerabilities of the year. The patches are out, the workaround is one command, and the time to act is now.