CVE-2026-31431 Kubernetes Escape: Copy Fail Hits EKS GKE

CVE-2026-31431, tracked as Copy Fail, is a Linux kernel page-cache corruption flaw in the AF_ALG crypto interface that turns any unprivileged local user into root on essentially every mainstream distribution built since 2017, and on Kubernetes it crosses container and tenant boundaries because the page cache is shared across the host. A validated proof of concept has already escaped from a fully unprivileged pod to node-level code execution on Amazon EKS, Google GKE, and Alibaba Cloud ACK, which means managed Kubernetes clusters running unpatched node kernels are directly exposed today. The bug lives in the kernel rather than in Kubernetes itself, but the orchestrator supplies the exact conditions — shared image layers plus privileged DaemonSets — that escalate a local privilege bug into a full container escape.

How Kernel Page Cache Enables Escape

The root cause sits in the kernel’s AF_ALG crypto subsystem, which exposes socket-based cryptographic operations to userspace. Copy Fail abuses a race in how the kernel handles splice() from a file into an AF_ALG socket: instead of isolating the attacker’s bytes, the kernel writes them into the page-cache pages of a read-only target file. The file on disk is never modified, so on-disk file-integrity monitoring tools see nothing, yet every process that subsequently reads or executes that file loads the corrupted pages. Because the page cache is shared kernel-wide, that corruption is immediately visible to processes in other containers and to the host itself.

Exploitation needs only an unprivileged local account — no network access, no kernel debugging features, and no pre-installed primitives, because AF_ALG ships enabled in essentially every mainstream distribution’s default configuration. On a single-tenant server that is a serious local privilege escalation; on a multi-tenant cluster it is a tenant-bypass primitive that crosses the boundaries Kubernetes is supposed to enforce.

Why Managed Kubernetes Clusters Stay Exposed

The escape becomes dangerous in Kubernetes because of three properties that commonly coexist on the same node: kernel page-cache corruption, image-layer sharing, and privileged DaemonSets. Container runtimes such as containerd and CRI-O use overlay filesystems, so identical image layers map to the same page-cache pages across containers. An unprivileged pod built FROM the same base image as a privileged DaemonSet corrupts a shared binary, and the privileged workload then executes the tampered pages with full node privileges — root, all capabilities, and host namespace access.

A public proof of concept has already demonstrated this end to end on the three largest managed platforms, writing a marker file to the host filesystem from a pod that held no special permissions:

The PoC uses kube-proxy as a concrete target because it is one of the most common privileged DaemonSets, but the technique generalizes to any privileged workload — monitoring agents, CNI plugins, log collectors, or security agents — whose image shares layers with an attacker-controlled base image. Clusters where kube-proxy runs non-privileged, as some managed distributions configure it, are less directly affected through that specific path, but the underlying page-cache primitive still hands an unprivileged tenant a reliable route to host root.

Patch The Kernel Before Anything Else

the definitive fix is a kernel update that includes mainline commit a664bf3d603d, which reverts the 2017 algif_aead in-place optimization so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are already shipping patched kernel packages, so on managed Kubernetes the priority is rolling nodes onto the latest provider AMI, Container-Optimized OS image, or node-image version that bundles the fix. Because the flaw affects every node independently, a partial rollout leaves vulnerable hosts in the fleet where a tenant or a compromised workload can still land.

Where immediate patching is not possible, copy.fail documents an interim kernel-level control: disable the algif_aead module so the vulnerable code path cannot load, then remove it from the running kernel. For the vast majority of systems this breaks nothing measurable, since dm-crypt, IPsec, in-kernel TLS, and default OpenSSL builds do not route through AF_ALG.

Containing Untrusted Pods Without Rebooting

for untrusted workloads such as containers, sandboxes, and CI runners, blocking AF_ALG socket creation through seccomp is recommended regardless of patch state. This denies the primitive the exploit depends on without touching the kernel, which matters for clusters where a node reboot would disrupt stateful workloads or where the patched image is still propagating through the fleet. Community eBPF daemons and policy engines make this enforceable across a cluster rather than host by host.

Additional defensive layers reduce blast radius even when a single node falls:

• Minimize privileged DaemonSets. Drop privileged mode and unnecessary capabilities from agents that do not strictly need them.
• Use distinct base images for privileged workloads so they do not share layers with untrusted tenant containers.
• Restrict pod scheduling so untrusted workloads cannot land on nodes that run privileged DaemonSets with shared base images.
• Enable image-layer isolation where the runtime supports per-container filesystem snapshots that prevent page-cache sharing.

Open-source mitigations already exist for teams that need enforcement: vArmor ships a built-in copy-fail-mitigation rule that blocks AF_ALG sockets through AppArmor and BPF enforcers, and community eBPF daemons provide a zero-downtime Kubernetes-level block. Pairing these with the pipeline controls described in embedding security into CI/CD pipelines ensures unpatched node images are caught before they reach production.

Practical Mitigation Checklist For Clusters

1. Inventory node kernels. List every node’s kernel version and flag any built before the CVE-2026-31431 patch.
2. Patch in waves. Rotate nodes onto the latest provider image that includes the fix, draining and replacing one batch at a time.
3. Disable algif_aead on hosts that cannot be rebooted immediately, using the modprobe rules documented at copy.fail.
4. Add a seccomp or eBPF block on AF_ALG socket creation for untrusted namespaces, using vArmor or a community eBPF daemon.
5. Audit privileged DaemonSets. Remove privileged mode where possible and move privileged workloads to distinct base images.
6. Restrict scheduling of untrusted tenants away from nodes running shared-layer privileged agents.
7. Verify with the PoC on a non-production node to confirm the kernel and seccomp controls actually block the escape.

For broader guidance on restricting what automated workloads can reach inside the cluster, the zero-trust playbook for cloud AI agents covers least-privilege boundaries that complement these kernel fixes.

Sources

• Copy Fail — CVE-2026-31431 (Xint Code)
• Copy Fail Kubernetes Container Escape PoC (GitHub)