Copy Fail CVE-2026-31431: Linux Root Exploit Explained

A 732-byte Python script can give any unprivileged user full root access on virtually every major Linux distribution shipped since 2017. That's the reality of CVE-2026-31431, nicknamed "Copy Fail" — a straight-line logic flaw in the Linux kernel's crypto subsystem with no race conditions, no retries, and a public PoC already in the wild.

In this post, you'll learn exactly what triggered the bug, how the exploit chains AF_ALG sockets and splice() to poison the page cache, why your containers don't protect you, and what you need to do right now to patch or mitigate before threat actors move beyond proof-of-concept testing.

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

Copy Fail is a local privilege escalation (LPE) vulnerability in the Linux kernel. It lets any unprivileged local user write to the kernel's page cache — the in-memory representation of files — and corrupt a setuid binary to get a root shell. No special permissions required. No timing tricks. It just works.

The affected component is algif_aead, a kernel module that exposes hardware-accelerated AEAD cryptographic operations to userspace via AF_ALG sockets. The bug itself is a logic flaw, not a memory corruption issue in the traditional sense. A 2017 optimization switched AEAD operations to in-place processing — and that single design decision quietly broke a boundary that should never be crossable from userspace.

The numbers tell the story fast:

CVSS score: 7.8 (HIGH)
Disclosed: April 29, 2026
Affected kernels: 4.14 through current LTS lines (everything since mid-2017)
Exploit size: 732 bytes of Python, standard library only
Affected distros: Ubuntu, RHEL, SUSE, Amazon Linux, Debian, and more
CISA KEV listed: Yes

If you run Linux anywhere — on-prem, cloud, or Kubernetes — assume you're affected until you've checked your kernel version.

The Root Cause: A Logic Flaw in the Linux Crypto API

The Linux kernel lets userspace programs access hardware crypto acceleration through AF_ALG sockets. You open a socket, feed it data, and the kernel runs the cipher. Normal, useful, widely used.

In 2017, a performance optimization landed in the algif_aead module (commit 72548b093ee3). It switched AEAD decryption from separate source/destination buffers to in-place processing — req->src = req->dst. Faster, but it created a silent assumption: every AEAD algorithm must confine its writes to the intended output region. Nothing in the API enforced this. Nothing documented it.

One algorithm broke that assumption: authencesn, used by IPsec for Extended Sequence Number support. During decryption, it writes 4 bytes of scratch data at assoclen + cryptlen — just past the intended output boundary. Normally harmless. But when you feed page cache pages into the operation via splice(), that 4-byte write lands directly inside a file's cached data in memory.

Here's the boundary violation in plain terms:

The kernel never validated page provenance in the scatterlist. That's the entire bug.

How the Exploit Actually Works (Step by Step)

The full exploit is 732 bytes of pure Python — no compiled payloads, no third-party libraries, just standard os and socket modules. Here's the attack flow:

Step 1 — Open an AF_ALG socket and configure it:

This loads the exact AEAD algorithm that has the broken scratch write.

Step 2 — Splice a setuid binary into the socket: Using os.splice(), the exploit feeds /usr/bin/sudo (or any setuid binary) directly into the crypto socket. The kernel maps those page cache pages into the operation's scatterlist.

Step 3 — Trigger the decryption: The authencesn algorithm runs, writes its 4-byte scratch value past the output boundary, and that write lands in the page cache of /usr/bin/sudo — corrupting it in memory without touching the file on disk.

Step 4 — Execute the corrupted binary: The modified in-memory version runs as root. Shell acquired.

The whole sequence is deterministic. No retries, no race conditions, no kernel crash. It either works first try or the system isn't vulnerable.

Copy Fail vs. Dirty Cow and Dirty Pipe

Linux has seen serious LPE vulnerabilities before. Copy Fail belongs in that conversation — but it's worse in the ways that matter most to defenders.

Dirty Cow (CVE-2016-5195) exploited a race condition in the kernel's copy-on-write memory path. It worked, but it was unreliable — you had to win a timing race, often needed multiple attempts, and could crash the system trying. Skilled defenders had a real window to detect repeated failed attempts.

Dirty Pipe (CVE-2022-0847) was cleaner but narrow. It required precise pipe buffer manipulation and only worked on kernels 5.8 and above. Older LTS systems were safe. Patching a targeted version range is manageable.

Copy Fail has neither limitation. Here's the direct comparison:

One script. No modification. Runs identically on Ubuntu, RHEL, SUSE, and Amazon Linux. That portability is what makes Copy Fail genuinely unprecedented.

Real-World Impact: Cloud, Containers, and Kubernetes

