Copy Fail (CVE-2026-31431): The 732-Byte Script That Roots Every Major Linux Distribution
A single 732-byte Python script. No race conditions. No compiled payloads. No kernel-specific offsets. No retries. Just run it, and you’re root — on Ubuntu, Red Hat, SUSE, Amazon Linux, and virtually every other Linux distribution shipped since 2017.
That’s the reality of CVE-2026-31431, nicknamed Copy Fail: a logic flaw buried in the Linux kernel’s cryptographic subsystem that grants any unprivileged local user full administrator access to the system. It was discovered by offensive security firm Theori using AI-assisted vulnerability research tools, disclosed publicly on April 29, 2026, and has since been added to CISA’s Known Exploited Vulnerabilities catalogue.
This one deserves your immediate attention.
What Is Copy Fail?
Copy Fail is a local privilege escalation (LPE) vulnerability in the Linux kernel’s algif_aead module — part of the kernel’s AF_ALG (Address Family Algorithm) interface, which provides userspace programs with access to hardware-accelerated cryptographic functions.
The flaw carries a CVSS score of 7.8 (High) and affects all Linux kernels since 2017 across essentially every major distribution: Ubuntu, Red Hat Enterprise Linux, SUSE, Amazon Linux, and Debian, among others.
Unlike famous predecessors such as Dirty COW (CVE-2016-5195) — which required winning a timing race — or Dirty Pipe (CVE-2022-0847) — which was version-specific and required precision pipe buffer manipulation — Copy Fail is a straight-line logic flaw. It triggers deterministically, every time, without crashes or retries.
How Does It Work?
The root cause is a design assumption in the kernel’s AEAD (Authenticated Encryption with Associated Data) cryptographic API that one particular algorithm quietly violates.
Here’s the breakdown:
The normal design: When the kernel performs in-place cryptographic operations via AF_ALG, it places page cache pages in a scatterlist (a memory descriptor used by the crypto subsystem). The design assumes every AEAD algorithm will confine its writes to the intended destination region — but nothing in the API actually enforces this, and it is never documented as a requirement.
The broken algorithm: authencesn is an AEAD wrapper used by IPsec for Extended Sequence Number (ESN) support. Because IPsec’s 64-bit sequence numbers are split between a high half and a low half, authencesn writes back a scratch value — seqno_hi — to restore a byte it overwrote during processing. That scratch write lands outside the intended destination buffer, directly into the page cache of any readable file the attacker chooses.
The exploit chain: By combining AF_ALG with splice() (a system call that moves data between file descriptors without copying it), an unprivileged attacker can feed page cache pages of a privileged binary directly into the crypto subsystem. The authencesn scratch write then corrupts those pages in memory — patching the setuid binary’s behaviour without ever touching the file on disk. The attacker can then execute the modified binary and obtain root.
The entire exploit is a short Python script using only standard library modules. It requires Python 3.10+ for os.splice. There are no compiled payloads and no external dependencies.
Why Is This Particularly Dangerous?
Reliability. This is not a probabilistic exploit. It runs once and works. There are no timing windows, no kernel version offsets to calculate, no per-distribution adjustments. The same script works identically across all affected distributions and architectures.
Portability. A C reimplementation has already been published that compiles to virtually any CPU architecture supported by the Linux kernel — x86_64, ARM, RISC-V, MIPS, PowerPC, and more.
Invisibility. The exploit modifies the in-memory page cache of a setuid binary, not the binary on disk. Traditional file integrity monitoring tools watching the filesystem will see nothing. The patch evaporates from memory when the system is rebooted.
Cloud and container scale. While Copy Fail requires local code execution and is not remotely exploitable in isolation, this is rarely an obstacle in practice. SSH access, a malicious CI/CD job, a compromised container, or any other form of unprivileged code execution on a vulnerable host is sufficient. Microsoft Defender estimates the vulnerability impacts a significant proportion of cloud Linux workloads and millions of Kubernetes clusters.
Container escape. In multi-tenant container environments running on a shared host kernel, Copy Fail can facilitate container escape — turning what should be an isolated container compromise into full host compromise.
How Was It Found?
This is where the story takes an additional dimension. Copy Fail was discovered by researchers at offensive security firm Theori using their AI-assisted vulnerability discovery platform, Xint Code.
According to their writeup, the vulnerability was surfaced after approximately one hour of automated scanning against the Linux kernel’s crypto subsystem, triggered by a single operator prompt. No custom harnesses were written. No manual code review guided the initial discovery.
Bugcrowd’s analysis of the disclosure called this a signal that the cost of finding deep kernel logic flaws may have dropped by an order of magnitude. The skill curve for using serious vulnerability discovery tooling is beginning to look a lot more like the skill curve for reading the output — meaning the supply of high-quality kernel vulnerabilities will not remain as bounded as defenders have historically assumed.
If your threat model prices kernel LPEs as rare events, that assumption needs revisiting now.
What Is Affected?
| Distribution | Affected? | Status (as of early May 2026) |
|---|---|---|
| Ubuntu (pre-26.04) | Yes | Patch released; mitigation via kmod available |
| Ubuntu 26.04 (Resolute) | No | Not affected |
| Red Hat Enterprise Linux | Yes | Patch in progress |
| Amazon Linux | Yes | Patch released |
| SUSE | Yes | Patch released |
| Debian | Yes | Patched downstream kernel released (May 2) |
| Arch Linux, Fedora | No | Shipping new enough upstream kernel |
| CloudLinux 7h/8/9/10 | Yes | KernelCare live patches available |
All Linux kernels shipped since 2017 and before the upstream fix commit (a664bf3d603d) are in scope.
A Critical Warning About the Common Mitigation for Copy Fail
Many sources — including CERT-EU and the original oss-security post — recommend blocking the algif_aead module by adding install algif_aead /bin/false to /etc/modprobe.d/ and running rmmod algif_aead.
This workaround does not work on RHEL-family distributions (Red Hat Enterprise Linux, AlmaLinux, CloudLinux, Rocky Linux, and others).
On these systems, algif_aead is compiled directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y). The modprobe.d rule cannot block a built-in module, and rmmod cannot remove it. The commands run without errors but leave the system fully vulnerable. Applying them creates a false sense of protection.
On RHEL-family distributions, the only effective remediation is a patched kernel or a KernelCare live patch.
What Should You Do Right Now?
Patch immediately — this is the only real fix.
Identify your kernel version and distribution, and apply the appropriate vendor-issued kernel update as a priority. Kubernetes nodes and CI/CD runners should be first in line, given the multi-tenant risk.
To check your current kernel version:
bash
uname -rInterim mitigation (Ubuntu/Debian and non-RHEL systems only):
bash
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aeadNote: This does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. Check lsof | grep AF_ALG to assess current usage.
For RHEL-family systems: Do not rely on the modprobe workaround. Apply patched kernel packages or deploy a KernelCare live patch.
For container and Kubernetes environments:
- Treat any container RCE as a potential host compromise
- Enforce rapid node recycling after any compromise indicator
- Consider adding hardware or VM isolation boundaries for sensitive multi-tenant workloads — namespace-based container isolation was never designed as a security boundary against kernel-level exploits
Check for indicators of compromise: Exploitation of this vulnerability does not leave traces on disk. Review authentication logs, privilege escalation events, and unexpected root process spawning for signs of post-exploitation activity.
Assess AF_ALG exposure:
bash
lsof | grep AF_ALGThis will show you which processes are currently using the AF_ALG socket family.
The Bigger Picture
Copy Fail sits in an uncomfortable category: it is not the kind of vulnerability that gets quietly fixed in a routine kernel update and forgotten. The combination of universal scope (every major Linux distro for nine years), a trivially portable public exploit, zero reliability barriers, and AI-assisted discovery methodology makes this a meaningful shift in the threat landscape.
The fact that a working proof of concept was produced by an AI tool in approximately one hour against a single subsystem should prompt organisations to reconsider how they budget vulnerability risk. If sophisticated research teams can dramatically accelerate kernel-grade vulnerability discovery with AI tooling, that same capability is eventually available to less sophisticated actors.
Patch your kernels. Harden your container isolation posture. Audit your CI/CD environments for untrusted code execution paths. And if your vulnerability management programme still treats Linux kernel LPEs as rare background noise — update that model.
Quick Reference
| Item | Detail |
|---|---|
| CVE | CVE-2026-31431 |
| Common Name | Copy Fail |
| CVSS Score | 7.8 (High) |
| Vulnerability Type | Local Privilege Escalation (LPE) |
| Affected Component | Linux kernel algif_aead / AF_ALG crypto API |
| Affected Kernels | All kernels since 2017 (pre-fix commit a664bf3d603d) |
| Affected Distributions | Ubuntu (pre-26.04), RHEL, SUSE, Amazon Linux, Debian, CloudLinux, others |
| Exploit Size | 732 bytes (Python); C port also available |
| Disclosed | April 29, 2026 |
| Discovered By | Theori / Xint Code (AI-assisted) |
| CISA KEV Added | Yes |
| Remote Exploitation | No (requires local code execution) |
| Container Escape | Yes (on shared-kernel multi-tenant environments) |
| Reliable? | Yes — deterministic, no race conditions |
Subscribe to our security bulletin to stay ahead of critical vulnerabilities like Copy Fail before they hit your environment.
