Copy Fail: Nine-Year-Old Linux Kernel Flaw Gives Any User Root in 732 Bytes

A nine-year-old logic flaw hiding in the Linux kernel's cryptographic subsystem has surfaced as one of the most impactful privilege escalation vulnerabilities in recent memory. CVE-2026-31431, nicknamed Copy Fail, lets any unprivileged local user gain full root access on virtually every major Linux distribution shipped since 2017. The exploit is a 732-byte Python script. It uses only standard library modules. It works unmodified across every tested distribution and architecture. Active exploitation has already begun.

This is not a theoretical edge case. It is already on CISA's Known Exploited Vulnerabilities catalogue, with a patch deadline of 15 May 2026 for US federal agencies. If your organisation runs Linux on-premises, in cloud infrastructure, or as container workloads in Kubernetes, you need to understand this vulnerability and act on it today.

Background: What Is Copy Fail?

Copy Fail was publicly disclosed on 29 April 2026 by researcher Taeyang Lee at Theori's Xint Code research team. The vulnerability has been assigned CVE-2026-31431 and carries a CVSS score of 7.8 (High).

The name is a play on the classic "Copy on Write" kernel mechanism, one of Linux's core memory efficiency features. The irony is precise: Copy Fail exploits the exact point at which the kernel skips making a copy it should have made, turning a performance optimisation into a root escalation primitive.

Unlike high-profile Linux privilege escalation bugs of the past, such as Dirty Cow (CVE-2016-5195), Copy Fail requires no race condition. There are no timing windows to win, no kernel-version-specific memory offsets to calculate, no compiled C payload to prepare. The same Python script, unmodified, achieves root on Ubuntu 24.04 LTS, Amazon Linux 2023, Red Hat Enterprise Linux 10.1, SUSE 16, Debian, Fedora, Arch Linux, and every other tested distribution running a kernel built after 2017.

The Technical Root Cause

Understanding Copy Fail requires examining three independent kernel changes made over a six-year period, none of which was dangerous in isolation.

The 2017 performance optimisation that started it all

In August 2017, a performance improvement was committed to algif_aead.c the kernel module that exposes the AEAD (Authenticated Encryption with Associated Data) cryptographic interface to userspace via the AF_ALG socket family. The change switched AEAD operations from copying data between separate input and output buffers to running "in-place": the same memory region serves as both input and output during encryption and decryption.

This is a legitimate optimisation. In-place operations avoid redundant memory allocation and copying, which is important for high-throughput cryptographic workloads. The problem is what it does to memory ownership.

The splice() interaction: page cache meets crypto

Linux's splice() system call allows data to be moved between file descriptors without copying it through userspace. When a file is spliced into an AF_ALG socket, the kernel does something efficient: rather than copying the file's contents, it passes references directly to the file's page cache pages; the in-memory representation of the file that the kernel uses for all file I/O.

Before the 2017 in-place optimisation, this was safe. The crypto subsystem would read from those page cache pages and write to a separate output buffer. The page cache itself was never modified.

After the 2017 change, the page cache pages fed into the AEAD subsystem now serve as both input and output. The kernel holds references to file-backed memory inside a buffer it is actively writing into.

The authencesn 4-byte overwrite

The third component is the authencesn cryptographic template, used by the IPsec protocol suite for authenticated network traffic. During decryption, authencesn writes four bytes past its legitimate output boundary as scratch space. On its own, this is a minor logic error with no exploitable consequence. In normal use, that scratch space falls within allocated memory and causes no visible effect.

Combined with the in-place page cache exposure above, those four bytes land inside the kernel's cached copy of a file the attacker chose to target. And because the attacker controls the splice input, they also control which file, which offset within that file, and which four-byte value to write.

The exploit primitive

The result is a deterministic, controlled 4-byte write into the kernel's page cache of any file readable by the attacker.

On any standard Linux system, the attacker chooses a setuid binary: sudo, passwd, su, or similar, and uses this primitive to patch a branch instruction inside it. The modified binary, when executed, drops directly to a root shell. Because the write targets the page cache (not the file on disk), the filesystem checksum remains clean and file integrity monitoring tools see no change on disk.

Theori's proof-of-concept achieves this in 732 bytes of pure Python, importing nothing beyond the standard library. It has no architecture-specific code paths. It runs identically on x86-64 and ARM64. Every distribution tested produced a root shell.

