Dirty Frag (CVE-2026-43284): Linux Root Escalation

Blog

Vulnerabilities & Threats

Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root

Written by

Nicholas Thomson

Published on:

Sep 4, 2026

Last updated on:

Sep 5, 2026

A read-only file should stay read-only. Dirty Frag (CVE-2026-43284, CVE-2026-43500 and CVE-2026-46300) gets the Linux kernel to edit its cached copy anyway.

This bug allows a program running with almost no privileges to write to files it should only be able to read by changing the copy the kernel keeps in memory. From there, it can rewrite something the system trusts and hand itself root access. In container environments, the same trick that reaches the host kernel can reach the node kernel shared by every workload.

The vulnerable pattern has been in the kernel's networking code for years, which is why it reaches back across most supported kernel versions and nearly every major distribution. Linux patched the flaw and every distro backported it, so the fix will live under a different version number on each one.

Dirty Frag overview

Red Hat groups three CVEs under Dirty Frag. They sit in different corners of the kernel's networking code, and one is a later variant the first round of patches missed. Here's how they compare.

The subsystem tells you whether this is relevant to you. If you don't run IPsec VPNs or AFS, it's a quick signal for how much to care. The module is what you'll check for (lsmod | grep -E 'esp4|esp6|rxrpc) to see what's loaded.

CVE	Kernel path (module)	CVSS Score	Practical condition	Impact
CVE-2026-43284	IPsec/XFRM ESP (esp4 / esp6)	8.8 (High)	Vulnerable kernel; the public attack path commonly relies on user or network namespace creation.	Page-cache corruption followed by local root escalation.
CVE-2026-43500	RxRPC / AFS (rxrpc)	7.8 (High)	The rxrpc module must be available and reachable. Distribution exposure differs.	Page-cache corruption followed by local root escalation.
CVE-2026-46300 (Fragnesia)	XFRM ESP-in-TCP (esp4, esp6)	7.8 (High)	A separate follow-on variant that required an additional kernel fix.	Arbitrary page-cache writes that can alter privileged binaries and yield root.

Linux keeps recently accessed file data in memory so it doesn't have to read from disk every time. That in-memory copy is called the page cache. Certain kernel functions like splice() pass that cached data to the networking code without copying it, instead handing over a pointer to where the data already lives. That saves work, as long as every later step knows the memory is shared and doesn't write to it.

The bug showed up in two different corners of the kernel's networking code. One was ESP, which handles encrypted VPN traffic. The other was RxRPC, an older protocol used mainly by the AFS file system. Neither the ESP nor the RxRPC path checks whether the memory is shared before writing to it.

This allowed an attacker to take a read-only file that could hand them privileges if tampered with, something like /usr/bin/su, and feed its contents into the networking path so the buggy decryption would end up writing into that file's memory. The write ends up in the page cache, which is the copy of the file the system serves to anything that reads it. The file on disk never changes, but the version in memory now says whatever the attacker made it say. Running su reads the tampered copy and hands the attacker root access, even though they were only ever allowed to read that file.

Fragnesia, tracked as CVE-2026-46300, is the later variant. The Dirty Frag fix made the kernel rely on a marker that says "this fragment is shared, make a safe copy before touching it." But an old bug from 2013 in the code that merges packet fragments together quietly drops that marker. It sat harmless for thirteen years because nothing depended on it. Unfortunately, the Dirty Frag fix depended on it, which turned a dormant bug into a fresh path to root access.

Why does Dirty Frag matter for containers?

Containers all share one kernel with the host, so a hacked container can reach the vulnerable kernel code if its permissions allow (syscall / namespace / security-policy settings). Researchers have already published working proof-of-concept exploits for Kubernetes, and Ubuntu spells out the risk of a container escape. If the container can reach the kernel, the risk is root access over the whole node.

You can shut down parts of the attack by running workloads as non-root, turning on the RuntimeDefault seccomp profile, enforcing restricted pod policies, and limiting unprivileged user namespaces. But none of that fixes the actual flaw. Only the vendor's kernel update does that.

How can you tell whether a host is exposed?

Start with the host that's actually running, not the Dockerfile. Three commands help.

Run uname -r to find out what kernel version you're running, then compare it against the fixed version in your distribution's advisory. Don't compare it to the upstream number. The vulnerable pattern goes back to kernels from around 2017, and enterprise and LTS distributions like RHEL, Ubuntu, and Debian backport the fix onto the older kernel version you already run, so a patched kernel can still report a version from years ago. A fully patched RHEL 8 host still says 4.18, and that 4.18 has the fix. Confirm against your vendor's fixed package version.

