Copy Fail (CVE-2026-31431): Universal Linux privilege escalation requires immediate action

"An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root." - Source: Xint Security Research copy.fail

‍A nine-year-old optimization in the Linux kernel turned into a universal privilege escalation path. Public PoCs dropped immediately, major cloud providers are scrambling to patch, and CISA added it to the Known Exploited Vulnerabilities catalog on May 1st. If you run Linux anywhere (and you do), this is a "patch first, analyze later" situation.

Why this matters

Copy Fail is local privilege escalation with training wheels off: no race conditions, no kernel version guessing, just 732 bytes of Python that turns any unprivileged user into root in under 30 seconds.

This affects every major Linux distribution built since 2017: Ubuntu, RHEL, Amazon Linux, Debian, SUSE—basically your entire production infrastructure. And because containers share the host kernel, one vulnerable kernel means every container on that node is at risk.

The real danger? This isn't a standalone remote exploit, but it's the perfect second-stage payload. An attacker compromises a web app running in a container, exploits a CI/CD pipeline, or gains SSH access—Copy Fail turns any of these footholds into full system control. In multi-tenant environments, that's game over.

Timeline: Zero to exploited in 24 hours

The escalation was brutal:
‍
- April 22: NVD publishes CVE-2026-31431
- April 29: Xint releases technical writeup and working PoC
- April 29: First container escape PoCs appear for Kubernetes
- April 30: Major security vendors (Microsoft, Wiz, Sysdig) publish advisories
- May 1: CISA adds to KEV catalog, confirming in-the-wild exploitation
- May 4: Most distributions still don't have patches available

Source: Hackuity - SmartEx² Enterprise module

What is Copy Fail, exactly?

Copy Fail (CVE-2026-31431) is a logic flaw in the kernel's AEAD crypto implementation (algif_aead) that allows unprivileged writes to the page cache (CWE-669).

The technical breakdown:
‍
- A 2017 optimization (commit 72548b093ee3) made AEAD operations work in-place, reusing source memory as destination
- By chaining AF_ALG sockets with splice(), attackers can write exactly 4 controlled bytes into any readable file's page cache
- Target the in-memory version of /usr/bin/su or another setuid binary, inject shellcode, execute it, gain root
- 🩹 Fixed upstream: Linux 7.0, 6.19.12, 6.18.22 (commit a664bf3d603d)

Affected versions:
‍
- Linux kernel 4.14 through 7.0-rc
- All 6.18.x prior to 6.18.22
- All 6.19.x prior to 6.19.12
- Vulnerable backports: 6.12.x, 6.6.x, 5.15.x, 5.10.x

Verified vulnerable distributions:
- Ubuntu 24.04 LTS (kernel 6.17.0-1007-aws)
- Amazon Linux 2023 (kernel 6.18.8-9.213.amzn2023)
- RHEL 10.1 (kernel 6.12.0-124.45.1.el10_1)
- SUSE 16 (kernel 6.12.0-160000.9-default)
- Plus Debian, Fedora, Arch, Rocky, AlmaLinux, Oracle Linux

ℹ️ Note: As of May 4, 2026, most distributions haven't released patched kernels yet. Upstream fixes exist, but backports are still rolling out.

What to do right now: Mitigate immediately

Priority 1 - Highest risk systems (today):
‍Start with multi-tenant environments, Kubernetes clusters, CI/CD runners, and anything executing untrusted code. These are where attackers already have footholds.

‍If patches are available for your distribution:
- Upgrade to Linux 7.0, 6.19.12, 6.18.22, or your distribution's backported fix
- Reboot to load the new kernel (no shortcuts here)

If patches aren't available yet (most of you):

‍Disable the vulnerable module immediately:

✅ This won't break: LUKS/dm-crypt, kTLS, IPsec, SSH, TLS, OpenSSL, GnuTLS

⚠️ This may affect: Applications explicitly using afalg engine or direct AEAD socket bindings (rare)

For containerized environments:
‍
Block AF_ALG socket creation via seccomp policies:

This blocks the exploit's first step, even on unpatched kernels.

‍Priority 2 - Detection (this week):
‍Monitor for exploitation indicators:
‍
- NET: Registered PF_ALG protocol family in logs outside boot sequences
- Unusual AF_ALG socket creation from unexpected processes
- Malformed auth.log entries with missing usernames in su records
- Suspicious POST activity to server endpoints followed by reverse shells

⚠️ These indicators will evolve. Sophisticated attackers will modify their approach, but opportunistic exploitation follows known patterns.

‍Priority 3 - If you were vulnerable during April 29-May 4:
‍Assume compromise and validate:

Rotate secrets on affected systems (database creds, API keys, cloud tokens)Review logs for privilege escalations and unexpected root shellsCheck for unauthorized user accounts or modified sudoersValidate integrity of setuid binaries

Why this matters for exposure management

Copy Fail demonstrates why static vulnerability counts miss the point. This CVE has a "High" CVSS score yet it's more dangerous than many 9.x vulnerabilities because:
‍
1. Universal applicability: Every Linux system built in the last 9 years
2. Zero complexity: 732-byte Python script, no special conditions
3. Container impact: One vulnerable kernel affects all containers on the node
4. Perfect second stage: Turns any initial access into full compromise

Traditional VM programs would prioritize this based on CVSS 7.1 somewhere below your "Critical" 9.x backlog. But vulnerability & exploit intelligence tells a different story: public exploits exist, it's in CISA KEV, and the technical barrier is essentially zero.

The organizations that handle this well aren't the ones with unlimited patch resources. They're the ones with intelligence that tells them: "This one can't wait until next maintenance window."