Copy Fail is a new Linux kernel zero-day that allows any authenticated user to gain root privileges (Local Privilege Escalation, or LPE) on almost every Linux distribution since 2017. An easy-to-use exploit is already public.
If you described this bug to a top kernel researcher—give me a universal Linux LPE, works across major distributions, no race window, no per-kernel offsets, clean container-escape primitive—they probably wouldn’t give you a timeline. They’d tell you this is the kind of thing that, when it exists at all, tends to sell on the broker market for the price of a house.
Zerodium’s public price list paid up to $500,000 for a high-end Linux zero-day before the platform went dark in early 2025. Today’s gray-market acquirers like Crowdfense run programs in the $10K–$7M range, with the top of that band reserved for exactly this kind of universal, reliable primitive.
According to the writeup, an AI system surfaced one in about an hour. I had to read that twice, and then actually run it, before I believed it. It’s real.
The bug is Copy Fail (CVE-2026-31431), disclosed today by Theori. A 732-byte Python script roots Ubuntu, Amazon Linux, RHEL, and SUSE — every Linux build since 2017 — through a logic flaw in the kernel’s crypto API. Theori’s writeup states that it was “surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem,” with “one operator prompt, no harnessing.”
Theori isn’t a startup trying to get attention. They’re one of the strongest offensive security teams in the world. As MMM (with CMU’s PPP and UBC’s Maple Bacon), they’ve won DEF CON CTF nine times. They also took third in the finals of DARPA’s AI Cyber Challenge. Xint Code is the system they built.
When Theori says “one prompt, one hour,” my default assumption is they probably did exactly that.
The bug matters. The way it was found matters more.
Before getting into the implications, it’s worth grounding what the bug actually is.
The closest reference point is Dirty Pipe (CVE-2022-0847), the 2022 Linux LPE that lets an unprivileged user splice data into the page cache of read-only files, including setuid binaries.
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.
Four properties make this dangerous in containerized environments:
Why was it missed for nearly a decade? Probably because crypto/ is heavily reviewed from a crypto lens, looking for properties like IND-CPA security, side channels, and parameter validation. Copy Fail is fundamentally about where the memory came from and whether the kernel should ever be writing through it. That’s a different type of question, and probably why it went missed.
Every major security tool, from static analysis to fuzzers, has found amazingly wide-spread bugs that have lurked for years. It’s always weird to me when people point out “AI found 500 new bugs”, as projects like OSS-fuzz and Mayhem have been doing that for years.
What changed is who can drive the tool and how fast they can get results.
The same class of system that produces this for a team like Theori can plausibly produce useful output for someone with far less experience. The skill curve for using a serious vulnerability discovery tool is starting to look a lot more like the skill curve for reading its output.
A couple of consequences fall out of that:
There’s an obvious counterpoint: maybe this is a one-off. Maybe Xint Code got lucky in crypto/, and the next ten subsystems won’t look like this. That’s possible. But we’ve seen this pattern before with symbolic execution, fuzzing, and hybrid approaches. Each time, though, the technology has proven to unlock a new set of critical bugs, and should be taken seriously.
The cloud-native posture of the last decade has been to treat the Linux container as a defense-in-depth layer. “Run untrusted code in a container, so even if it’s malicious, it can’t reach the host.” Copy Fail puts real pressure on that posture because the page cache is host-wide and the primitive is reliable.
Don’t be fooled by the “high” (not critical) CVSS score. If your stack runs untrusted code and the isolation story has the word “container” in it without the word “microVM,” “gVisor,” or “dedicated host” right after it, Copy Fail is in your threat model.
Three surfaces are exposed by exactly this assumption today:
What doesn’t break under Copy Fail is exactly what wasn’t a Linux container in the first place. AWS Lambda and Fargate run on Firecracker microVMs—separate kernels per tenant, no shared page cache. Cloudflare Workers run on V8 isolates, with no Linux kernel in the threat model at all. gVisor interposes a user-space kernel that does not share the host’s algif_aead. The pattern is consistent: the boundaries that hold are the ones that don’t share a kernel.
Patch cycles, vulnerability budgets, and CVE prioritization are all built on a hidden assumption: that finding a kernel-grade bug is expensive, so the supply of new ones is roughly bounded by how many people are looking. Copy Fail shows that assumption is false going forward.
I see three practical implications:
Theori was founded by people I had the privilege to first teach, and then watch as they became some of the world’s most elite hackers. They did not pivot to AI exploit development to chase a trend. They pivoted because the math now favors it.
Theori isn’t alone here. Most of the best vulnerability researchers I know—people who routinely make millions in responsible disclosure—are all using AI to be more productive. This isn’t a bad thing. In some ways, it means certain classes of problems get solved faster, and experts can move on to harder ones.
Copy Fail is not a story about a single bug, or about one team’s tooling. It’s a data point that the cost of finding deep logic flaws may have dropped by something like an order of magnitude.
If your threat model still budgets kernel LPEs as rare, you probably have weeks to update that—not years.
Agree or disagree? Tell me where I’m wrong.