Dirty Frag: The Second Linux Root Exploit in Two Weeks
Two new kernel vulnerabilities chain together for race-free root on every major distro. Exploited within 24 hours of disclosure. Same primitive class as Dirty Pipe and CopyFail. Patch your servers.
#Two Linux root exploits in two weeks. This is not a drill.
If you just finished patching CopyFail (CVE-2026-31431), congratulations. Now do it again.
"Dirty Frag" is a pair of page-cache-write vulnerabilities in the Linux kernel's networking subsystem:
- CVE-2026-43284: ESP4/ESP6 fragmentation handling lets you write controlled data into arbitrary page-cache pages
- CVE-2026-43500: Same flaw in RxRPC transport
- CVE-2026-46300 ("Fragnesia"): Related XFRM ESP-in-TCP issue, same vulnerability family
Chain them together: deterministic, race-free path to root. Same primitive class as Dirty Pipe (2022) and CopyFail (two weeks earlier). Works on Ubuntu, RHEL, Fedora, openSUSE, Amazon Linux, Azure Linux, CloudLinux. Basically everything.
Exploited in the wild within one day of disclosure. Public proof of concept available.
Microsoft published the initial analysis because they found it being used in active attacks on Azure Linux workloads. When Microsoft is writing Linux security advisories, that's how you know things are serious.
#Why the kernel keeps having these bugs.
Three Linux root exploits in the same vulnerability class in less than a month (Dirty Pipe descendants in the page cache write family). Same primitive. Same impact. Different subsystems.
This isn't a coincidence. The Linux kernel is enormous. Millions of lines of code. Written over decades by thousands of contributors. The page cache, the networking stack, the crypto subsystem, all of them handle memory in complex ways, and subtle bugs in how pages are mapped, copied, and released can lead to arbitrary write primitives.
Once researchers find one instance of a bug class, they go looking for others. Dirty Pipe showed the class exists. CopyFail found it in the crypto subsystem. Dirty Frag found it in networking. There will be more.
For businesses, the lesson is simple: kernel patching is not optional, it's not quarterly, and it's not something your IT person "gets to when things slow down." It's as critical as locking the front door.
#What to do.
1. Patch your kernels. Distro patches are available for all major distributions. This is the same drill as CopyFail:
`
#Ubuntu/Debian
sudo apt update && sudo apt upgrade linux-image-$(uname -r)
#RHEL/CentOS/Rocky/Alma
sudo dnf update kernel
#Then reboot
sudo reboot
`
2. If you can't patch immediately, disable the affected modules:
`
#Disable ESP and RxRPC modules
echo "install esp4 /bin/false" | sudo tee -a /etc/modprobe.d/disable-dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/disable-dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/disable-dirty-frag.conf
`
Note: if you use IPsec VPNs, you can't disable ESP modules without breaking them. In that case, patching is your only option.
3. Enable live patching if available. Ubuntu Livepatch, RHEL kpatch, and SUSE kGraft can apply kernel security fixes without rebooting. Not all fixes qualify, but for critical LPEs like this, live patches are usually available quickly.
4. Automate security updates. If you're manually patching servers, you're always going to be behind. Set up unattended-upgrades (Debian/Ubuntu) or dnf-automatic (RHEL) for security patches. Test in staging, auto-apply in production.
5. Monitor for privilege escalation. Tools like Wazuh and Falco (open source, CNCF project) can detect anomalous privilege escalation patterns. If someone exploits Dirty Frag on your server, the privilege change generates detectable events. But only if you're watching.
#Further reading
- Microsoft: Dirty Frag Analysis - initial discovery and exploitation details
- Tenable FAQ - affected versions and patch status
- Sysdig Detection Guide - detection rules
- Falco - open source runtime security for containers and Linux
- Wazuh - open source SIEM with kernel-level monitoring