A critical zero-day vulnerability disclosed on April 29, 2026 lets any unprivileged user gain full root access on virtually every Linux server built since 2017. No race condition. No special tools. No kernel version detection. Just a logic flaw that has been sitting in the kernel for nearly a decade.

Tracked as CVE-2026-31431 and dubbed Copy Fail, this vulnerability affects Ubuntu, RHEL, Amazon Linux, SUSE, and Debian — the distributions running the majority of the world's servers, containers, and cloud infrastructure. If your organization runs Linux anywhere, this one deserves your attention today, not next patch cycle.

What Is Copy Fail?

Copy Fail is a logic flaw in the Linux kernel's cryptographic API, specifically in the algif_aead.c component that handles AF_ALG sockets. The bug was introduced in 2017 as part of an optimization that reused the same scatterlist (the memory structure describing input and output buffers) for both reading and writing during AEAD encryption operations.

The problem: when a user feeds a file into the kernel's crypto subsystem via a splice operation, that file's pages land directly in the kernel page cache — shared memory the kernel uses to cache files on disk. Because of the scatterlist reuse bug, a decryption operation that fails partway through still writes four bytes of scratch data across the boundary, landing inside those cached file pages. The file on disk is untouched, but the in-memory version the kernel serves to any process asking for it has been silently altered.

The exploit targets setuid binaries like /usr/bin/su. Corrupt the right four bytes in the page cache, execute the binary, and the kernel loads your version of it — as root.

Why This One Is Different

Every few years a Linux local privilege escalation makes headlines. The comparison point everyone reaches for is Dirty Cow (2016) or Dirty Pipe (2022). Copy Fail is worse in one critical way: reliability.

Dirty Cow required winning a race condition — fast machines made it more reliable, but it was never guaranteed to work on the first try
Dirty Pipe was version-specific, limited to kernels 5.8 through 5.16, and patched quickly
Copy Fail is a straight-line logic flaw with no timing window. A working exploit runs identically on Ubuntu, Amazon Linux, RHEL, and SUSE without modification, recompilation, or version detection

There is one more detail that makes security teams nervous: the corrupted page is never marked dirty for disk writeback, so checksum-based integrity tools do not flag it. The attack leaves minimal forensic traces.

Who Is Actually at Risk

Copy Fail is a local privilege escalation, which means the attacker needs code execution on your system before they can exploit it. That is the one thing working in defenders' favor. But "local access" covers more ground than it used to:

Multi-tenant servers and shared hosting — any environment where multiple users or customers share a kernel is immediately at risk. One compromised tenant becomes root on the entire host
CI/CD runners and build systems — if your pipeline runs untrusted code (open source contributions, external PRs, third-party scripts), a malicious job can root the runner
Kubernetes nodes — the page cache is shared across the host. A container that can create AF_ALG sockets may be able to escalate to root on the node, turning a container escape into a cluster takeover
Any server where phishing works — a compromised employee account with shell access becomes full root in seconds. The attack chain is now: phishing email → stolen SSH credentials → Copy Fail → root → ransomware
Cloud VMs and managed Linux instances — if your team has SSH access to an unpatched instance, so does anyone who compromises a team member's credentials

If you have been relying on network perimeter controls to keep attackers out, remember that perimeters fail. Copy Fail is what happens when they do and your patch management hasn't kept up.

What to Do This Week

The fix is available. Patches were committed to the Linux kernel mainline on April 1, and major distributions have issued updates. The checklist is short but the reboot requirement catches organizations off guard:

1. Patch and Reboot Every Linux System

Update to Linux kernel 7.0, 6.19.12, or 6.18.22 — or apply your distribution's backported patch
Reboot after patching. Kernel patches do not take effect until the system restarts. A patched but unrebooted server is still fully vulnerable
Check distribution-specific advisories: Ubuntu, Debian, RHEL, Amazon Linux 2023, and SUSE have all issued patches

2. Audit Systems That Haven't Rebooted in 90+ Days

Run uptime or check your monitoring platform for systems with long uptimes — these are your highest-risk targets
Production servers that "can't go down" for a reboot need a maintenance window scheduled now, not at the next quarterly cycle

3. Rebuild Container Images

If your containers run on a Linux base image, rebuild them against a patched kernel
Review pod security policies to restrict AF_ALG socket creation where userspace crypto is not required
Add detection for unexpected AF_ALG SEQPACKET socket creation in your runtime security tooling (Falco, Sysdig, or equivalent)

4. Tighten Shell Access

Audit who has SSH or shell access to Linux systems — remove accounts that are no longer needed
Ensure MFA is enforced on all accounts with shell access, not just admin accounts
Review service accounts that run with local user privileges on shared systems

5. If You Cannot Patch Immediately

Disable CONFIG_CRYPTO_USER_API_AEAD at the kernel level if userspace AEAD crypto is not required in your environment
Apply seccomp filters to restrict AF_ALG socket creation on sensitive systems
Increase monitoring on setuid binary execution and unusual process trees

The Bigger Pattern: AI Is Closing the Exploit Window

Copy Fail was discovered by Theori researcher Taeyang Lee and reported to the Linux kernel security team on March 23, 2026. What happened next is worth paying attention to: the Xint Code Research Team used AI-assisted analysis to turn that research finding into a working, cross-distribution exploit in a matter of days — and published it the same day the CVE went public.

That timeline — discovery to weaponized exploit in under six weeks — represents the new normal. AI-assisted vulnerability research is compressing the window between "bug found" and "exploit in the wild." Patch cycles that run quarterly or annually are structurally incompatible with this environment. If a working exploit can be built in days, the only organizations that stay safe are the ones with patch management measured in days, not months.

This is not a reason to panic. It is a reason to build the operational muscle now, before a vulnerability lands where you haven't patched yet.

Bottom Line

Copy Fail is not theoretical. A working, public exploit exists, it requires no special skills to run, and it affects every major Linux distribution shipped in the last eight years. If you have Linux servers — on premises, in the cloud, or running containers — patch and reboot them this week.

If you are not sure which of your systems are vulnerable, how long they have been unpatched, or whether your current patch management process can respond to a disclosure like this in under a week, that is the real problem to solve.

ITP 360 manages Linux infrastructure and patch management for businesses across South Florida. If you want a fast answer on your exposure to CVE-2026-31431, contact our team for a free vulnerability review. We can also help you build the patch management and cybersecurity posture that keeps the next disclosure from becoming an incident.

CVE-2026-31431: A Linux Kernel Flaw That Gives Attackers Root Without Breaking a Sweat