Copy Fail: The 9-Year Linux Kernel Flaw That Hands Any Local User Root Access
CVE-2026-31431 lets any unprivileged user on virtually every major Linux distribution gain full root access using 732 bytes of Python. An AI found it in roughly one hour. Nobody spotted it for nine years.
Three separate kernel changes, written years apart by engineers who had no reason to connect them, quietly assembled a trap inside the Linux cryptographic subsystem. The last piece clicked into place in August 2017. Nobody noticed. Servers got deployed. Containers launched. Cloud providers scaled. And somewhere in the intersection of an IPsec helper module, a zero-copy file transfer mechanism, and a performance shortcut, a fully working privilege escalation waited.
On April 29, 2026, offensive security firm Xint.io published the full technical details of CVE-2026-31431, now publicly named Copy Fail. The flaw carries a CVSS 7.8 severity score, which sounds manageable until you read what it actually does: it gives any local user, no matter how restricted, a reliable path to full root on nearly every Linux system shipped since 2017. No race condition. No per-distro adjustments. No compiled payload. Just Python, and patience.
The discovery itself is almost as striking as the vulnerability. Theori’s Xint Code Research Team, using an AI-assisted analysis pipeline, surfaced Copy Fail as its highest-severity finding roughly an hour after pointing the system at the Linux kernel’s crypto/ subsystem. The same scan, the team noted, found additional high-severity bugs still working through coordinated disclosure.
A Bug Built in Three Acts
Copy Fail isn’t a single coding mistake. It’s the result of three individually reasonable kernel changes, each made years apart, that only become dangerous in combination.
Act One: 2011 – The authencesn Module
The authencesn module arrived in 2011 to handle IPsec ESP Extended Sequence Numbers, defined in RFC 4303. From the start, it used the caller’s destination scatterlist as scratch space to rearrange ESN bytes during decryption. This was entirely harmless: only the kernel’s internal xfrm layer ever called it, and the kernel controlled both ends of the operation.
Act Two: 2015 – The AF_ALG AEAD Socket
In 2015, the AF_ALG interface gained AEAD support, including a splice() path that could deliver pages directly from the page cache into the cryptographic subsystem. authencesn was converted to the new AEAD interface. Still not exploitable: AF_ALG used out-of-place operations, keeping input and output buffers separate.
Act Three: August 2017 – The In-Place Optimization
A performance optimization in algif_aead.c changed how decryption handled memory. For efficiency, the new code copied AAD and ciphertext into an output buffer, but chained the authentication tag pages by reference using sg_chain() and then set req->src = req->dst, creating an in-place operation. Page cache pages delivered via splice() were now sitting inside the writable destination scatterlist. The trap was set.
The core insight: Nobody connected the 2017 in-place optimization to authencesn‘s scratch writes or to splice()‘s page cache delivery mechanism. Each change was reasonable in isolation. The vulnerability lives entirely at their intersection, across a six-year window and three separate subsystems.
How the Exploit Actually Works
The attack chain is deceptively clean. An unprivileged user opens an AF_ALG socket bound to authencesn(hmac(sha256),cbc(aes)) and uses the standard splice() system call to transfer pages from a readable target file into the socket. No special permissions. No kernel modules. Nothing that triggers standard audit rules.
Inside the kernel, the 2017 in-place optimization causes those file pages to end up in the writable destination scatterlist. When authencesn‘s decrypt routine runs, it writes four bytes at an offset past the AEAD tag, directly into what it believes is its own output buffer. Those bytes land in the kernel’s cached copy of the target file.
“An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.”
Xint Code Research Team, Theori — xint.io
The write fails HMAC verification and recvmsg() returns an error. The caller sees a failed decryption. But the four-byte write into the page cache persists. Repeat the process across targeted offsets of a setuid binary, and the kernel’s cached version of that binary contains attacker-controlled code. Call execve() on it, and the kernel loads from the page cache rather than disk.
Stealth note: The corrupted page is never marked dirty for writeback, so the file on disk remains unchanged. Disk-based integrity checks and standard checksums won’t catch the modification. The in-memory version, which is what actually executes, is corrupted system-wide.
The result is a four-property combination that the Xint team describes as nearly unique in their experience:
Portable
Confirmed working on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16 with no per-distro modifications.
Tiny
The full working proof-of-concept is 732 bytes of standard-library Python. No compiled payload, no external dependencies.
Stealthy
Disk-based integrity checks see nothing. The modification exists only in the page cache, invisible to on-disk forensic tools.
Cross-Container
Container isolation doesn’t stop it. Part two of Theori’s research series covers a full Kubernetes container escape using the same primitive.
“This vulnerability is unique because it has four properties that almost never appear together: it’s portable, tiny, stealthy, and cross-container. It allows any user account, no matter how low-level, to increase their privilege to full admin access.”
Xint.io Spokesperson, Theori — xint.io
The Scale of Exposure
Linux isn’t just popular on servers. It is, for practical purposes, the substrate on which the cloud runs. The numbers make the exposure concrete.
| Platform | Linux Share | Implication |
|---|---|---|
| Google Cloud VMs | 91.6% | Highest Linux density of any major cloud provider |
| AWS EC2 Instances | 83.5% | Amazon Linux 2023 directly confirmed vulnerable |
| Microsoft Azure VMs | 61.8% | Majority of Azure workloads run affected kernels |
| Public Cloud Overall | ~90% | CNCF estimate across combined AWS/Azure/GCP infrastructure |
| Production Kubernetes | 96.4% | Container escape risk affects nearly all K8s deployments |
The affected kernel range compounds the problem. Theori confirmed the exploit works across kernel versions 6.12, 6.17, and 6.18. The vulnerable commit dates to August 2017, meaning any system running a kernel from that point forward and exposing AF_ALG sockets to unprivileged users is potentially affected. That’s essentially every major distribution shipped in the past nine years.
Shared hosting environments face the most acute risk. A single compromised tenant account can traverse to root, from which the entire host is accessible. Multi-tenant SaaS platforms, university computing clusters, and developer PaaS environments all sit in this category.
“732 bytes of Python. Root on every major Linux distribution shipped since 2017. No race conditions. No per-distro offsets. No version checks. 100% success rate.”
Brian Pak, Xint Code Research Team, Theori — xint.io
AI Found It in One Hour
The vulnerability’s discovery story is, in many ways, just as significant as the vulnerability itself. Taeyang Lee, a researcher at Theori, formed an initial hypothesis: the combination of AF_ALG sockets and splice() creates a path where unprivileged userspace can feed page cache pages directly into the crypto subsystem, and that scatterlist page provenance might be an underexplored source of vulnerabilities.
Rather than manually auditing the kernel’s crypto subsystem, the Xint Code Research Team fed that one-line hypothesis into an AI-assisted scanning pipeline pointed at crypto/. About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs that are still working through coordinated disclosure.
“About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs, still in coordinated disclosure.”
Xint Code Research Team, Theori — xint.io
The implications for the security research field are hard to overstate. Traditional manual kernel audits are expensive, slow, and require deep specialist knowledge. This approach condensed what might have been weeks of expert review into a single hour of autonomous scanning. The economics of vulnerability discovery are shifting, and not symmetrically: defenders don’t automatically get faster just because attackers do.
David Brumley, Chief AI and Science Officer at Bugcrowd, drew a direct line between Copy Fail and earlier high-profile kernel primitives in a post on Bugcrowd’s research blog:
“Copy Fail is the same class of primitive, in a different subsystem. The 2017 in-place optimization in algif_aead allows a page-cache page to end up in the kernel’s writable destination scatterlist for an AEAD operation submitted over an AF_ALG socket. An unprivileged process can then drive splice() into that socket and complete a small, targeted write into the page cache of a file it doesn’t own.”
David Brumley, Chief AI and Science Officer, Bugcrowd — bugcrowd.com
Logic bugs like Copy Fail are particularly hard for humans to spot. Memory corruption flaws produce signals: crashes, sanitizer output, fuzzer hits. A logic bug that writes to the right memory location, through the right interfaces, in a sequence that spans three subsystems and six years of kernel history, produces nothing. It just works.
Patching: Fast Upstream, Slow Everywhere Else
The upstream kernel response was fast. Theori reported the flaw to the Linux kernel security team on March 23, 2026. An initial acknowledgment came the next day. Patches were proposed and reviewed by March 25. The fix landed in the mainline kernel on April 1, 2026, via commit a664bf3d603d, which reverts the 2017 in-place optimization. Upstream patch time: under 10 days from report to commit.
The problem is what happens after that. Enterprise deployments average 60 to 90 days to roll out Linux patches after vendor releases, according to Qualys TruRisk data. Roughly 15 to 25 percent of systems running older LTS kernel branches wait more than 100 days. The gap between “patch exists” and “patch deployed” is where attacks happen.
| Stage | Typical Timeline | Status for CVE-2026-31431 |
|---|---|---|
| Upstream kernel patch | 24-48 hours (critical) | Committed April 1, 2026 |
| Distro security advisory | Days to weeks | Debian and SUSE advisories published |
| Enterprise deployment | 60-90 days average | Majority of systems still unpatched |
| LTS branch backport | Varies widely | 15-25% may wait 100+ days |
For immediate mitigation before patching is possible, administrators can restrict AF_ALG socket access using seccomp profiles or AppArmor/SELinux policies. The Debian security tracker and SUSE CVE advisory both carry current package status for their respective distributions.
Action required: Check your kernel version against your distribution’s patched release. On systems where live patching isn’t available, restrict AF_ALG socket creation for unprivileged users as an interim control. Container workloads should be treated as high priority given the forthcoming Kubernetes container escape research.
Disclosure Timeline
Copy Fail followed a thorough coordinated disclosure process, giving vendors and distributors time to prepare patches before full public release.
| Date | Event |
|---|---|
| August 2017 | Vulnerability introduced via in-place optimization commit in algif_aead.c |
| March 23, 2026 | Theori reports flaw to Linux kernel security team |
| March 24, 2026 | Kernel security team acknowledgment received |
| March 25, 2026 | Patches proposed and reviewed |
| April 1, 2026 | Fix committed to mainline kernel (commit a664bf3d603d) |
| April 22, 2026 | CVE-2026-31431 officially assigned |
| April 28, 2026 | Bugcrowd blog post published by David Brumley |
| April 29, 2026 | Full public disclosure via xint.io; The Hacker News coverage published |
| April 30, 2026 | Heise.de German-language coverage; broader security community response |
Theori has also confirmed that this is part one of a two-part research series. Part two will detail a Kubernetes container escape built on the same underlying primitive. Container security teams should treat this as an active, evolving situation rather than a closed incident.
Frequently Asked Questions
What is CVE-2026-31431 (Copy Fail)?
CVE-2026-31431, called Copy Fail, is a local privilege escalation flaw in the Linux kernel’s algif_aead cryptographic interface. It allows any unprivileged local user to write four controlled bytes into the kernel page cache, enabling root access on any major Linux distribution shipped since August 2017.
Which Linux distributions are affected by Copy Fail?
Confirmed affected distributions include Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16. Any Linux distribution running a kernel from August 2017 onward with the authencesn and algif_aead modules is likely affected. Debian and SUSE have published security advisories with current patch status.
How do I know if my system is patched?
Check your running kernel version against your distribution’s patched release. The upstream fix landed on April 1, 2026, in mainline commit a664bf3d603d. Check the Debian security tracker or your distro’s equivalent CVE advisory page for the specific patched package version.
Does Copy Fail affect cloud virtual machines?
Yes. Cloud VMs running unpatched Linux kernels are vulnerable to any user who can execute code on the instance. This includes multi-tenant environments. Cloud providers run Linux on over 60% to 91% of VMs depending on the platform, making this a high-priority patch for cloud workloads.
Does Copy Fail work inside containers?
Yes. Container isolation does not prevent exploitation because the flaw exists in the host kernel’s page cache, which is shared across containers. Theori has confirmed a full Kubernetes container escape using the same primitive; full details are expected in a forthcoming Part 2 research post.
Why did this go undetected for nine years?
The vulnerability exists only at the intersection of three kernel changes made in 2011, 2015, and 2017 across separate subsystems. Logic bugs don’t produce crashes or fuzzer signals. Each individual change was reasonable in isolation, making the combined effect essentially invisible to standard review and testing processes.
What’s the interim mitigation if I can’t patch immediately?
Restrict AF_ALG socket creation for unprivileged users via seccomp filter policies, AppArmor profiles, or SELinux policy rules. This blocks the attack path without requiring a kernel update. Verify your container runtime and Kubernetes policies also restrict this system call for workloads running as non-root users.
How significant is the AI-assisted discovery angle?
Theori’s AI pipeline found Copy Fail in roughly one hour from a one-line research hypothesis. The same scan identified additional high-severity bugs still in coordinated disclosure. This suggests AI tools can compress vulnerability discovery timelines from weeks to hours, changing the economics of both offensive and defensive security research significantly.
What Comes Next
Copy Fail is a clean illustration of how complexity creates risk in long-lived software. The Linux kernel is audited more thoroughly than virtually any codebase on earth, yet a logic bug spanning three subsystems and six years of history slipped through every review. The flaw wasn’t in any single commit. It was in the space between them.
The AI discovery angle changes the calculus going forward. If a one-line hypothesis fed into an autonomous scanner can surface a CVSS 7.8 kernel flaw in an hour, the assumption that lightly funded attackers lack the research capacity to find such bugs needs revisiting. The same tools available to Theori’s researchers are available to anyone willing to build or buy similar infrastructure. Coordinated disclosure and rapid upstream patching matter more than ever, because the window between bug introduction and discovery is likely to shrink.
For enterprise security teams, the immediate priority is simple: patch, or restrict AF_ALG access today. The 60-to-90-day average remediation window is a liability Copy Fail was designed to exploit. And with Part 2 of Theori’s research series, covering the Kubernetes container escape, still to come, the organizations most at risk may not have fully mapped their exposure yet.