On April 29, 2026, CVE-2026-31431 was publicly disclosed. Nicknamed “Copy Fail”, it is a local privilege escalation in the Linux kernel with a CVSS score of 7.8, present in every major distribution running kernel 4.13 or later: Ubuntu, RHEL, Amazon Linux, SUSE, Rocky Linux. What makes it stand out from most CVEs in this class is how little an attacker needs: a 732-byte Python script, standard library only, no compilation, no race conditions, no kernel offsets. First try, every time.

What Is Copy Fail?

The vulnerability comes from three independent kernel changes that accumulated over six years. The critical one: a 2017 optimization in the kernel’s crypto subsystem started reusing memory buffers in a way that exposed page cache pages to writable access. The page cache is how Linux keeps file contents in RAM so they do not have to be re-read from disk every time. That optimization caused a four-byte write to cross a buffer boundary directly into those cached pages, overwriting the in-memory content of whatever file had been fed into the pipeline.

The exploit uses a kernel crypto socket (AF_ALG) to feed the cached pages of /usr/bin/su through a cryptographic operation. The operation itself fails, by design, but the write into the page cache sticks. Run /usr/bin/su afterward, and the injected code executes as root. No timing windows, no retry loops, no special setup.

Two things make this particularly serious in containerized environments. First, the Linux page cache is a host-kernel resource shared across all processes on the same host, regardless of namespaces or cgroups. A container does not have its own page cache. A compromised pod can corrupt binaries used by other pods on the same node, and shared image layers mean the same /usr/bin/su pages are often mapped across multiple containers. Second, the corruption exists only in RAM. File integrity monitoring tools (AIDE, Tripwire, Wazuh, OSSEC) all inspect disk, and the disk is untouched. They see nothing.

Standard Kubernetes mitigations don’t block this. AF_ALG sockets (address family 38) are permitted by the default seccomp profile. Pod Security Standards “Restricted” mode has no control for AF_ALG. Read-only root filesystems don’t help because the corruption is in the page cache, not on disk.

For the full technical breakdown of the exploit chain, the Xint research post covers it in depth.

The Fix: Patch the Kernel

The patch is in commit a664bf3d603d. Update to a kernel version that includes it:

BranchFirst patched version
Mainline7.0+
Stable6.19.12+
LTS6.18.22+

For managed Kubernetes on EKS, GKE, AKS, or OVHcloud MKS, check your provider’s advisory and upgrade node pools as soon as patched images are available. For environments requiring zero downtime, kpatch on RHEL and Canonical Livepatch on Ubuntu support live kernel patching without a reboot.

That is the whole fix. Everything below is mitigation, not remediation.

When You Cannot Patch Immediately

The most effective immediate mitigation is blacklisting the algif_aead kernel module:

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

The practical impact on legitimate workloads is negligible. dm-crypt, LUKS, kTLS, IPsec, OpenSSL, and SSH all use the kernel crypto API directly, not the AF_ALG socket interface. Almost no production software uses this interface.

For Kubernetes clusters, deploy this via a privileged DaemonSet in kube-system. The OVHcloud advisory includes a ready-to-deploy manifest.

Beyond module blacklisting, a custom seccomp profile blocking socket() calls with domain=38 (AF_ALG) adds syscall-level enforcement on top. Deploy it cluster-wide via Kyverno or OPA Gatekeeper. This does not require a kernel update and works as defense-in-depth even alongside the module blacklist.

While you work toward patching, auditd rules on socket() calls with a0=38 from non-root processes catch every exploitation attempt at the syscall level. On Kubernetes, a Falco rule on AF_ALG socket creation from unexpected processes gives you alert coverage.

The strongest behavioral signal is the UID transition: a non-root process spawning a root child via a setuid binary is the exploit completing. That should never happen on a clean system. On Kubernetes with Cilium, a Tetragon TracingPolicy on sys_socket filtered to domain=38 hooks at the kernel level via eBPF, firing before the socket is fully created. In detection mode it surfaces the full process context (binary path, PID, namespace, container ID, pod metadata). With a Sigkill action it terminates the process before the exploit chain can advance, no CONFIG_BPF_KPROBE_OVERRIDE needed. The ZENDATA writeup has a solid summary of detection options across tools.

Audit setuid binaries on your nodes and container images while you’re at it:

find / -perm -4000 -type f 2>/dev/null

Remove the setuid bit from anything that doesn’t strictly need it.

Runtime Security: The Layer That Actually Tells You Something Is Happening

In most of the production environments I’ve worked with, runtime security is consistently the last thing to get budget or serious attention. The arguments I hear most: performance overhead is too high, there’s no budget for another tool, or endpoint EDR already covers it. These are real operational constraints. The conclusions they lead to, though, are wrong.

Copy Fail was silently present for nine years. It was patched within a week of public disclosure. During that window, and during every future window of this kind, the only control that works is detection and enforcement at runtime, at the kernel level. Disk integrity monitoring didn’t catch this. Network monitoring wouldn’t catch it. Static analysis missed it for nine years. The exploit leaves no disk trace. The only visibility comes from observing what actually executes, in memory, in real time.

If you have budget for a commercial solution, SentinelOne Singularity is worth serious consideration. The behavioral AI engine runs on Linux endpoints and Kubernetes nodes, and it does more than signature matching. It models process behavior continuously, catching anomalous SUID binary execution and the impossible UID transition (a non-root process spawning a root child via a corrupted binary) without requiring a specific rule for each CVE. That is the real advantage: it detects the behavioral pattern of an exploit, not just the known exploit. On top of that, Deep Visibility gives you full telemetry for retrospective hunting across your fleet, and STAR rules let you define automated response actions (kill process, network quarantine) that fire in real time. It ships ready to deploy, it has vendor support, and it does not require your team to maintain custom kernel policies. For most organizations, that operational simplicity is worth the cost.

If budget is the constraint, the open-source ecosystem has solid options, though each comes with its own operational tradeoff. Falco is the most accessible starting point: it monitors system calls and container events through a rules engine, integrates well with Kubernetes, and has a large community and pre-built rule sets. Writing and tuning Falco rules is approachable. Tetragon goes deeper: it hooks directly at the kernel level via eBPF, operates before a syscall completes, and can enforce a Sigkill action to terminate a process before the exploit chain advances. For Copy Fail, a Tetragon TracingPolicy on AF_ALG socket creation stops the exploit at step one. Combining both is a reasonable free-tier architecture: Falco for broad behavioral visibility and alerting, Tetragon for low-level enforcement on high-priority threats. Neither is as turnkey as a commercial agent, and both require investment to configure and operate well, but they are not theoretical and they run in production today.

CVEs are being analyzed and weaponized faster than they used to be. AI tooling accelerates vulnerability research in both directions. Supply chain attacks are discovered with increasing frequency, and the attack surface of a running cluster extends far beyond what pre-deployment scanning covers. Controls that only inspect artifacts before they run leave a large blind spot.

Patching is urgent. The deeper question is whether your infrastructure would have detected any of this if someone had used it quietly for months before public disclosure. I’ve seen runtime security deprioritized too many times. Every time a kernel-level CVE like this lands, the cost of that choice becomes a little clearer.

Sources