If your threat model assumes containers are a security boundary, Copy Fail breaks that assumption completely. Containers share the host kernel. A compromised container that can execute code as a local unprivileged user can run this exploit against the host kernel directly — namespace isolation doesn't factor in.

The highest-risk environments right now:

Kubernetes nodes running untrusted or third-party workloads
CI/CD runners where contributor-triggered jobs execute arbitrary code
Multi-tenant cloud hosts where multiple customers share one kernel
SSH-accessible dev servers where multiple engineers have shell access

The attack chain in practice looks like this:

web app RCE → unprivileged shell → Copy Fail → root on host

or

malicious CI job → runner shell → Copy Fail → root on Kubernetes node

From root on a Kubernetes node, an attacker can read secrets from other pods, access the kubelet API, and potentially move laterally across the cluster. One unprivileged foothold becomes a full cluster compromise.

Microsoft's Defender team estimates millions of Kubernetes clusters are running vulnerable kernels. CISA added CVE-2026-31431 to the KEV catalog, meaning federal agencies must patch on a mandatory deadline. For everyone else, treat it with the same urgency.

How to Fix and Mitigate CVE-2026-31431

Step 1 — Check if you're vulnerable:

uname -r

# Vulnerable: 4.14 through 6.18.21 and 6.19.x before 6.19.12

Compare your output against your distro's patched version in the table below.

Step 2 — Apply vendor patches (preferred fix):

Step 3 — Interim mitigation (if you can't patch immediately):

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

sudo rmmod algif_aead 2>/dev/null || true

This blocks the vulnerable module. It does not affect OpenSSL, GnuTLS, SSH, LUKS, or IPsec.

Critical RHEL/CloudLinux warning: On RHEL-family systems, algif_aead is built directly into the kernel CONFIG_CRYPTO_USER_API_AEAD=y. The modprobe.d workaround silently does nothing. Use the grubby bootloader method instead or apply the kernel patch directly.

Reboot after any mitigation to guarantee the module is inactive.

Detecting Exploitation Attempts

The exploit relies entirely on standard syscalls, so there's no exotic kernel module to catch. Detection comes down to spotting the specific syscall sequence that the attack requires.

What to watch for:

An unprivileged process opening an AF_ALG socket with type aead
splice() calls feeding a setuid binary into that socket
authencesn(hmac(sha256),cbc(aes)) appearing in AF_ALG bind parameters
A non-root process spawning a root shell immediately after crypto socket activity

Check active AF_ALG socket usage right now:

lsof | grep AF_ALG

# Any output here warrants immediate investigation

Auditd rule to catch the exploit pattern:

-a always,exit -F arch=b64 -S socket -F a0=38 -k af_alg_socket

# a0=38 is AF_ALG's address family number

Add this to /etc/audit/rules.d/copy-fail.rules and restart auditd.

If you're running Falco or Sysdig Secure, a detection rule for "AF_ALG Page Cache Poisoning Leading to Privilege Escalation" is already available — deploy it without waiting for a full policy review.

For Kubernetes, flag any pod where a non-root UID spawns a root process. That transition should never happen legitimately.

The Bigger Lesson: AI Found This in One Hour

Copy Fail wasn't found by years of manual kernel auditing. Theori's automated system, Xint Code, surfaced it in roughly one hour with a single operator prompt:

"This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls."

No harness. No pre-written test cases. One prompt, one hour, one critical kernel bug that had sat undetected for nine years.

That changes the economics of vulnerability research permanently. The old assumption — that kernel-grade bugs are expensive to find, so the supply is naturally limited — is no longer valid. If offensive tooling can find bugs this fast, the gap between disclosure and widespread exploitation is shrinking.

What this means for your security posture, practically:

Patch cycles built around "low probability of exploitation" need revisiting
Container-only isolation is not a sufficient threat model for shared kernels
You need adversarial testing in your pipeline — not just static analysis
A monitored VDP or bug bounty intake isn't optional anymore

The uncomfortable truth: if Theori found this in an hour, others are running similar tools right now against codebases you own. The question isn't whether AI-assisted vulnerability discovery is coming — it's already here.

Conclusion

Three things to walk away with: Copy Fail is a nine-year-old logic flaw that gives any local user root on essentially every major Linux distro, a 732-byte script already exploits it reliably, and your containers won't save you if the host kernel is unpatched.

Do this right now: run uname -r, cross-reference your kernel version against your distro's patch table, and either update or blacklist algif_aead before you close this tab.

Curious how attackers typically get that first unprivileged foothold before chaining an LPE like this? Read our breakdown of the most common initial access techniques in Linux environments.

Tags: CVE-2026-31431, Linux kernel privilege escalation, page cache poisoning, AF_ALG socket vulnerability, Linux security, copy fail CVE