lsmod | grep -E 'esp4|esp6|rxrpc shows whether the vulnerable code path is loaded. An empty result isn't the all-clear, since these modules load on demand. And a loaded one isn't automatically bad. esp4, esp6, and rxrpc are ordinary modules that are perfectly safe on a patched kernel. This tells you your attack surface and whether the blacklist mitigation is worth applying.

sysctl user.max_user_namespaces shows how reachable the ESP path is. Above zero means unprivileged users can create namespaces, the usual way into the ESP path. Zero closes that door, but only for ESP. The RxRPC path doesn't need namespaces, so it's not full cover.

Check your vendor status. Red Hat says CVE-2026-43500 doesn't affect its products, while CVE-2026-43284 and CVE-2026-46300 do affect supported Red Hat Enterprise Linux kernels and anything built on them. Ubuntu publishes the exact fixed package version for each kernel line it supports.

What should you monitor?

Proof-of-concept code is already public. Microsoft has reported limited real-world activity where an attacker escalates privileges using su, though it's careful to note this may be Dirty Frag or its predecessor Copy Fail, since the two are hard to tell apart from process logs alone.

The realistic place to catch this is the audit and EDR tooling you already run. Linux's audit framework can log process execution and setuid transitions, which is where the telltale sequence would surface, an unknown binary being dropped and run, followed immediately by su. Watch for esp4, esp6, or rxrpc loading around the time of other suspicious activity, especially on a host that has no reason to use IPsec or AFS, and for freshly dropped ELF files being executed.

If you suspect exploitation, run your integrity checks from a trusted environment rather than the possibly-compromised host itself. And remember that blocking the kernel modules doesn't undo any page-cache changes an attacker already made.

Where Aikido fits

Most scanning stops at the image or the repo. Dirty Frag lives one layer down, in the kernel the node actually boots.

Aikido Security VM scanning reads what's actually installed on the running host from a cloud snapshot, so a vulnerable kernel package shows up as a host finding. Because it also ties hosts to the workloads and accounts running on them, you can see the blast radius if one node gets popped.

For the cloud hosts connected to Aikido, VM scanning surfaces the ones carrying the vulnerable kernel package and shows which workloads run on them. The fix stays the same, patch the node kernel and confirm the loaded build after reboot.

FAQ

Which CVEs are part of Dirty Frag?

The current Dirty Frag set contains CVE-2026-43284 in IPsec/XFRM ESP, CVE-2026-43500 in RxRPC, and CVE-2026-46300, the Fragnesia variant, in XFRM ESP-in-TCP fragment handling.

Is CVE-2026-43284 remotely exploitable?

Exploitation begins with the ability to run code locally as a low-privileged user or workload. A remote vulnerability, stolen SSH account, or compromised container can provide that first foothold, after which Dirty Frag can supply root escalation.

Can Dirty Frag escape Kubernetes or Docker?

A vulnerable host kernel can make node-level escalation possible from a container when the workload can reach the required kernel functionality. Seccomp, pod security settings, namespace restrictions, and the node distribution all change practical reachability.

Does rebuilding a container image fix Dirty Frag?

No. The affected code runs in the host kernel. Patch and reload the kernel on the node, then verify that old nodes and machine templates are no longer serving workloads. Securing what's actually inside your images is a separate job.

‍

Text Link

Scan for malware

Start for Free

4.7/5

Tired of false positives? 
Try Aikido like 100k others.

Start Now

Get a personalized walkthrough

Trusted by 100k+ teams

Book Now

Scan your app for IDORs and real attack paths

Trusted by 100k+ teams

Start Scanning

See how AI pentests your app

Trusted by 100k+ teams

Start Testing

Find the exposed hosts before an attacker does

Aikido VM scanning surfaces vulnerable kernel packages on the hosts you run

Try for free

MECCHA CHAMELEON can't hide from the RCE

We found a second delayed RCE in MECCHA CHAMELEON: a malicious custom map could write files anywhere on your system and run code after a restart. Now patched in 4.0.0.

Pentesting

August 28, 2026

•

Vulnerabilities & Threats

Popular code generator for TanStack Query hit by supply chain worm

A supply chain worm was found hiding in @7nohe/openapi-react-query-codegen, a popular code generator for TanStack Query, stealing credentials and spreading itself to every package the victim maintains.

Malware

August 20, 2026

•

Vulnerabilities & Threats

Popular Rust crates arrayref, append-only-vec, and internment compromised in Supply Chain Attack

A supply chain attack compromised popular Rust crates, arrayref, append-only-vec, and internment, injecting a dependency on the malicious proc-macro1 package that downloads and executes a remote payload at build time.

Malware

Get secure now

Secure your code, cloud, and runtime in one central system.
Find and fix vulnerabilities fast automatically.

Start Scanning

Book a demo

No credit card required | Scan results in 32secs.