Copy Fail (CVE-2026-31431): An AI-Assisted Audit Surfaced a Linux Kernel Bug That Roots Every Distribution Since 2017

Severity: High (CVSS 7.8), but the impact reads like a 9

Status: Public disclosure April 29, 2026. Patches landing across major distributions now

TL;DR

A new Linux kernel vulnerability called Copy Fail (CVE-2026-31431) lets any unprivileged user become root on essentially every Linux distribution shipped in the last nine years. The exploit fits in a 732-byte Python script. It works on the first try, no race conditions, no per-distribution tuning. It corrupts files in memory only, so disk-based integrity checks miss it entirely. It crosses container boundaries.

And it was surfaced by an AI-assisted audit in roughly an hour of scan time.

That last part is the most important sentence in this entire post. We'll come back to it.

If you run Linux anywhere (bare metal servers, Kubernetes clusters, CI runners, multi-tenant cloud platforms, developer workstations), patch your kernel today. If you can't, disable the algif_aead module immediately. Detailed mitigation below.

What Copy Fail does, in plain English

Most Linux privilege-escalation bugs are picky. They need precise timing windows ("races"), kernel addresses leaked from somewhere, or careful tuning per distribution. Copy Fail needs none of that.

The attacker needs one thing: a normal user account on the machine. From there, the exploit script asks the kernel to do some encryption work, abuses how that work is wired up internally, and ends up writing 4 controlled bytes into Linux's in-memory copy of any file the user can read. Those 4 bytes can be aimed at any program the system trusts, for example /usr/bin/su, the standard shortcut to becoming root. The next time anyone executes that program, the attacker becomes root.

This works on Ubuntu, Amazon Linux, Red Hat Enterprise Linux, SUSE, and almost certainly every other mainstream distribution. Same exact script. No version checks. No recompilation.

The detail that changes everything

Most file-tampering attacks have one thing going against them: the file on disk gets modified, so file-integrity tools eventually notice. Copy Fail does not modify the file on disk. It modifies Linux's page cache, which is the high-speed in-memory copy of files that the kernel uses to serve every read, every memory map, every program execution.

The on-disk file is byte-for-byte unchanged. Image the drive, run a checksum, the file matches the official package hash exactly. Reboot the machine, or just put it under enough memory pressure that the kernel evicts and reloads the cached page, and the corruption disappears. Until the attacker triggers it again.

For incident response, this is a substantially harder kind of compromise to prove after the fact. For attackers, this is a substantially better kind of compromise to deploy.

Containers do not help

A lot of teams hear "local privilege escalation" and reach for the same comfort: "we use containers, the blast radius is contained." Not here. The page cache is shared across the entire host kernel. It doesn't care about cgroups, namespaces, or container boundaries. A process inside a single compromised pod can use Copy Fail to compromise the underlying host, and from there reach into every other tenant on the same node.

This means Copy Fail is not just a Linux server bug. It is a:

• Multi-tenant SaaS platform bug
• CI runner bug (GitHub Actions, GitLab Runners, Jenkins agents)
• Kubernetes node compromise bug
• Cloud sandbox bug (notebooks, agent runtimes, serverless functions executing user code)
• Shared developer infrastructure bug (jump hosts, build servers, dev VMs)

If your security model assumes containers contain untrusted code, that assumption breaks the moment a Copy Fail-class bug lands. Theori has stated they will publish a Part 2 on the Kubernetes container escape, so expect detailed POCs for the orchestration layer next.

How a 2017 optimization became a 2026 root primitive

Copy Fail is the result of three reasonable changes that, individually, all looked fine. Together, they created a vulnerability that sat untouched for nearly nine years.

2011: A kernel module called authencesn was added to support IPsec's 64-bit Extended Sequence Numbers. To rearrange some bytes during HMAC computation, it used the caller's destination buffer as scratch space. At the time the only caller was the kernel's internal IPsec layer, so nobody noticed the temporary writes.

2015: The kernel exposed its crypto subsystem to userspace through AF_ALG sockets, including a splice() path that could pass file pages by reference into crypto operations. Still safe at this point, because the source and destination buffers were separate, so the scratch writes only touched the user's own memory.

2017: A performance optimization was added to algif_aead.c that combined source and destination into a single in-place buffer. From this commit forward, page cache pages of the user's chosen file ended up sitting in the writable destination scatterlist, separated from the legitimate write region by nothing more than an offset boundary.

authencesn's decade-old scratch write, once harmless, was now reaching across that boundary and writing 4 controlled bytes into the page cache of any readable file.

Each change was reasonable in isolation. The vulnerability exists at the intersection of all three. This is the most common shape of long-lived bugs in mature systems: not a single careless mistake, but a quiet collision between three correct-looking decisions made years apart.

What you actually need to do

Patch the kernel

The fix is mainline commit a664bf3d603d, which reverts the 2017 in-place optimization in algif_aead.c. Major distributions began shipping fixed kernels on April 29, 2026:

• Ubuntu: apply available kernel package updates
• Amazon Linux: dnf upgrade kernel and reboot
• RHEL / CentOS Stream: package updates rolling out; check access.redhat.com/security/cve/cve-2026-31431 for current status
• SUSE / openSUSE: zypper update kernel-default and reboot
• Debian: security-tracker.debian.org/tracker/CVE-2026-31431

Verify your kernel version after update and reboot. The page cache only refreshes from disk after a reboot or sufficient memory pressure, so a reboot also clears any corruption that may have been planted before patching.

If you cannot patch immediately

Disable the vulnerable kernel module. This is a one-liner that closes the entire attack surface:

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

Verify it stuck:

lsmod | grep algif_aead       # should return nothing
cat /etc/modprobe.d/disable-algif.conf   # should show the install line

