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/suor 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 familyin logs outside boot sequences - Unusual AF_ALG socket creation from unexpected processes
- Malformed
auth.logentries with missing usernames insurecords - 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:
- Universal applicability: Every Linux system built in the last 9 years
- Zero complexity: 732-byte Python script, no special conditions
- Container impact: One vulnerable kernel affects all containers on the node
- 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."
Want to see how SmartEx² Enterprise provides real-time exploit & vulnerability intelligence for CVE-2026-31431 and helps you launch focused remediation campaigns? Request a short demo, and we'll walk you through it 👇
VR-1 | Property |
|---|---|
Model type | Post-trained cyber reasoning model |
Primary specialization | Multi-domain enterprise attack-chain discovery |
Starting condition | A scoped foothold and a concrete objective |
Operating surfaces | Cloud, identity, runtime, code, CI/CD, SaaS, and organizational context |
Success signal | Execution-verified completion of the objective |
Primary evaluation | IntrusionBench |
Preliminary result (preview) | More than 2× black-box pass@3 over the strongest evaluated frontier baseline |
Trajectory budget | Two-hour wall-clock limit per trajectory, or 250 agent turns (whichever comes first) |
