CopyFail and DirtyFrag: What These Linux Kernel Exploits Mean for You

Two Reliable Linux Root Exploits in Eight Days

In late April and early May 2026, two Linux kernel privilege escalation vulnerabilities were disclosed in quick succession. CopyFail (CVE-2026-31431) landed April 29. DirtyFrag (CVE-2026-43284 / CVE-2026-43500) followed eight days later. 

Both are deterministic, require no race condition to win, and achieve root from an unprivileged process. Both have highly effective public exploit code available. CopyFail has been added to CISA's Known Exploited Vulnerabilities catalog. DirtyFrag landed before patches were ready after a coordinated disclosure embargo was broken.

Nearly every mainstream Linux kernel version since 2017 is affected. The risk isn’t constrained to interactive workloads only. Container orchestrators like Kubernetes are also at risk due to containers sharing the underlying host’s kernel. An unprivileged pod, with standard security settings, can exploit the underlying worker node.

This post explains how both vulnerabilities work, how they can achieve container escape, what active exploitation looks like, and what to do right now.

The Shared Mechanism: Page Cache as an Attack Surface

Both vulnerabilities exploit a fundamental property of the Linux kernel: the page cache is shared across processes on the same host. When a file is read or memory-mapped, the kernel may keep its contents in memory. Subsequent accesses typically use this cached copy rather than rereading the file from disk, improving performance.

Under normal conditions, processes without write permission cannot modify the cached contents of a read-only file. The attack surface emerges when a kernel bug breaks that guarantee and allows an unprivileged process to alter page-cache pages associated with a file it can only read.

The file on disk remains unchanged. Instead, the attacker modifies the kernel's in-memory representation of the file. Any later process that reads, maps, or executes that file receives the modified contents from the page cache. If the target is a binary or shared library used by a privileged process, this can lead to privilege escalation.

Because the underlying file is never modified, disk-based integrity checks continue to report the original file as intact. Once the modified cache pages are evicted or the system reboots, the kernel reloads the original contents from disk and the changes disappear.

CopyFail and DirtyFrag each exposed a different kernel flaw that ultimately provided this same capability: modifying page-cache-backed file contents without modifying the file itself.

Page-cache write vulnerabilities are not new. Dirty COW, Dirty Pipe, CopyFail, and DirtyFrag all fall into this broader family, even though their root causes arise in different kernel subsystems.

CopyFail (CVE-2026-31431): A Logic Bug in the Crypto Subsystem

CopyFail was discovered by Xint Code, Theori's AI-assisted vulnerability research system. The bug resides in Linux's AF_ALG userspace cryptography interface, a feature that allows applications to access kernel cryptographic functions.

The root cause is a flaw in an optimization added in 2017. Under specific conditions, the kernel incorrectly reuses memory during a cryptographic operation and ends up writing data into a page-cache page associated with a file. As a result, an unprivileged user can gain a controlled 4-byte write primitive against the cached contents of any file they are permitted to read.

Like Dirty COW and Dirty Pipe before it, the vulnerability does not modify the file on disk. Instead, it corrupts the kernel's in-memory copy. Other processes subsequently reading or executing that file receive the modified contents from the page cache, creating a path to privilege escalation.

The public proof-of-concept is remarkably small—just 732 bytes of Python—and works across a wide range of Linux distributions, including Ubuntu 22.04 and 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16, Debian, Fedora, and Arch Linux. Ubuntu 26.04 (Resolute) and later are not affected.

The vulnerability received a CVSS score of 7.8. A fix was committed to the mainline Linux kernel on April 1, the CVE was assigned on April 22, and public disclosure followed on April 29. At the time of disclosure, no affected distribution had yet released a patched kernel package.

Since disclosure, CopyFail has been confirmed as actively exploited in the wild and has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog.

DirtyFrag (CVE-2026-43284 + CVE-2026-43500): Two Bugs, One Root Primitive

DirtyFrag was disclosed by independent researcher Hyunwoo Kim (@v4bel) on May 8, 2026, eight days after CopyFail. Its disclosure was unusually disruptive because the embargo was broken before Linux distributions had shipped patched kernels. For a short period, defenders faced a public exploit with no generally available vendor fix.

DirtyFrag is not a single bug. It chains two separate vulnerabilities that both lead to the same kind of page-cache write primitive. On their own, each bug has practical limits. Used together, they make exploitation more reliable across different distribution configurations.

The first issue, CVE-2026-43284, is in the IPsec ESP receive path. It was introduced by a 2017 optimization that moved ESP receive handling into an in-place decryption fast path. Under specific conditions involving spliced pipe-backed pages, the kernel fails to recognize that the memory being decrypted is shared. It then treats a page-cache page as if it were private and writes decrypted network data into memory it does not own. The result is a powerful write primitive against cached file contents.

