Copy Fail (CVE-2026-31431): AI finds a 732-byte exploit that gives root on any Linux since 2017

A logic flaw in the Linux kernel’s cryptographic subsystem has been exploitable for nearly a decade without anyone noticing. An AI found it in roughly an hour. The result: any unprivileged local user can get root on virtually every Linux distribution shipped between 2017 and the patch released in April 2026.

The assigned CVE is CVE-2026-31431 and the vulnerability is known as Copy Fail. The official page with all the details, the exploit, and the mitigation is at copy.fail.

What is Copy Fail and why is it different from other LPEs

Most Linux local privilege escalation vulnerabilities depend on race conditions or distribution-specific offsets, which significantly limits their real-world reach. Copy Fail needs neither. It is a straight-line logic flaw: the authencesn module in the kernel crypto subsystem uses the caller’s destination buffer as a scratch pad and writes 4 bytes past the legitimate output region without restoring them. Combined with AF_ALG and splice(), those 4 bytes end up landing in the kernel page cache on top of any setuid binary readable by the user.

The full exploit is 732 bytes of Python 3, no external dependencies, and runs unmodified on Ubuntu, Amazon Linux, RHEL, and SUSE. No offsets, no recompilation, no race window to win: it either fires or it doesn’t, and according to tests it always fires.

What makes it especially dangerous

What sets Copy Fail apart from most LPE CVEs is the combination of four properties that almost never appear together: it is portable across distributions without any adaptation, it is tiny and dependency-free, it is stealthy because the cache write never marks the page as dirty (nothing reaches disk — on eviction or reboot the cache reloads clean and a forensic image shows the original file), and it is also a container escape primitive because the page cache is shared across the entire host.

That last point is what turns a serious problem into a critical one for multi-tenant environments: any pod in a Kubernetes cluster, any CI runner executing code from an untrusted pull request, any shared notebook or serverless function, faces the same risk as a production server with multiple users.

How to mitigate it if you cannot patch yet

The patch is already in mainline (commit a664bf3d603d) and major distributions are shipping updated kernels. If you cannot patch immediately, the mitigation is to disable the algif_aead module:

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

For the vast majority of systems this breaks nothing. AF_ALG is not used by dm-crypt/LUKS, IPsec, kTLS, OpenSSL by default, or SSH. If in doubt, lsof | grep AF_ALG answers the question in a second.

The role of AI in the discovery

The vulnerability was found by Xint Code, an AI-powered auditing tool. The starting point was human: Taeyang Lee identified that splice() can push page-cache pages into the crypto subsystem and that scatterlist page provenance was an under-explored bug class. From there, the AI swept the entire crypto/ directory of the kernel in about an hour, and Copy Fail was the most severe finding in that run. It is not the only one: the rest are still in coordinated disclosure.

Official page with the exploit, full technical write-up, and disclosure timeline: https://copy.fail/