Copy Fail

On April 29, 2026, a researcher from the research team at Theori.io published details of a critical Linux kernel vulnerability: CVE-2026-31431, nicknamed Copy Fail. In short: a 732-byte Python script allows any unprivileged user to gain root access on virtually all modern Linux distributions — Ubuntu, Amazon Linux, RHEL, SUSE, and any other distribution built on kernels 4.13 or higher.

This flaw has been silently lurking in the code since 2017.

Why this CVE is not like the others

Three characteristics make Copy Fail particularly concerning for any cloud infrastructure, and even more so for those running containers.

It is trivially easy to exploit. No race condition, no finicky timing, no version-specific compiled payload. The same script works out of the box on every tested distribution, without modification. Where historical vulnerabilities like Dirty Cow or Dirty Pipe required a certain level of expertise, Copy Fail executes on the first try.

It is stealthy. The exploit modifies the in-memory version of a file (the kernel's page cache), but never the on-disk version. In practice, if your integrity monitoring tools compare file hashes stored on disk, they will see absolutely nothing. The /usr/bin/su binary remains intact on the filesystem, but when it is executed, the corrupted in-memory version runs — with root privileges.

It crosses container boundaries. The kernel page cache is shared across all processes on the same machine, whether containerized or not. This means an attacker who has compromised a single pod can potentially escalate to the Kubernetes node, and then impact all workloads running on it. Xint has also announced a follow-up article specifically dedicated to container escape on the major managed Kubernetes platforms.

What to do concretely

The fix was merged into the mainline Linux kernel on April 1, 2026. Distributions are progressively rolling it out through their standard update channels. Three actions are required.

1. Inventory your kernel versions. Every Linux kernel released after 2017 is affected until the patch is applied. On a Kubernetes cluster, this means auditing every node — whether it's an EC2 instance, GKE, AKS, or a self-managed VM.

2. Apply an immediate mitigation. While waiting for your distribution to publish its patched kernel, you can disable the vulnerable kernel module. For most containerized workloads, this has no functional impact. A more Kubernetes-native approach is to block the relevant syscall via a seccomp profile applied to your workloads.

3. Plan your node restarts. Once the patched kernel is available, applying the fix requires a reboot. On a production cluster, this calls for a drain-and-reinstate procedure, node by node, without any application-level downtime.

Final thoughts

Copy Fail illustrates a reality we regularly observe with our customers: the security of a Kubernetes cluster is not played out solely at the application or network level, but also — and above all — on the maintenance of the underlying Linux layer. A CVE of this magnitude requires a rapid inventory, a clean temporary mitigation, and then a coordinated patch rollout across your entire fleet.

If reading this article made you realize you don't know exactly which kernel versions are running on your nodes today, or how to orchestrate a coordinated patch without downtime, let's talk.