The second issue, CVE-2026-43500, follows the same broad pattern in the rxrpc subsystem, Linux’s implementation of Reliable Transport RPC. This second path matters because some distributions restrict the namespace features needed to reach the ESP bug. When that route is blocked, the rxrpc bug can provide a complementary way to reach the same underlying primitive.

The two vulnerabilities received CVSS scores of 8.8 and 7.8, respectively. Affected distributions include RHEL, AlmaLinux, Ubuntu, Debian, Fedora, Arch, CentOS, CloudLinux, and Amazon Linux. AWS also confirmed that multiple Amazon Linux kernel lines were affected, including 4.14, 5.4, 5.10, 5.15, 6.1, 6.12, and 6.18.

Like CopyFail, DirtyFrag is deterministic rather than race-based. There is no narrow timing window to win. Once the right kernel path is reachable, the exploit can reliably corrupt page-cache-backed file contents, which is why the bug is so serious despite living in relatively specialized networking subsystems.

The Kubernetes Risk: Turning Shared Image Layers into a Container Escape

Most DirtyFrag demos focus on a single host: corrupt a cached system binary, execute it, and gain root privileges. The Kubernetes proof-of-concept published by PercivalII takes a different approach.

Instead of targeting a file unique to the attacker's container, it targets a file stored in a container image layer shared by multiple pods on the same node. Container runtimes such as containerd and Docker avoid storing duplicate copies of image layers. A single cached copy of a layer may be referenced by many containers simultaneously.

The attack begins inside an ordinary, unprivileged pod. Using DirtyFrag or CopyFail, the attacker modifies the page-cache-backed contents of a binary that exists in a shared image layer. The image on disk remains unchanged, but the kernel's in-memory copy is now attacker-controlled.

Any container on the node that later executes that binary receives the modified version from the page cache. The attacker does not need direct access to the target workload. The shared image layer becomes a distribution mechanism for the malicious code.

In the EKS proof-of-concept, this technique is used to demonstrate code execution beyond the originating pod. The significance is not the specific binary being modified, but the fact that a vulnerability in the host kernel can cross container boundaries through resources that containers are designed to share.

This highlights why page-cache vulnerabilities are particularly dangerous in containerized environments. Containers isolate filesystems, processes, and userspace resources, but they all depend on the same kernel and often the same cached image data. A corruption that would affect a single process on a traditional server can potentially affect multiple workloads running on the same Kubernetes node. The risk is compounded by the fact that Kubernetes runs privileged infrastructure components as DaemonSets on every node: components that execute binaries from their images with elevated privileges.

Three properties make this particularly dangerous in Kubernetes. First, the page-cache corruption is invisible to disk-based defenses. The on-disk binary is clean; only the kernel's in-memory copy is compromised. Second, container runtimes share image layers across pods on the same node, so a corruption in one container's view of a file affects every other container reading from the same cached copy. Third, Kubernetes runs privileged infrastructure components as DaemonSets on every node, executing binaries from their images with elevated privileges.

CopyFail and DirtyFrag are not just "local privilege escalation" bugs. In Kubernetes, they become cross-workload bugs because the page cache and container image layers are shared resources.

From Pod to Pwnd

In this EKS proof-of-concept, the target workload is kube-proxy. The attacker pod is built from the same base image as the kube-proxy DaemonSet and corrupts the cached copies of the iptables and ip6tables binaries. Because kube-proxy periodically invokes these utilities while running with elevated privileges, it eventually executes the modified versions, resulting in code execution within the privileged container.

The exploit can be achieved using a standard Kubernetes deployment with no special permissions and allowPrivilegeEscalation: false. This configuration would pass most companies' policy checks without attracting any scrutiny.

Because kube-proxy is a DaemonSet it is guaranteed to be running on all nodes in the cluster making the chance of successful exploitation significantly higher without needing to target the malicious deployment to a specific worker node.

Executing the DirtyFrag payload inside of the unprivileged container overwrites the cached copies of /usr/sbin/xtables-legacy-multi and /usr/sbin/xtables-nft-multi in the shared image layer. The on-disk binaries are untouched.

kube-proxy manages iptables rules and periodically invokes /usr/sbin/xtables-legacy-multi or /usr/sbin/xtables-nft-multi as part of normal operation. When it next updates network policy, the binaries from the kernel's page cache are invoked executing the attacker's payload. 

As the kube-proxy DaemonSet runs with a privileged security context, it allows for root access on the underlying worker node. The PoC payload simply tries to mount the worker node’s filesystem and write a file but a real attacker could drop malware, schedule malicious pods, steal secrets, etc.

The before-and-after view on the underlying worker node confirms execution. 

Before the exploit, the node's root home directory contained only standard dotfiles. After kube-proxy executes the modified binary, the file pwnd.txt is written.

The CopyFail Kubernetes PoC (also by Percivalll) leverages the same shared image layer attack that has been validated on EKS, GKE, and Alibaba Cloud’s ACK.

Active Exploitation and Operational Risk

