< back to blog

Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC

Michael Clark
Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC
Published by:
Michael Clark
Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC
Director of Threat Research
@
Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC
Published:
May 8, 2026
falco feeds by sysdig

Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.

learn more
Green background with a circular icon on the left and three bullet points listing: Automatically detect threats, Eliminate rule maintenance, Stay compliant, with three black and white cursor arrows pointing at the text.

On May 8, 2026, CVE-2026-43284 and CVE-2026-43500, nicknamed Dirty Frag, were disclosed by independent researcher Hyunwoo Kim, who claims he was forced to publish ahead of schedule — and ahead of patches being released — after another party broke a coordinated embargo. The pair of vulnerabilities allows an unprivileged local user to corrupt arbitrary page caches and pivot to root on many Linux distributions. A working proof of concept (PoC) was published the same day, before any distribution shipped patched kernels.

The ESP vulnerability (CVE-2026-43284) was introduced in January 2017 by commit cac2661c53f3, which moved IPsec ESP receive into an in-place decryption fast path. The RxRPC variant (CVE-2026-43500) was introduced in June 2023 when the same fast-path pattern was added to rxrp. Given the extended gap between the introduction of the vulnerabilities and their discovery, it’s likely that both were identified with the assistance of AI. 

The Sysdig Threat Research Team (TRT) analyzed Dirty Frag to examine how both vulnerabilities can be exploited, validate runtime detection coverage for Sysdig and OSS Falco users, and provide key recommendations for security and development teams. Their findings are outlined below.

Affected versions

Known affected: 

  • Linux kernel 4.10 through 7.0
  • Most if not all Linux distributions are affected, going back several years.

Root cause

Linux keeps recently-used files in RAM as a performance cache (what it calls a "page cache"). When you read /usr/bin/su, the kernel doesn't go to disk. Instead, it serves the bytes. Crucially, the cache is shared: Every process that opens the file points at the same in-memory pages. File permissions decide whether you can modify those pages, and an unprivileged user normally cannot.

Two Linux networking features — IPsec encryption, ESP, and the niche file-sharing protocol, RxRPC — use an optimization that decrypts received networking data in place. Instead of copying received network data into a fresh buffer before decryption, the kernel decrypts it directly inside whatever memory chunk it arrived in.

The flaw is that the kernel doesn't check who actually owns that memory. That means an attacker can stitch together a fake network packet whose payload memory is secretly a page borrowed from the cache of /usr/bin/su. They can then configure the kernel's decryption using their own key, so the "decrypted output" is the bytes they fully chose. As a result, the kernel obediently writes those bytes into the borrowed page, which is the in-memory copy of the su file that the whole system shares. Now /usr/bin/su is silently rewritten in RAM with the attacker's shellcode. The next person to run su runs the attacker's code as root.

Exploitation

The public PoC chains both primitives together so it can route around distribution-specific hardening. On hosts that allow unprivileged user namespaces, the ESP variant runs first; on Ubuntu, where unprivileged user namespaces are restricted but rxrpc.ko ships in the default kernel package, the RxRPC variant takes over. 

The ESP exploit roughly follows the attack chain below:

  • Open a pipe and use vmsplice() to attach a page from the /usr/bin/su page cache as a paged fragment.
  • Configure an XFRM SA with attacker-chosen cipher, key, and SPI via AF_KEY or XFRM netlink.
  • splice() the pipe into a UDP socket configured for ESP encapsulation and send a crafted ESP datagram to loopback.
  • The kernel decrypts the data in place across the spliced page, depositing a 192-byte x86_64 stub (setuid(0); setgid(0); execve("/bin/sh")) directly into the cached pages of /usr/bin/su.
  • Run /usr/bin/su; the patched binary executes and yields a root shell.

Unlike the previous DirtyPipe vulnerability, CVE-2022-0847, which relied on a narrow race in pipe buffer flag handling, Dirty Frag is a deterministic logic flaw. Kim reports very high success rates and minimal kernel panic risk, with no timing window to lose. The four-byte write granularity of Copy Fail (CVE-2026-31431) is replaced here by full attacker-controlled plaintext at any chosen offset, in single-shot form.

Impact