The AI-Assisted Discovery

Copy Fail is notable not just for its severity but for how it was found. Researcher Taeyang Lee was studying the interaction between the Linux crypto subsystem and page-cache-backed data,  a narrow, technically deep area of the kernel. He used Xint Code, an AI-powered code scanning tool developed by Theori, to scale his hypothesis across the entire crypto subsystem rather than examining individual files manually.

The AI identified the chain of interactions across algif_aead.c, authencesn, and the splice() path, connections that span multiple subsystems and years of separate commits, each individually benign. A conventional audit focused on any single component would almost certainly have missed it.

This matters beyond Copy Fail itself. AI-assisted security research is accelerating the discovery of complex, cross-component vulnerabilities, the class of bugs most likely to escape conventional review. Defenders should expect this class of disclosure to become more common.

Scope and Impact

Which systems are affected

Any Linux host running a kernel built from 2017 onward is affected until a patched kernel is applied. This covers essentially every production Linux system in use today. The confirmed affected distributions include Ubuntu (all supported LTS releases), Red Hat Enterprise Linux (8 and above), Amazon Linux 2 and 2023, SUSE Linux Enterprise Server 15 and SUSE 16, Debian (stable and testing), Fedora, and Arch Linux.

Local privilege escalation: why "local" matters less than it sounds

"Local" privilege escalation means the attacker must already have a foothold on the host, an existing shell, a compromised application process, or container access. This is often presented as a mitigating factor. It should not be here.

In modern infrastructure, local access is not hard to achieve. A single exploited web application, a compromised CI/CD runner, a misconfigured container image, or a phishing-delivered payload on a developer machine all provide the local access Copy Fail needs. Once that foothold exists, root is seconds away. The gap between "compromised user process" and "full system compromise" has effectively been closed on unpatched systems.

The Kubernetes dimension

The impact extends well beyond individual hosts. Theori has announced a second part of the Copy Fail disclosure, a Kubernetes container escape built on the same primitive, is forthcoming.

The reason this works is fundamental to how the Linux kernel manages memory: the page cache is shared across all processes on the same physical host, including across container boundaries. A compromised pod running on a Kubernetes node can use the Copy Fail primitive to corrupt a setuid binary in the page cache of the host kernel. When that binary is executed, whether on the host or in any other container on the same node, the attacker's injected code runs.

Critically, this is a page-cache-only write. Nothing changes on the filesystem. Existing container filesystem integrity checks will not detect it.

This means a single compromised pod can pivot to the Kubernetes node and then affect all other workloads running on it, crossing tenant boundaries in shared clusters.

Current Exploitation Status

Active exploitation of Copy Fail is underway. CISA added CVE-2026-31431 to its Known Exploited Vulnerabilities catalogue following confirmation of in-the-wild exploitation. Microsoft's Defender Security Research Team observed preliminary exploitation activity beginning shortly after public disclosure and noted that threat actor activity was expected to increase substantially in the days following.

The low barrier to exploitation, a 732-byte Python script requiring no compilation, no specialised tooling, and no target-specific configuration, means that exploitation will scale rapidly once threat actors incorporate the technique into existing attack chains. Ransomware operators, post-compromise lateral movement toolkits, and opportunistic cryptomining payloads are the most likely immediate adoption vectors.

What to Do Right Now

1. Patch immediately

Patches are available in Linux kernel versions 6.18.22, 6.19.12, and 7.0. All major distributions have released or are actively releasing kernel updates. Apply them now, do not wait for your next maintenance window.

The fix reverts the 2017 in-place AEAD optimisation entirely, restoring the copy-based behaviour that kept page cache references safe. Performance impact on the vast majority of workloads will be immeasurable.

After applying the patch, a reboot is required for the new kernel to take effect. A kernel update without a reboot leaves the vulnerable kernel running.

2. Apply the immediate mitigation if you cannot patch right now

If patching and rebooting cannot happen immediately, blacklist the algif_aead kernel module:

 echo "install algif_aead /bin/true" >> /etc/modprobe.d/disable-algif-aead.conf
modprobe -r algif_aead