CopyFail is no longer theoretical. It has been reported as exploited in the wild and added to CISA’s Known Exploited Vulnerabilities catalog. DirtyFrag arrived only days later with working public exploit code, before distributions had broadly shipped patched kernels.

The important point is where these bugs fit in an attack chain. They are local privilege escalation vulnerabilities, not initial access vulnerabilities. An attacker still needs a foothold first: SSH access, a web shell, compromised credentials, or code execution inside a container. Once that foothold exists, the exploit turns a low-privileged shell into root within seconds.

Microsoft described this pattern in observed Linux activity: an inbound SSH session establishes an interactive shell, a small ELF payload is dropped and executed, and privilege escalation follows almost immediately. In that sequence, the kernel exploit is the second step, not the first.

What happens after root is what matters operationally. At that point, an attacker can disable security tooling, read credentials from environment variables or mounted secrets, access in-memory material, and tamper with logs. In Kubernetes, root on the node is especially serious: the attacker may be able to inspect workloads running on that node, access secrets mounted into pods, and, depending on configuration, reach cloud credentials exposed through the node’s metadata service.

Detection is difficult because the exploit path abuses legitimate kernel interfaces. There may be no suspicious disk write before escalation, no obviously malicious syscall, and no modified binary on disk to hash. Signature-based detections can catch known proof-of-concept implementations, but small changes to the exploit wrapper or a custom payload may look like ordinary local kernel activity until the attacker is already root.

Validate Your Exposure

Verify whether the vulnerable modules are loaded:

# DirtyFrag
lsmod | egrep '^(esp4|esp6|rxrpc)\b'

# CopyFail
lsmod | grep algif_aead

No output means the modules are not currently loaded. That does not mean they cannot be loaded on demand. Check whether the modules are available on disk:

find /lib/modules/$(uname -r) -name 'algif_aead.ko*' -o -name 'esp4.ko*' -o -name 'esp6.ko*' -o -name 'rxrpc.ko*'

Check your kernel version:

uname -r

All mainstream kernels from 4.14 through current are affected unless patched. Ubuntu 26.04 (Resolute) and later are the only major distribution not affected by CopyFail.

Take Action

Patch first. For EKS, AWS has published updated EKS-optimized AMIs for all affected Amazon Linux kernel versions (4.14, 5.4, 5.10, 5.15, 6.1, 6.12, 6.18). Rotate your managed node groups to the updated AMIs. For Bottlerocket nodes, update to v1.61.0. For self-managed nodes and non-EKS Linux hosts, apply the latest kernel packages from your distribution's security repositories.

Interim mitigation if patching has to wait. Disabling the vulnerable modules blocks all known exploit paths for both vulnerabilities:

For CopyFail:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

For DirtyFrag:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf; \
  rmmod esp4 esp6 rxrpc 2>/dev/null; \
  echo 3 > /proc/sys/vm/drop_caches; true"

The drop_caches step at the end discards any previously corrupted in-memory pages. Do not skip it.

Important caveats before applying: disabling esp4/esp6 breaks IPsec functionality. Disabling rxrpc breaks AFS client connectivity. Evaluate whether your environment uses either before applying. The drop_caches flush causes a brief I/O spike; avoid it under peak load.

Treat node recycling as a security event after an RCE finding. The exploits operate in memory. A compromised page cache is cleaned by rebooting the node and reloading the original binary from disk. If you have a workload with a known or suspected RCE vulnerability on an unpatched node, rotate the node rather than waiting for the next maintenance window. If you suspect exploitation has already occurred, treat the node as compromised and rebuild: memory forensics or log review are not reliable recovery paths given the in-memory nature of the attack.

Harden Kubernetes privileges as a structural control. The Kubernetes-specific attack chain depends on a privileged workload executing a binary from a shared image layer. Reducing the attack surface by limiting workload privileges not only helps with vulnerabilities like CopyFail and DirtyFrag but may also reduce or eliminate the impact of the next yet-to-be-discovered vulnerability.

The Real Problem Is Not Finding These CVEs

Every scanner has already flagged CVE-2026-31431, CVE-2026-43284, and CVE-2026-43500. The detection is not the hard part.

The hard part is that the scanner output does not tell you which of your containers is reachable from outside and could serve as the initial entrypoint. It does not tell you which nodes, if compromised, expose secrets that can pivot into other workloads within your cloud environment. It does not tell you which patches to prioritize to reduce your blast radius. And it does not track whether the fix actually reached every node in your fleet or stalled somewhere in a change control queue.

That gap between a scanner finding and a confirmed-remediated node is where your exposure window lives. For vulnerabilities that are actively exploited and exist on nearly every Linux kernel version since 2017, that window matters.

Averlon maps the full attack chain from a container-level RCE through node compromise to cloud lateral movement, so you know which findings close the highest-value paths first. If you want to see where your current exposure lands, book a demo.