Any local unprivileged user on a vulnerable kernel can gain root access. There is no remote vector. The exploit relies only on standard syscalls (socket, setsockopt, bind, vmsplice, splice, sendmsg) and modules (esp4, esp6, rxrpc) that come fully enabled in the default kernel packages of every major enterprise distribution. Container workloads, therefore, inherit host kernel exposure: a compromise of any container that can create AF_KEY, XFRM netlink, or AF_RXRPC sockets (the default for unconstrained Docker, containerd, and most Kubernetes pods) escalates to host root.

Detection with Sysdig Secure

Sysdig Secure customers using managed policies have runtime detections to help them detect these threats. First, the existing CopyFail rules detect some variants of Dirty Frag:

  • AF_ALG Page Cache Poisoning Leading to Privilege Escalation
  • AF_ALG Page Cache Poisoning Targeting Sensitive File

For the rest of the Dirty Frag variants, two new rules covering the ESP and RxRPC paths have been added to the Sysdig Runtime Behavioral Analytics policy:

  • Dirty Frag xfrm-ESP Page Cache Poisoning LPE
  • Dirty Frag RxRPC Page Cache Poisoning LPE 

Both rules use Sysdig's advanced detection engine to link events across signals, catching the setup phase before the in-place write lands.

Detection with Falco

The RxRPC path of Dirty Frag requires this socket to autoload rxrpc.ko and register an rxkad session key via add_key(), which is the prerequisite for obtaining the splice write primitive into the page cache. Since AF_RXRPC has no legitimate userspace consumers outside AFS filesystem daemons, the socket call itself is a reliable early indicator. 

- rule: AF_RXRPC Socket Created by Unexpected Process
  desc: >
    Detects creation of an AF_RXRPC (RxRPC protocol, domain 33) socket by a process that is not a known AFS client or server daemon. AF_RXRPC sockets are used by the Dirty Frag RxRPC userspace-fcrypt exploit path: an attacker opens socket(AF_RXRPC, SOCK_DGRAM) and calls add_key("rxrpc") to register a kernel rxkad key, obtaining a splice write primitive into a page-cache fragment.
  condition: >
    evt.type=socket and evt.dir=< and evt.rawres >= 0 and
    (evt.rawarg.domain=33 or evt.arg.domain contains AF_RXRPC) and
    proc_name_exists and
    not proc.name in (af_rxrpc_trusted_processes)
  output: AF_RXRPC socket created by unexpected process (proc.name=%proc.name proc.exepath=%proc.exepath proc.pname=%proc.pname proc.pexepath=%proc.pexepath gparent=%proc.aname[2] gexepath=%proc.aexepath[2] ggparent=%proc.aname[3] ggexepath=%proc.aexepath[3] proc.cmdline=%proc.cmdline proc.pcmdline=%proc.pcmdline socket.domain=%evt.arg.domain socket.type=%evt.arg.type proc.pid=%proc.pid proc.exe=%proc.exe)

Recommendations

  • Update to a patched kernel version.
  • Mitigate immediately on hosts that do not require IPsec transport mode or AFS by preventing the vulnerable modules from loading. AWS's 2026-027 bulletin extends the list beyond the originally disclosed three to include the surrounding xfrm_user, ipcomp4, and ipcomp6 modules. (NOTE: This will not be effective if the kernel has the functionality compiled in.) 
  • Restrict AF_KEY, AF_RXRPC, and XFRM netlink syscalls in container runtimes via seccomp profiles; the default Docker seccomp profile already blocks AF_RXRPC but not AF_KEY or XFRM netlink configuration.
  • Deploy the Falco rule above to flag unprivileged use of these socket families and netlink protocols across hosts and containers.
  • Audit running workloads for legitimate IPsec and AFS users, so detection exceptions are scoped to known binaries rather than disabled.
  • Monitor for unexpected modifications to setuid binaries and /etc/passwd, and for unexpected privilege transitions following splice and vmsplice activity from unprivileged processes.

Conclusion

Dirty Frag is the second universal Linux LPE vulnerability in eight days, following CopyFail's algif_aead page cache write flaw. Both turn long-lived in-place processing optimizations into deterministic root primitives: one in userspace crypto, the other in IPsec receive. With a working public PoC 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

Until kernels are updated, blacklisting the vulnerable modules and deploying runtime detection of unprivileged AF_KEY, AF_RXRPC, and XFRM activity are the only practical compensating controls. Page-cache-write classes should be treated the same way Dirty Pipe was: as a recurring pattern, not a one-off bug.

About the author

Cloud detection & response
Cloud Security
featured resources

Test drive the right way to defend the cloud
with a security expert