HIGH: 'Dirty Frag' Linux Kernel Bugs Hand Locals Root, One Half Already Patched, RxRPC Half Still Open (CVE-2026-43284, CVE-2026-43500)

If you were hoping the Linux kernel would catch a break this month, hope harder. A pair of memory-management bugs collectively dubbed "Dirty Frag" can hand any unprivileged local user a root shell in a single command, and Microsoft has already seen attackers using one of them in the wild. Public proof-of-concept code is on GitHub. One of the two CVEs has a kernel patch as of yesterday. The other one, the one in the RxRPC subsystem, is still unpatched at the time of writing.

The flaws are tracked as CVE-2026-43284 in the IPsec xfrm-ESP code path and CVE-2026-43500 in the RxRPC networking module. Security researcher Hyunwoo Kim, known online as @v4bel, reported both to Linux kernel maintainers on April 30, 2026, and named the chain Dirty Frag in homage to the long lineage of page-cache and copy-on-write privilege escalation bugs that have plagued Linux for the better part of a decade. The pattern is depressingly familiar. A subsystem hands out a write primitive into pages it does not actually own, an unprivileged process keeps a reference, and what was supposed to be a transient buffer turns into a tool for rewriting the contents of files that root cares about. Dirty COW walked so Dirty Pipe could run, and now Dirty Frag is here to remind us that no one has actually solved the underlying class of problem.

What makes Dirty Frag interesting from a defender's perspective is the age of the underlying mistakes. The xfrm-ESP issue traces back to a commit landed in January 2017, almost a decade old. The RxRPC issue was introduced in June 2023. Both have been sitting in mainline kernels through countless merge windows, distro rebuilds, and security audits. Neither was caught by fuzzers or static analysis. They surfaced because one researcher decided to look closely at how the receive paths in those two subsystems handle paged buffers that were not privately owned by the kernel, the kind of pages that arrive at a socket through splice or sendfile rather than being allocated freshly inside the kernel itself. When the decryption or framing logic writes back into those shared pages, the unprivileged process that originally provided them gets a clean view of the result. Worse, that process can then turn the write primitive against the page cache itself and modify on-disk data the attacker has no business touching, including files like /etc/passwd. Kim's public exploit closes the gap in one command.

The list of distributions confirmed vulnerable reads like an inventory of every production Linux fleet on the planet. Ubuntu 24.04.4, Red Hat Enterprise Linux 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, and openSUSE Tumbleweed are all affected, and Wiz has flagged Red Hat OpenShift deployments running on top of those base images. If your organization runs Linux servers, runs Linux containers, or runs anything that even smells like a Linux pod, assume Dirty Frag is on the menu until you can prove otherwise. The CVSS scoring for the two CVEs has not been finalized, but the predecessor in this informal series, Copy Fail (CVE-2026-31431), came in at 7.8 and CISA already added that one to the Known Exploited Vulnerabilities catalog. Dirty Frag is functionally equivalent in impact and somewhat easier to weaponize given the published proof of concept, so expect similar treatment from CISA in short order.

Microsoft published a corroborating threat intelligence post on May 8 confirming what most of us suspected the moment the PoC dropped. Defender telemetry caught attackers using Dirty Frag as a post-compromise privilege escalation step in actual intrusions. The observed chain looks roughly like this. The attacker authenticates over SSH with credentials harvested earlier, drops a small ELF binary called update into a writable directory, and runs it. The binary triggers the kernel bug, su pops a root shell, and the actor moves on to the real work. In Microsoft's documented case that real work included tampering with GLPI LDAP authentication files, wiping session data and active sessions, and conducting general reconnaissance. Microsoft has not attributed the activity to a named threat group, only noting "limited in-the-wild activity," which in practice tends to mean "limited until somebody packages this into a Cobalt Strike kit, at which point it stops being limited."

The crucial detail for anyone doing risk math at the moment is that CVE-2026-43284, the xfrm-ESP half of the chain, was patched in mainline at commit f4c50a4034e6 on May 8. Distros are pushing kernel updates as of yesterday and today. CloudLinux already shipped its kernel update. Tenable, Qualys, and Sysdig have all published detection guidance and signatures. The bad news is that CVE-2026-43500, the RxRPC half, does not yet have an upstream fix. The CVE was reserved but is not even fully published in NVD. For anything you cannot patch immediately, the temporary mitigation is to blocklist the vulnerable kernel modules entirely. Drop a file under /etc/modprobe.d that prevents esp4, esp6, and rxrpc from loading, then reboot to flush any already-loaded copies. Most production servers do not actually need RxRPC, which exists primarily to support Andrew File System workloads, so the operational impact of blocking it is generally negligible. The IPsec ESP modules are a different conversation. If your infrastructure depends on IPsec VPNs or transport-mode tunnels, blocklisting esp4 and esp6 will break those. Patch instead.

Detection is the next worry. Because Dirty Frag is a local privilege escalation, the kernel exploit itself does not generate the kind of network traffic an IDS would catch. What you can catch is the surrounding behavior. A non-root process spawning a setuid root shell in close temporal proximity to module load events for esp4, esp6, or rxrpc is a strong signal. So is any service account suddenly executing su with success. Microsoft Defender for Endpoint on Linux is shipping a signature called Exploit:Linux/DirtyFrag.A along with related variants, and EDR products that hook execve and prctl can flag the typical exploitation pattern. If you run Sysdig, Falco, or any auditd-based stack, write a rule that alerts on uid transitions where the parent process was a low-privileged shell and the child is a root shell with no preceding sudo invocation. That alone catches most of the public exploit's behavior.

There is also a worthwhile inventory exercise hiding in this disclosure. The Dirty Frag chain only matters when an attacker already has unprivileged code execution on the box. The question of how often that condition is met inside your environment is exactly the question every CISO should be asking after a story like this. Over-permissioned service accounts, shared SSH credentials between developers and production, weak container isolation, exposed Jupyter notebooks, build agents that run untrusted code, and any web application with a remote code execution bug all create the precondition. Patching the kernel closes one door. Treating that door as the only one between an attacker and root is the kind of thinking that makes ransomware actors comfortable.

For the managed service crowd, this disclosure cycle is one of the cleaner upsell hooks of the quarter. Every Linux server you manage just acquired a critical patch obligation, and every Linux server you do not currently manage at a client just became an opportunity to demonstrate value. The pitch practically writes itself. Pair the kernel patch deployment with a privileged access review and a quick audit of which service accounts can reach which boxes, and you have turned a Saturday morning fire drill into a multi-line statement of work. For clients on the fence about EDR for Linux, this is the case study. Without endpoint telemetry on the host, the SSH-to-su-to-root chain Microsoft documented is invisible. With it, you catch the exploit at execution time and get to send a triumphant before-and-after to the customer's leadership team. Add darkweb monitoring for stolen SSH keys and you have a three-service bundle that addresses the full kill chain rather than just the kernel bug.

Patch the kernels, blocklist RxRPC where you can afford to, watch for unusual privilege transitions, and accept that the page cache is now a permanent attack surface. There will be a Dirty Frag 2 eventually. The interesting question is whether your detection stack will catch it before the next researcher reports it.