CISA added the Copy Fail Linux vulnerability, CVE-2026-31431, to its Known Exploited Vulnerabilities catalog on May 1, 2026. The flaw has been sitting in mainline Linux kernels since 2017, and a 732-byte Python script reliably takes any unprivileged local user from a normal shell to root on virtually every major distribution. If that doesn't make you check your cloud fleet, the federal patch deadline of May 15, 2026 probably should.
What Copy Fail actually is
The vulnerability is a logic bug in the Linux kernel's algif_aead module, the Authenticated Encryption with Associated Data (AEAD) socket interface that exposes the kernel's userspace crypto API (AF_ALG). The root cause is mainline commit 72548b093ee3 from 2017, which switched AEAD operations to in-place processing as a performance optimisation. That optimisation interacts badly with the authencesn template, letting an unprivileged local user trigger a deterministic four-byte write into the page cache of any readable file on the system.
That last sentence is the whole bug, and it deserves to land. There's no race, no heap grooming, no retry loop. The write is precise and reliable.
CVSS scores it 7.8 (High), which feels conservative once you read Microsoft's writeup. Microsoft Defender researchers call out that the flaw escalates cleanly across containers and shared multi-tenant systems, and that the public proof-of-concept worked on every distribution they tested.
How the exploit chain works
The technique chains two old friends. First, AF_ALG opens a crypto socket. Second, splice() moves data into the kernel without copying it through userland buffers, which is normally a performance win. The bug is in how algif_aead handles the in-place copy when the authencesn template is active. Mishandling the source buffer turns into a four-byte write at a controlled location in the kernel's page cache, and from there it's straightforward to patch the in-memory copy of any setuid binary the attacker can read.
The 732-byte PoC
The publicly available proof-of-concept fits in 732 bytes of Python. It opens the AEAD socket, uses splice to plant the payload, and rewrites the in-memory copy of a setuid binary. When any privileged process later executes that binary, it runs from the corrupted page cache copy. Root shell, no recovery needed. Xint's research walks the full chain on Ubuntu, Amazon Linux, RHEL, and SUSE.
A working exploit is on GitHub, and CISA cited public exploitation evidence when adding the CVE to KEV.
Why disk forensics misses it
This is the part that should worry incident responders. The modification only lives in the kernel's page cache. The file on disk is never touched. sha256sum returns the original hash. AIDE, Tripwire, and similar file-integrity tools tell you nothing's wrong. A reboot or page eviction restores normal behaviour, which makes the post-incident timeline ugly. If you're trying to prove a container was compromised, you need memory forensics. Disk inspection alone won't catch it.
Why CISA fast-tracked it to KEV
CISA usually adds vulnerabilities to KEV after observing in-the-wild exploitation against US federal interests. This one moved fast for three reasons.
The bug is deterministic. No timing window, no heap-spray uncertainty. If you can run code on the box, you can root the box.
The PoC is trivially weaponisable. At 732 bytes it fits inside the smallest of foothold payloads, and there's no setup beyond running it.
The blast radius covers cloud. Microsoft confirmed the flaw affects WSL2 because WSL2 runs an actual Linux kernel, and the Federal Civilian Executive Branch patch deadline of May 15, 2026 is aggressive even by CISA's recent standards.
Real-world blast radius
The vulnerable code shipped in mainline 4.14 and persisted through 7.0-rc. Patched versions are 6.18.22, 6.19.12, and 7.0. That means almost every long-running Linux fleet is in scope: Ubuntu (including 24.04 LTS), Amazon Linux 2023, RHEL 10.1, SUSE 16, Debian, Fedora, Arch, and the managed Kubernetes distributions sitting on top of them. Canonical's advisory and CERT-EU's writeup both cover the patched kernel versions per distribution.
The container angle deserves a separate beat. A non-root user inside a container who can reach the host kernel can use this to break out, because they're sharing that kernel. For BFSI and healthcare clients running multi-tenant Kubernetes, this is not a "patch when convenient" bug. It's an active container escape primitive with a confirmed public exploit. We've been replaying the technique against client environments this week, and the success rate is uncomfortable.
WSL2 ships a real Linux kernel, so Windows workstations running WSL2 are equally exposed. Microsoft is pushing an updated WSL2 kernel through May 2026 Patch Tuesday.
Detection and short-term mitigation
If you can't patch immediately, two stopgaps help. First, block unprivileged access to AF_ALG sockets through seccomp profiles or by setting kernel.unprivileged_userns_clone=0 where your workloads tolerate it. Second, harden setuid binary exposure: trim the list, audit which ones live on shared infrastructure, and consider running them under capabilities instead.
Detection is harder. Page-cache tampering doesn't leave file-system artifacts, so look at eBPF telemetry on setsockopt and sendmsg calls into the AF_ALG family. Sysdig and Falco published detection rules within 48 hours of disclosure, and they're worth deploying if your container runtime supports them. A practical eBPF filter to flag the suspect socket family looks like this:
c
SEC("kprobe/sys_socket")
int trace_af_alg(struct pt_regs *ctx) {
int family = (int)PT_REGS_PARM1(ctx);
if (family == AF_ALG) {
u64 pid_tgid = bpf_get_current_pid_tgid();
bpf_printk("AF_ALG socket opened by pid %d", pid_tgid >> 32);
}
return 0;
}It won't stop exploitation on its own, but it gives you the telemetry to investigate after the fact.
What this means for your team
For most security teams, the prioritisation goes like this.
Patch the highest-blast-radius hosts first: Kubernetes nodes, build servers, jump boxes, anything multi-tenant. The reboot pain is worth it. If your fleet management tool supports live kernel patching (kpatch, kgraft, Ksplice), schedule a wave today. Some of the worst exposure isn't in modern Kubernetes, by the way. It's in long-running Linux VMs, especially older RHEL and Ubuntu LTS images that have skipped kernel updates because the application on top is fragile. Attackers will park there, because uptime is high and patch tolerance is low.
Treat any container environment without patched nodes as compromisable from inside out. Threat-model accordingly. The classic "the container is the security boundary" assumption gets weaker every year, and this CVE is a fresh reminder. The zero-trust thinking we wrote about previously maps directly here: assume the container plane is hostile and design segmentation that survives a single-host compromise.
Pull memory captures, not just disk images, when investigating suspected exploitation. Page-cache forensics from a live host or a memory dump is the only way to see this exploit in action. Bake that into your IR runbook now, before you need it.
If you operate cloud workloads at scale, fold AF_ALG-aware exploitation into your next cloud configuration review or network pentest. It's a useful chassis for testing whether your container escape detections actually work, and it's far more realistic than the old "I escaped a permissive docker run -v /:/host" demos. We at PentesterHub have been adapting our Kubernetes engagement playbook this week to include AF_ALG exploitation against staging clusters before clients ship the patch broadly.
The combination of a 2017 introduction date, a 732-byte exploit, and a page-cache primitive that disk forensics can't see makes this one of the most consequential kernel bugs of the decade. Patch, hunt, and assume the worst about anything you couldn't update before May 15. If you'd like a fresh pair of eyes on your cluster posture or a targeted assessment of your container escape detections, get in touch.
References and Sources
CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments. Microsoft Security Blog, May 1, 2026.
CISA Adds One Known Exploited Vulnerability to Catalog. CISA Alert, May 1, 2026.
CISA Adds Actively Exploited Linux Root Access Bug CVE-2026-31431 to KEV. The Hacker News, May 2026.
CVE-2026-31431 Detail. National Vulnerability Database.
Copy Fail (CVE-2026-31431): Linux Kernel Privilege Escalation FAQ. Tenable Research.
Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years. Unit 42, Palo Alto Networks.
Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. Xint Research.
Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability. Canonical / Ubuntu.
Nine-year-old Linux kernel flaw enables reliable local privilege escalation (CVE-2026-31431). Help Net Security, April 30, 2026.
CVE-2026-31431: "Copy Fail" Linux kernel flaw lets local users gain root in seconds. Sysdig Threat Research.
High Vulnerability in the Linux Kernel ("Copy Fail"). CERT-EU Advisory 2026-005.
CVE-2026-31431 Red Hat Security Advisory. Red Hat.
Share this post