On May 7, 2026, two Linux kernel vulnerabilities went public before the coordinated disclosure process was finished. An unrelated third party broke the embargo. The researchers had patches staged and vendor coordination underway — and then the clock ran out anyway.
The bugs are called Dirty Frag. They have been assigned CVE-2026-43284 and CVE-2026-43500. A public proof-of-concept was on GitHub within hours of the disclosure. By May 8, Microsoft confirmed active exploitation in the wild. By May 9, CISA added them to the Known Exploited Vulnerabilities catalog.
Here is what they are and what you need to do.
Why "Dirty Frag"
The name is a nod to Dirty Pipe (CVE-2022-0847) and Dirty Cow (CVE-2016-5195), two earlier Linux privilege escalations that exploited mishandled page-cache references. Dirty Frag follows the same pattern: unprivileged code ends up with a write primitive into the page cache of files it should only be able to read. The difference this time is that the primitive comes from the kernel's in-place decryption fast path in two independent networking subsystems — and neither bug is sufficient for reliable escalation on its own.
The Core Flaw: In-Place Decryption Into Borrowed Memory
When encrypted network data arrives, the kernel has two choices: decrypt into a fresh buffer it allocated, or decrypt directly inside whatever memory the data arrived in. The second path — in-place decryption — saves a copy operation and a heap allocation, which matters at line rate. Both the ESP (IPsec) and RxRPC subsystems chose this optimisation.
The problem is that the memory the data arrived in is not always kernel-owned. If an unprivileged process uses splice(2) or sendfile(2) to feed data through one of these decryption paths, it can arrange for page-cache pages — in-memory copies of files — to land inside the decryption buffer. The kernel then decrypts directly into those pages.
Because the pages belong to the page cache, the plaintext the kernel just wrote into them is now visible to the original process as modified file contents. The on-disk file is unchanged. The kernel's file-integrity accounting sees nothing. But the in-memory copy the kernel executes from has been patched.
That is the write primitive. With it, you can modify the in-memory image of any readable file on the system, including setuid-root binaries like su and sudo. Patch them in memory, call execve, and the kernel runs your shellcode with UID 0 because those binaries carry the setuid bit.
The Two CVEs and Why Chaining Matters
CVE-2026-43284 covers the ESP path — specifically the esp4 and esp6 modules that handle IPsec traffic. This vulnerability was introduced in January 2017 by a commit that moved IPsec receive into an in-place decryption fast path.
CVE-2026-43500 covers the RxRPC path. RxRPC is a niche kernel networking protocol (used by AFS), and it added the same fast-path optimisation in June 2023.
On their own, each bug provides a write primitive, but with limitations. The ESP variant can be blocked on systems where unprivileged user namespaces are disabled — a common hardening step on RHEL 9+ and recent Ubuntu. The RxRPC variant does not require user namespaces, but produces a write primitive with different alignment and size characteristics. Each primitive alone fails to cover certain kernel configurations or distribution hardening choices reliably enough for a one-shot exploit.
Chained, they cover each other's gaps. The Dirty Frag public exploit selects which path to use based on what the target system has available, achieving immediate, deterministic root access across all major distributions without requiring the attacker to know anything about the specific kernel configuration in advance.
That is the design: two individually incomplete primitives that together form a complete, adaptive exploit.
Deterministic. No Race. Already Weaponised.
The two things security teams most want to hear about a local privilege escalation are that it requires a race condition (hard to exploit reliably) and that it is not yet weaponised. Dirty Frag is neither.
The in-place decryption write is a logic bug, not a timing bug. The exploit does not need to win a race against any concurrent kernel operation. It runs the same way every time. The kernel does not panic on failed attempts because there are no failed attempts — the write either lands where you aimed it or you miscomputed the target, which is correctable in a loop.
A public PoC from researcher V4bel has been confirmed working on:
- Ubuntu 24.04 LTS and earlier LTS releases
- Red Hat Enterprise Linux 8, 9, and 10
- CentOS Stream, AlmaLinux, Rocky Linux
- Fedora (all recent releases)
- openSUSE Leap and Tumbleweed
- OpenShift (container host kernels)
Microsoft's threat intelligence team reported in-the-wild exploitation on May 8, describing Dirty Frag as a post-compromise escalation tool: attackers land via an unrelated initial access vector — a web application vulnerability, a compromised credential, a misconfigured service — and immediately escalate from any unprivileged shell to root.
What You Need to Do
Patch first. The Linux Kernel Organization released upstream fixes for CVE-2026-43284 on May 8. All major distributions have shipped or are shipping updated kernel packages.
Update your kernel and reboot:
# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade linux-image-generic
sudo reboot
# RHEL / CentOS Stream / AlmaLinux / Rocky
sudo dnf update kernel
sudo reboot
# Fedora
sudo dnf update kernel
sudo reboot
# openSUSE
sudo zypper update kernel-default
sudo rebootIf you cannot reboot immediately, block the vulnerable modules. This closes the exploit path without a reboot, provided the modules are not already loaded:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
| sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'Caveats: unloading esp4 and esp6 will break IPsec (VPN tunnels using IKEv2, WireGuard is not affected). If you run site-to-site IPsec or use an IPsec-based VPN client, evaluate the impact before running this. Unloading rxrpc is safe on the vast majority of systems — it is only needed for AFS filesystem access.
Verify module state:
lsmod | grep -E 'esp4|esp6|rxrpc'Empty output means the modules are not loaded and the immediate exploit path is closed.
Check your OpenShift / Kubernetes nodes separately. Container workloads share the host kernel. A compromised container that can reach a host kernel vulnerable to Dirty Frag has a path to full node compromise. Update node kernels independently from application deployments.
The Embargo Break and What It Changes
Coordinated disclosure depends on vendors having enough time to produce and test patches before public knowledge of the bug enables exploitation. The timeline for Dirty Frag compressed that window to near zero: the embargo broke before several downstream distributions had shipped patched packages.
This is not the first time an embargo has broken early on a high-severity Linux vulnerability, but the consequences are increasingly severe as the tooling for weaponising LPE bugs improves. The gap between disclosure and exploitation used to be weeks; for Dirty Frag, Microsoft's threat intelligence team observed in-the-wild use within roughly 24 hours of the embargo breaking.
The practical implication for teams: a disclosed Linux kernel LPE, any disclosed Linux kernel LPE with a public PoC, now has an assumed exploitation timeline of 24 hours or less. Detection and patching cadences built around weekly maintenance windows are not sufficient for this threat class.
The Pattern
Dirty Frag is the second major Linux local privilege escalation in six weeks, following CopyFail (CVE-2026-31431). Both are logic bugs, not memory corruption. Both exploit the gap between what the kernel tracks as "writable" and what actually ends up in a writable code path. Both have a deterministic exploit, no race condition, and full distribution coverage.
The pattern — two or more subsystems individually correct, dangerous in combination — is harder to find with line-by-line code review and easier to find with tools that trace data flows across subsystem boundaries at scale. We are watching the attack surface get more systematically mapped, not because the kernel has gotten sloppier, but because the tools scanning it have gotten better.
Patch now, then think about what else is sitting in your kernel that nobody has named yet.