This costs you almost nothing. The algif_aead interface is used by a handful of niche userspace crypto libraries; the overwhelming majority of systems will never miss it.

For untrusted-code environments, go further

If you operate any environment that runs code on behalf of others (multi-tenant SaaS, CI runners with public PRs, agent sandboxes, notebook environments), block the entire AF_ALG socket family at the seccomp layer, even after patching. Almost nothing legitimate needs userspace access to the kernel crypto API, and blocking it eliminates an entire class of future bugs in the same subsystem. There will be more.

Hunting for prior compromise

Standard file integrity monitoring will not detect Copy Fail, because the on-disk file is unchanged. The corruption is page-cache-only and ephemeral. That said, a few signals are worth checking:

• Unexpected setuid binary behavior. Users escalating to root, or processes spawning under unexpected UIDs, in time windows that don't match scheduled jobs.
• AF_ALG socket usage. Most production systems should have near-zero AF_ALG socket activity from non-root processes. Audit your kernel audit logs for socket(AF_ALG, ...) calls from unexpected UIDs.
• Unusual splice() patterns between file descriptors and pipes from non-root processes targeting setuid binaries.
• Reboot history. The page cache corruption does not survive a reboot. A successful exploit chain may include unusual restarts or long uptime windows where the implant lived in memory only.

If you find indicators, treat the host as compromised. Rotate every credential reachable from that machine, rebuild from clean artifacts, and do not assume disk-based forensics will surface anything.

The part that should worry CISOs more than the bug itself

Copy Fail was surfaced by Xint Code, an AI-assisted security audit tool built by Theori. The discovery began with an insight from Theori researcher Taeyang Lee, who had been studying how the Linux crypto subsystem interacts with page-cache-backed data. He used Xint Code to scale that hypothesis across the entire crypto subsystem. The operator prompt was three sentences. The scan ran for about an hour. Copy Fail was the highest-severity finding in the run. The same scan surfaced other high-severity vulnerabilities still under coordinated disclosure.

This is not "AI replaced the researcher." It is something more important: a senior researcher's intuition about an underexplored attack surface, multiplied across an entire kernel subsystem in an hour, with results good enough to ship.

Theori is not a startup chasing attention. They have won DEF CON CTF nine times. They placed in the finals of DARPA's AI Cyber Challenge. When they describe one prompt and one hour leading to a zero-day in a kernel subsystem the entire world has been looking at for two decades, that statement should be taken at face value.

The implication is simple but uncomfortable: the supply of newly discovered kernel-grade bugs is no longer bounded by how many researchers can manually read kernel code. Patch cycles, vulnerability budgets, asset inventory expectations, container threat models, and even the basic shape of a CISO's annual planning all assume that finding a kernel-grade bug is expensive. Copy Fail demonstrates that assumption is becoming false going forward.

Three concrete things change as a result:

Patch latency becomes a much sharper edge. If the next Copy Fail-class bug ships from disclosure to public PoC in 24 hours instead of 6 weeks, "we patch on a 30-day cadence" stops being a viable security posture. The teams that win this decade will be the ones that can detect "is this CVE in our stack, and how exposed are we, right now" in minutes, not in the next monthly patch review.

Shared-kernel multi-tenancy is a riskier default than it used to be. "Containers on a shared host kernel" was always a weak isolation story; Copy Fail makes it concrete. If your isolation model is namespace boundaries, the threat model now needs hardware or VM boundaries (gVisor, Firecracker, Kata, or full VM separation) for any workload running untrusted code.

Asset inventory and CVE tracking move from "good practice" to "load-bearing." When the rate of newly discovered bugs accelerates, the bottleneck shifts from finding bugs to finding yourself in the bugs. Teams that can't answer "what kernel versions do we run, and where" within minutes will be reading about their own breach in someone else's disclosure post.

A short list of CVEs to track this exact pattern

In the last 60 days alone, we have covered three CVEs that share Copy Fail's shape, all long-lived bugs in foundational software, all exposed by patient research:

• MCPwn (CVE-2026-33032): a single missing line of authentication middleware in nginx-ui, sitting unnoticed since the MCP integration shipped. Same kind of "obvious in retrospect" logic flaw. (Our writeup)
• Adobe Reader CVE-2026-34621: a prototype pollution flaw silently exploited for months before public disclosure. Same kind of "the on-disk file looks fine" detection problem. (Our writeup)
• Axios npm supply chain attack: three hours of malicious package availability, North Korean attribution, an estimated 3% of the userbase compromised. Same kind of "trust assumption invalidated by an upstream change" failure. (Our writeup)

The pattern across all four is consistent: foundational components, decade-old assumptions, ephemeral exposure windows, and on-disk artifacts that don't tell the whole story. AI-assisted research is going to surface more of these, faster.

How VulnTracker fits

We built VulnTracker for the world Copy Fail represents: where new critical CVEs land overnight, where the affected components live multiple layers below your application code, and where "is this in our stack?" needs an answer in minutes.

If you tell us the Linux distributions and kernel versions you run, we tell you the moment a CVE-2026-31431-class flaw surfaces in any of them, with exploitation context (KEV listing, EPSS, public PoC availability) so you can prioritize the response. No advisory feed parsing, no spreadsheets, no Friday afternoon Slack panic.

If you're tracking Linux infrastructure manually right now, start a 5-day free trial and let us cut the noise for you. If you just want to stay informed without setting up tracking yet, our daily digest is free and covers the CVEs worth knowing about.

Either way, the next Copy Fail is coming. The question is how quickly you'll find out.

Timeline

Track the Linux kernel, container runtimes, and the CVEs hitting your stack from one place. Start your 5-day free trial at vulntracker.io.

We hope your company is the one hackers skip.