This Linux Exploit Quietly Gains Root Level Permission
This exploit has existed for nearly ten years but was only "officially" found and reported recently.
Since 2017 every major Linux distribution has been shipping a flaw that hands root access to any local user. This flaw is an exploit that is a 732-byte Python script. By default, the script only uses what comes with Python by default. It works on Ubuntu, Amazon Linux, RHEL, and SUSE without a single modification, leaves nothing on disk, and bypasses almost every file integrity monitoring tool in existence, because the file it corrupts is never actually written to.
This exploit is known as Copy Fail (CVE-2026-31431) and it was publicly disclosed on April 29, 2026. Like most Linux privilege escalation bugs, the kind that give a regular user administrator-level control over a system, require timing tricks, repeated attempts, and a bit of luck. That is not the case with Copy Fail. It is a straight-line logic flaw that executes cleanly every single time, on every tested distribution, without per-system adjustments.
It is important to note that this attack does not work from the outside. An attacker needs an existing user account on the system first, which is exactly what makes the CI/CD and shared server scenarios so relevant.
Every Linux system has a crypto interface called AF_ALG. This is a set of tools that any regular program, without special privileges, can use to perform encryption and decryption. It has been available for over a decade. A kernel function called splice() moves file data between processes without copying it, passing the original memory pages by reference instead. The page cache is where the kernel stores recently accessed files in memory so it does not have to go back to disk every time. When splice() hands data over, those original page cache pages go along with it.
So one might ask, has this been exploited in the wild? Zerodium, one of the best-known zero-day brokers before going dark in 2025, listed prices up to $500,000 for high-quality Linux privilege escalation bugs. Crowdfense, which still operates, goes up to $7 million, with the top of that range reserved for exactly this kind of bug: universal, reliable, no per-distribution adjustments required. It is nearly certain that this exploit has been utilized for many, many years.
This is what that the phyton script looks like:
a = socket.socket(38, 5, 0) # AF_ALG socket, no privileges required
a.bind((”aead”, “authencesn(hmac(sha256),cbc(aes))”))
# set key, accept request socket u
u.sendmsg([b”A”*4 + payload_chunk], [cmsg_headers], MSG_MORE)
os.splice(target_fd, pipe_wr, offset)
os.splice(pipe_rd, alg_fd, offset)
u.recv(...) # triggers decrypt, authencesn writes 4 bytes into page cache
The decryption call returns an error because the ciphertext is fabricated, but the four-byte write already happened and it is not rolled back. The script repeats this for each chunk of the payload, then executes the binary. In testing, the same script, unmodified, achieved root on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16.
What makes this so hard to detect is that the write goes through the kernel’s own crypto path, not through the file system. File integrity tools like Tripwire and AIDE compare checksums of files on disk, but nothing there changed. Inotify watches for file system events, and this write had none. From the perspective of every standard monitoring tool, nothing happened.
Now for the part that makes this worse in modern infrastructure. A container, think Docker or a Kubernetes pod, is not a separate machine. It shares the same kernel as the host and everything else running on that host. The page cache is part of the kernel, which means a process inside a container can corrupt page cache pages that belong to the host and to every other container running alongside it. Copy Fail is not just a local privilege escalation. It breaks through the container boundary entirely.
Cloud functions on microVM infrastructure like AWS Lambda and Fargate are not affected, because each tenant gets a completely separate kernel. Cloudflare Workers run on V8 isolates with no Linux kernel in the picture. gVisor interposes its own user-space kernel that does not share the host’s vulnerable code. The pattern is consistent: what holds is anything that does not share a kernel.
What to check and do right now:
1. Check your kernel version
2. Patch immediately
3. If patching is not possible blocked the vulnerable kernel module.
Stay safe out there. Layered security and vulnerability management are two keys precepts to being safe in a crazy and insecure world!

