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.
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.
{{cta}}
FAQ

{
"@context": "https://schema.org"
"@graph": [
{
"@type": ["BlogPosting", "TechArticle"],
"@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#article"
"isPartOf": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#webpage" },
"mainEntityOfPage": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#webpage" },
"headline": "Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root",
"description": "Dirty Frag lets a local attacker turn low-privileged Linux access into root. See the affected CVEs, container risk, exposure checks and fixes.",
"datePublished": "2026-09-04",
"dateModified": "2026-09-04",
"wordCount": 1250,
"timeRequired": "PT6M",
"inLanguage": "en-US",
"articleSection": "Malware & CVEs",
"author": { "@id": "https://www.aikido.dev/authors/nicholas-thomson#person" },
"publisher": { "@id": "https://www.aikido.dev/#organization" },
"image": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#primaryimage" },
"keywords": [
"Dirty Frag",
"CVE-2026-43284",
"CVE-2026-43500",
"CVE-2026-46300",
"Fragnesia",
"Linux kernel privilege escalation",
"local privilege escalation",
"container escape",
"Kubernetes security",
"page cache",
"IPsec ESP",
"RxRPC",
"XFRM",
"kernel patching"
],
"about": [
{ "@type": "Thing", "name": "Dirty Frag" },
{ "@type": "Thing", "name": "Linux kernel local privilege escalation" },
{ "@type": "Thing", "name": "Linux kernel vulnerability" }
],
"mentions": [
{ "@type": "Thing", "name": "CVE-2026-43284", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43284" },
{ "@type": "Thing", "name": "CVE-2026-43500", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43500" },
{ "@type": "Thing", "name": "CVE-2026-46300", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46300" },
{ "@type": "Thing", "name": "Linux kernel" },
{ "@type": "Thing", "name": "IPsec ESP" },
{ "@type": "Thing", "name": "RxRPC" },
{ "@type": "Thing", "name": "Andrew File System" },
{ "@type": "Thing", "name": "page cache" },
{ "@type": "Thing", "name": "Kubernetes" },
{ "@type": "Thing", "name": "Docker" },
{ "@type": "SoftwareApplication", "name": "Aikido Security VM Scanning", "applicationCategory": "SecurityApplication", "url": "https://www.aikido.dev/cloud/virtual-machine-scanning" },
{ "@type": "SoftwareApplication", "name": "Aikido Container Image Scanning", "applicationCategory": "SecurityApplication", "url": "https://www.aikido.dev/code/container-image-scanning" }
],
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["h1", "h2"]
}
},
{
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#webpage"
"url": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284"
"name": "Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root",
"description": "Dirty Frag lets a local attacker turn low-privileged Linux access into root. See the affected CVEs, container risk, exposure checks and fixes.",
"inLanguage": "en-US",
"isPartOf": { "@id": "https://www.aikido.dev/#website" },
"primaryImageOfPage": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#primaryimage" },
"breadcrumb": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#breadcrumb" },
"datePublished": "2026-09-04",
"dateModified": "2026-09-04"
},
{
"@type": "ImageObject",
"@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#primaryimage"
"url": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284/hero.png"
"caption": "Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root"
},
{
"@type": "BreadcrumbList",
"@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#breadcrumb"
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.aikido.dev" },
{ "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://www.aikido.dev/blog" },
{ "@type": "ListItem", "position": 3, "name": "Dirty Frag (CVE-2026-43284)", "item": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284" }
]
},
{
"@type": "WebSite",
"@id": "https://www.aikido.dev/#website"
"url": "https://www.aikido.dev"
"name": "Aikido Security",
"publisher": { "@id": "https://www.aikido.dev/#organization" },
"inLanguage": "en-US"
},
{
"@type": "Organization",
"@id": "https://www.aikido.dev/#organization"
"name": "Aikido Security",
"url": "https://www.aikido.dev"
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
},
"sameAs": [
"https://www.linkedin.com/company/aikido-security"
"https://x.com/AikidoSecurity"
]
},
{
"@type": "Person",
"@id": "https://www.aikido.dev/authors/nicholas-thomson#person"
"name": "Nicholas Thomson",
"url": "https://www.aikido.dev/authors/nicholas-thomson"
"jobTitle": "Senior SEO & Growth Lead",
"worksFor": { "@id": "https://www.aikido.dev/#organization" },
"sameAs": [
"https://www.linkedin.com/in/nicholas-gray-thomson/"
]
},
{
"@type": "FAQPage",
"@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#faq"
"isPartOf": { "@id": "https://www.aikido.dev/blog/dirty-frag-cve-2026-43284#webpage" },
"mainEntity": [
{
"@type": "Question",
"name": "Which CVEs are part of Dirty Frag?",
"acceptedAnswer": {
"@type": "Answer",
"text": "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."
}
},
{
"@type": "Question",
"name": "Is CVE-2026-43284 remotely exploitable?",
"acceptedAnswer": {
"@type": "Answer",
"text": "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."
}
},
{
"@type": "Question",
"name": "Can Dirty Frag escape Kubernetes or Docker?",
"acceptedAnswer": {
"@type": "Answer",
"text": "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."
}
},
{
"@type": "Question",
"name": "Does rebuilding a container image fix Dirty Frag?",
"acceptedAnswer": {
"@type": "Answer",
"text": "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."
}
}
]
}
]
}