CVE-2026-31431: Copy Fail Attack - 732 Bytes to Root on Linux

732 Bytes. No Root Password. No Race Condition. No Crash!!

On April 29, 2026, security research firm Theori published a write-up about a vulnerability they named Copy Fail. It came with a 732-byte Python exploit. No root password required. No race condition to win. No system crash to risk. No compiled binary to deploy. No dependencies to install. Just a short Python script using only the standard library, and within seconds: root!!!

The script works unmodified on Ubuntu, Amazon Linux, Red Hat Enterprise Linux, SUSE, Debian, Fedora, Arch Linux, every mainstream Linux distribution shipping a kernel built since 2017. That's not most Linux systems. That's essentially all of them.

Theori found the bug in under an hour, not through months of manual kernel reverse engineering, but through a single AI-assisted operator prompt against the Linux crypto subsystem. The vulnerability had been sitting in the kernel for nine years.

What Is CVE-2026-31431 (Copy Fail)?

Local privilege escalation (LPE) is a class of attack where someone who already has limited, unprivileged access to a system, say, a normal user account, a compromised container, or a CI/CD job etc. can elevate themselves to full administrator (root) access. Think of it like a hotel guest who finds a maintenance closet left unlocked and uses the master key inside to access every room in the building, including the owner's suite.

Copy Fail is precisely this class of vulnerability. An attacker who can run any code on an affected Linux system, a regular user, a malicious container workload, a compromised CI job, can exploit CVE-2026-31431 to become root in seconds. From root, they can read any file, modify any configuration, install any software, exfiltrate any data, and persist indefinitely.

What makes Copy Fail stand apart from prior Linux LPE vulnerabilities is what it doesn't require:

• No race condition (unlike Dirty Cow / CVE-2016-5195, which required winning a timing window and sometimes crashed systems)

• No kernel version fingerprinting (unlike Dirty Pipe / CVE-2022-0847, which was version-specific)

• No compiled exploit (the entire thing is a short Python script using os and socket)

• No per-distribution offsets or adjustments (the same script works on every affected distro and architecture)

It is deterministic. It is portable. It is silent because it never writes to disk. The exploit operates entirely in memory.

How the Copy Fail Vulnerability Works

In 2017, a performance optimization was committed to the Linux kernel for AEAD (Authenticated Encryption with Associated Data) operations. The optimization made the source and destination scatter-gather lists for in-place cryptographic operations share a combined memory structure.

This is where the bug lives. The optimization placed page cache pages (the kernel's in-memory copies of files on disk) directly into the writable destination portion of that combined scatterlist. Nothing in the API enforced that cryptographic algorithms must confine their writes to only the designated output region. The design assumed it. That assumption was silent, undocumented, and wrong.

authencesn is an AEAD wrapper algorithm used by IPsec for Extended Sequence Number support. IPsec uses 64-bit sequence numbers: the high 32-bit half (seqno_hi) is implicit and not present on the wire whereas the low half (seqno_lo) is transmitted. During decryption, authencesn needs to temporarily write seqno_hi somewhere and it writes it into the caller's destination buffer as a scratch pad.

Those 4 bytes land on a page cache page (the kernel's in-memory cached copy of a file on disk). The file on disk is unchanged. Filesystem integrity checks see nothing. But the next time the kernel runs code from that cached page, it runs the modified version.

The entire exploitation path uses only standard, unprivileged system calls: socket(), bind(), setsockopt(), splice(), recv(), execve(). No kernel exploits. No memory corruption in the traditional sense. Just a logic flaw in how the kernel's cryptographic API handles an edge case that was never supposed to be reachable from userspace with page cache pages.

Who found it and how?

Theori's tool, Xint Code, surfaced the bug in approximately one hour of automated scan time against the Linux crypto subsystem with a single operator prompt: "This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls."

Theori disclosed publicly before all major distributions had shipped patched kernels, a deliberate decision that accelerated vendor action but also opened a window for threat actors. Copy Fail is uniquely dangerous precisely because it strips away every technical hurdle that historically limited LPE exploitation in production environments.

Copy Fail CVE

SOC Incident Response Workflow

• Assess exposure immediately: Run uname -r across all Linux hosts and compare against your distributions' minimum patched kernel version.

• Apply the algif_aead mitigation for unpatched systems.

• Deploy patched kernels and reboot.

• Hunt in audit logs for AF_ALG socket creation events by non-root UIDs

Copy Fail is a logic bug that was introduced by a performance optimization nine years ago, only discoverable by someone looking in exactly the right place in the kernel's cryptographic subsystem.

The security community has normalized treating kernel LPEs as rare, hard-to-find, and hard-to-exploit events that warrant a measured response. Dirty Cow took years to weaponize into reliable tooling. Dirty Pipe required careful version matching. Copy Fail shipped with a working exploit at disclosure, and the entire payload fits in a text message.

The vulnerability itself will be patched, kernel distributions will ship fixes, and the immediate crisis will pass. What won't pass is the underlying shift it represents: that the cost of finding kernel-grade vulnerabilities which is measured in researcher-hours, specialized expertise, and expensive tooling, is collapsing.

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don't forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let's keep the conversation going and make cybersecurity a community effort!

-AJ