The new domain at copy.fail looks like a slick browser exploit demo. It is not. The site is the public disclosure page for CVE-2026-31431, a Linux kernel local privilege escalation that landed on 29 April 2026 and that you should care about even if you do not personally run a Linux server. The name is a pun on the underlying defect: the kernel's in-place AEAD copy fails to protect page-cache integrity. The consequence is that any unprivileged local user on a vulnerable kernel can become root on most Linux distributions shipped since 2017, leaving no trace on disk for file-integrity tooling to find.
I want to walk through why this matters for hosting, Kubernetes, CI/CD and ordinary developer laptops, and what makes copy.fail different from the long line of similar bugs that came before it.
TL;DR
- copy.fail is a Linux kernel local privilege escalation, not a browser or clipboard attack. Disclosed by Theori on 29 April 2026 with a working PoC.
- It abuses the kernel crypto API (
AF_ALGsockets) plussplice()to write four bytes at a time straight into the page cache of a file the attacker does not own. - The exploit works unmodified across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Fedora and most others. No race condition, no per-distro offsets.
- The file on disk is never modified. AIDE, Tripwire and checksum-based monitoring see nothing.
- Kubernetes Pod Security Standards (Restricted) and the default
RuntimeDefaultseccomp profile do not block the syscall used. A custom seccomp profile is needed. - The mainline fix landed on 1 April. Distros are rolling kernels out now. Patch.
What copy.fail actually is
"Local privilege escalation" sounds dry, so let me unpack it. It means: an attacker who already has some way to run code on the machine, even as the most boring unprivileged user, can promote themselves to root. From there they can read every file, install backdoors, watch every process, and pivot to other systems.
Why does that matter on shared infrastructure? Because "local" covers a lot of ground in 2026: every container on a shared Kubernetes node, every tenant on a shared hosting box, every CI/CD job that runs untrusted pull-request code, every WSL2 instance on a Windows laptop, every containerised AI agent given shell access. They all share one Linux kernel with their neighbours. A kernel LPE collapses that boundary.
The realistic threat chain looks like this. An attacker exploits a known WordPress plugin vulnerability and gets shell access as www-data. They run the copy.fail PoC. They are now root on the host. Every other tenant is suddenly reachable, in the way I walked through in this hack post-mortem. The vulnerability does not get the attacker onto the box; it changes what happens in the next ten seconds after they land there.
How the bug works
The disclosure page and the longer technical writeup from Theori describe a clean three-feature collision in the Linux kernel:
AF_ALGsockets, in-tree since 2015, let any unprivileged user ask the kernel to perform cryptographic operations. You open a socket, name the algorithm, send data, receive output.splice()with page-cache pages hands page references (not data copies) into the kernel. When you splice a regular file into a socket, the same physical pages that back every other read of that file system-wide are now part of the request.- In-place AEAD operation, switched on for
AF_ALGin 2017 as a performance optimisation, makes the input and output scatterlists point to the same memory.
Combine those with a quirk in the authencesn AEAD template (the one used for IPsec extended sequence numbers): authencesn writes four bytes of scratch data into the destination buffer at a controllable offset. With in-place mode active and a spliced file as the input, that destination buffer is the page cache. Four attacker-controlled bytes go straight into the kernel's cached copy of, say, /usr/bin/su (a setuid root binary that every user can read). Repeat until the binary contains your payload. Run it. The kernel loads from page cache, not disk. You execute as root.
There is no race condition. There is no kernel ASLR bypass to do. The same script that works on Ubuntu 22.04 also works on Amazon Linux 2023 and SUSE 15.6 and Debian bookworm. Theori's PoC repository went public the day of disclosure.
The closest historical comparison is Dirty Pipe (CVE-2022-0847), which also wrote into the page cache through a splice-based primitive. Dirty Pipe required kernels 5.8 or newer, which let a lot of LTS environments off the hook. copy.fail reaches back to the 2017 in-place AEAD commit. That is a much wider net.
Why your container won't save you
This is the part operators should sit up for. The team at Juliet.sh tested copy.fail inside Kubernetes. They confirmed that PSS Restricted does not block AF_ALG socket creation. Neither does the default RuntimeDefault seccomp profile that ships with containerd on the runtimes they tested (Talos and Amazon EKS). A pod conforming to your strictest workload security policy can still call socket(AF_ALG, ...) and reach the vulnerable code path. (One nuance worth flagging: the published PoC targets /usr/bin/su, so on minimal immutable distros without setuid binaries an attacker has to retarget another in-cache binary, but the kernel primitive itself stays reachable.)
The Kubernetes Pod Security Standards never had a reason to block this syscall. It looks innocuous. The pattern, which I went into in the multi-tenant Kubernetes governance article, is a recurring one: defaults that look adequate today rarely anticipate next year's exploit class. CERT-EU's advisory 2026-005 now recommends adding a custom seccomp profile that explicitly denies AF_ALG socket creation, regardless of patch state.
A few isolation models do hold up. AWS Lambda and Fargate run on Firecracker microVMs with separate kernels per tenant. Cloudflare Workers use V8 isolates. gVisor interposes a user-space kernel that does not implement algif_aead. If your workload runs there, you are not exposed via this CVE. If it runs on a shared kernel, you are.
Why file-integrity tools won't see it
Page-cache corruption never marks the page dirty. The kernel's writeback machinery never flushes the modified bytes back to disk. After a successful exploit, sha256sum /usr/bin/su returns the expected hash. AIDE, Tripwire, OSSEC and any monitoring tool that compares on-disk checksums see nothing. Yet every process that loads that binary on the host gets the corrupted in-memory version, until the page is evicted or the system reboots.
This is the property that makes copy.fail unusually nasty. The compromise is invisible to the controls many regulated environments lean on. Detection has to move to syscall auditing (alert on socket() calls with AF_ALG from non-root users), eBPF probes on the affected code path, or behavioural alerting on unexpected privilege escalations. None of those are common defaults.
The bigger story: an AI tool found this in an hour
The most striking detail in Theori's writeup is not the bug itself. It is the discovery method. Theori's commercial code-analysis tool Xint Code, publicly launched in March 2026, surfaced the bug in roughly an hour of analysis on the Linux crypto/ subsystem from a single operator prompt. A human researcher framed the hypothesis. The tool scaled it.
Bugcrowd's analysis frames it bluntly: the cost of finding deep kernel logic flaws may have dropped by an order of magnitude. That cuts both ways. Defenders can audit their own codebases faster. Attackers, including the ones with worse motives than Theori, can hunt the next copy.fail with less effort than before. The same shift that just produced a clean, responsibly-disclosed kernel bug is also the shift that drove curl to end its bug bounty programme last month under a wave of low-quality AI-generated reports. Both trends are downstream of the same tooling.
What to do now
Patch your kernels. The fix landed in mainline on 1 April 2026 (commit a664bf3d603d) and was backported to stable 6.18.22 and 6.19.12. Track your distro's advisory:
- Ubuntu: every current LTS release (16.04 through 24.04) is affected. Ubuntu 26.04 on kernel 7.0 is not.
- Red Hat: RHEL 10.1 confirmed affected, fixes shipping.
- Debian: fixed in
forkyandsid.bullseye,bookwormandtrixieare still vulnerable as of 30 April. - SUSE: security update published 30 April.
- Amazon Linux: "Pending Fix" across the relevant packages on 30 April.
- CloudLinux KernelCare offers a live patch, which is useful for shared hosting where reboots are painful.
If you cannot patch this week, the practical mitigations from the oss-security disclosure and the CERT-EU advisory are: blacklist the algif_aead module (echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf), or for kernels that compile it in, add initcall_blacklist=algif_aead_init to the kernel command line. For Kubernetes, ship a custom seccomp profile that denies socket(AF_ALG, ...) across the cluster.
If you have shell users, CI/CD runners or multi-tenant containers on Linux hosts, treat this as urgent. A Linux system serving only its own first-party application from a hardened image, with no untrusted code execution, is at much lower practical risk and can wait for the regular patch cycle. The press coverage so far (The Register, Help Net Security) reports no in-the-wild exploitation yet, but the PoC is public and the window between "PoC available" and "opportunistic abuse" historically closes in days.
Key takeaways
- copy.fail (CVE-2026-31431) is a Linux kernel privilege escalation, not a browser or clipboard bug. The cute name hides a serious primitive.
- The same exploit script works across nearly every modern Linux distribution from 2017 onwards, with no race condition.
- Page-cache corruption leaves no on-disk trace, which neutralises the file-integrity monitoring most organisations rely on.
- Kubernetes Pod Security Standards and
RuntimeDefaultseccomp do not block the underlying syscall. Patch the kernel and add a seccomp profile. - The bug was found by an AI-assisted code analysis tool in roughly an hour. Expect the cadence of deep kernel disclosures to pick up.