Theori confirmed this mitigation eliminates the attack surface and has no measurable impact on the vast majority of systems. The algif_aead module exposes kernel AEAD operations to userspace via AF_ALG sockets, a feature used almost exclusively by specialised cryptographic benchmarking tools. Standard TLS, IPsec, and disk encryption operations are unaffected.

Alternatively, you can block AF_ALG socket creation entirely using a seccomp policy or an AppArmor/SELinux rule restricting access to socket(AF_ALG, ...). This provides equivalent protection if you prefer not to remove the module.

3. Check for indicators of compromise

Because Copy Fail writes to the page cache rather than the filesystem, traditional file integrity monitoring will not catch exploitation after the fact, at least not at the file level. Review your endpoint and kernel telemetry for:

• Unexpected processes running as root that were initiated by non-root users
• Sudden privilege changes in audit logs (sudo or su events not matching expected patterns)
• AF_ALG socket creation followed shortly by splice() calls, this sequence is the exploit's fingerprint
• Unexpected kernel module loads or modprobe invocations
• Kubernetes node compromise indicators: pod-to-node privilege escalation events, unexpected host namespace access from pod processes

4. Harden your Kubernetes posture

Until the Kubernetes container escape PoC is disclosed, treat all Kubernetes nodes as potentially exploitable by any compromised pod on the same node. Immediate steps:

• Apply kernel patches to all cluster nodes, both control plane and worker nodes
• Review pod security policies (or Pod Security Admission controls) to ensure pods run with the minimum required privileges
• Confirm that your runtime (containerd, CRI-O) and node-level seccomp profiles are blocking AF_ALG socket creation by default for untrusted workloads
• Enable Kubernetes audit logging for privilege escalation events

5. Review your Linux attack surface

Copy Fail is a reminder that "local access" is a meaningless qualifier in environments where applications, containers, and CI/CD pipelines routinely run code with authenticated system access. Now is a good time to:

• Audit which users and service accounts have shell access to Linux systems
• Review application sandboxing and containerisation to ensure compromised application processes cannot trivially reach the kernel
• Verify that your vulnerability management programme surfaces kernel CVEs promptly and has a defined SLA for critical and high-severity patches

The Broader Signal

Copy Fail is not an isolated event. It is a data point in a pattern.

Complex, cross-component vulnerabilities, the kind that emerge from the interaction of individually reasonable code changes made years apart, are extremely hard for conventional security review to catch. The Linux kernel's cryptographic subsystem changes from 2011 to 2017 were each reviewed and accepted on their merits. Nobody was wrong. The dangerous combination only became visible when someone looked across all three changes simultaneously, with a model capable of holding the full context in scope at once.

AI-assisted vulnerability research changes that calculus. It allows a single researcher to systematically explore interaction surfaces across an entire subsystem in the time it would previously take to review a handful of files. Theori's Xint Code found what years of conventional audit missed. Other research groups, including those working for nation-state intelligence services and well-resourced criminal organisations, have access to equivalent capability.

The implication is direct: defenders should anticipate an accelerating cadence of complex, high-impact kernel and platform vulnerabilities. Patch cadence, kernel hardening defaults, and runtime isolation need to be treated as first-order security controls, not background maintenance tasks.

Summary

CVE-2026-31431 (Copy Fail) is a nine-year-old logic flaw in the Linux kernel's cryptographic subsystem that allows any local user to gain root access on virtually every major Linux distribution in 732 bytes of Python. It requires no race conditions, no compiled payloads, and no target-specific configuration. Active exploitation is confirmed. A Kubernetes container escape variant is pending disclosure.

If you have unpatched Linux systems, the priority is straightforward:

1. Apply kernel patches immediately and reboot
2. Blacklist algif_aead as an interim mitigation if patching cannot happen right now
3. Review audit logs for signs of exploitation
4. Tighten Kubernetes pod isolation on all cluster nodes

SALTT Technologies' Technical Testing & Assurance and Security Architecture & Engineering teams are available to assist organisations in assessing their exposure, validating patch deployment, and hardening Linux and Kubernetes environments against this and related privilege escalation techniques. Contact us at saltt.tech.

References: Theori / Xint Code — Copy Fail disclosure · Microsoft Security Blog — CVE-2026-31431 · Ubuntu Security Notice · CERT-EU Advisory 2026-005 · Qualys ThreatPROTECT · Wiz Blog · CISA KEV — CVE-2026-31431