Linux Copy Fail Vulnerability: Fixed Kernel Versions and Current Status

The Linux kernel carried a flaw called "Copy Fail" (CVE-2026-31431) that let an ordinary user account seize administrator (root) control of almost any Linux server. It is fixed in kernels 5.10.254 / 5.15.204 / 6.1.170 / 6.6.137 / 6.12.85 / 6.18.22 / 6.19.12 and later — every stable and long-term kernel series shipping as of July 23, 2026 already contains the fix. If your servers have taken OS updates and a reboot since May 2026, no further action is needed. If they have not, they remain exposed. That is the short version of this article.

Copy Fail is a bug in the cryptographic subsystem at the heart of the Linux kernel, exploitable with just 732 bytes of Python code, and it affected essentially every Linux system shipped since 2017 — Ubuntu, Red Hat, Amazon Linux, SUSE, Debian, Fedora. On May 1, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to the Known Exploited Vulnerabilities (KEV) catalog — meaning in-the-wild exploitation is officially confirmed — and ordered federal civilian agencies to patch by May 15, 2026, a deadline now long past.

This article first ran on May 12, 2026 as breaking coverage. It has since been rewritten as a status summary for readers checking whether their systems are safe. Copy Fail turned out to be the first pipe to burst in a chain: Dirty Frag and Fragnesia followed in May, and DirtyClone, GhostLock, and RefluXFS arrived in June and July (details below).

The People Who Make a 732-Byte Python Script Look Like "Nothing Happened"

"A single 732-byte Python script lifts an unprivileged user to root" sounds implausible on its own, so the operator-side question worth answering first is: who is actually carrying that script around, against which servers, to take what.

The people who treat Copy Fail as live ammunition are not random pranksters; they are the professional groups for which those 732 bytes are a direct revenue lever. Ransomware crews who buy a non-root shell on a shared VPS or EC2 instance and then reach the whole cloud account, industrial spies after a competitor's customer database, source code, and pre-sale materials, targeted attackers pivoting from a corporate Linux workstation into the accounting server and identity provider, and initial access brokers (IABs) reselling already-rooted boxes in bulk to other groups are the principal customers. What they come to take is the password hashes in /etc/shadow, the customer rows in production databases, Kubernetes service-account tokens, AWS IAM temporary credentials, and the persistent backdoor they then install under systemd. One run of that 732-byte script is enough to open the route from an ordinary user shell all the way up to a root that can touch every one of those. And because nothing on disk is ever modified — the rewrite happens only in the page cache — standard forensic tooling reports "files intact" and operators see no warning at all.

In security terminology this is a kernel-level "local privilege escalation (LPE)," but reading "local" as "needs physical proximity" would be misleading. The real entry points are a non-root shell taken through a web application bug, a leaked developer SSH account, or the attacker's own tenant on a rented VPS — any one rung below root is enough, and from there the climb is immediate. The post-root playbook is well-rehearsed: persistence as a systemd unit, a planted file under /etc/sudoers.d/, an extra key appended to ~/.ssh/authorized_keys, edits to auth.log and wtmp to erase the entry trace. If the host is a Kubernetes node the whole cluster is in range; on a container host every co-tenant is exposed; on an Active Directory–joined Linux box every Windows endpoint in the domain is reachable. The blast radius extends far past the one server that got touched.

CVSS 7.8 reflects the local-vector assumption only. What an organization running Linux servers actually loses is not a single root compromise but customer data, private keys, and the trust of the entire internal network walking out together, and that state persisting for weeks or months while everything still looks "as if nothing happened".

What kind of vulnerability is Copy Fail

Copy Fail is a bug in the component of the Linux kernel that handles cryptographic operations.

A short explanation. Linux relies heavily on internal crypto operations for disk encryption (dm-crypt), IPsec traffic, and more. To enable that, the kernel exposes interfaces so applications can call cryptographic primitives, one of which is a socket-style interface called "AF_ALG." Think of the socket here as a communication channel from a program into kernel features.

The problem lives in an "in-place optimization" added to the crypto code in 2017. Normally the "source data" and "destination buffer" for a crypto operation must be different regions of memory, but for efficiency this optimization deliberately reuses the same memory for both. Combine that with the splice() system call (which moves portions of files between buffers), and an attacker can produce a controlled four-byte write into the kernel's in-memory cache of any readable file. The upstream fix simply reverts that 2017 optimization (commit a664bf3d603d).

Four bytes does not sound like much, but it is plenty. Linux has setuid binaries like su and sudo that automatically run with root privileges. Tweaking the in-memory image of one of those binaries by just four bytes is enough to let an attacker execute arbitrary code as root.

What makes this nastier: the file on disk is never modified. The change only happens in the in-memory page cache. Standard forensic checks see the file as unmodified, which means the attack leaves few obvious traces.

Technical writeups are available from security firm Xint, Palo Alto Networks Unit 42, and Tenable.

Why every distribution is hit at once

Normally, Linux distributions, Ubuntu, Red Hat, Debian, SUSE, fork off into endless branches. The reason Copy Fail is described as "all distributions falling simultaneously" is that the bug lives inside the Linux kernel itself.

The Linux kernel is the core OS software. Ubuntu, Red Hat Enterprise Linux, Amazon Linux—they all wrap their own bodywork around the same engine (the Linux kernel). If the engine cracks, it doesn't matter which body you bolted on.

The fixed kernel releases are 5.10.254 / 5.15.204 / 6.1.170 / 6.6.137 / 6.12.85 / 6.18.22 / 6.19.12 and later (the inverse of the affected ranges recorded by NVD). Every series shipping as of July 2026 — 6.18.39, 6.12.96, 6.6.144, 6.1.177, 5.15.211, 5.10.260 and so on — is far past those numbers, so a kernel that has simply been kept updated is fixed. On Ubuntu, the fixed packages are, for example, 6.8.0-117.117 for 24.04, 5.15.0-179.189 for 22.04, and 5.4.0-230.250 for 20.04 (Ubuntu's announcement).

Production servers, home servers, Kubernetes clusters, AWS EC2 instances, IoT devices, parts of Android—as we reported when desktop Linux finally crossed the 5% mark, Linux deployments keep growing every year. Copy Fail puts essentially all of them in range.

Unit 42 estimates "millions of systems" exposed. Microsoft puts it as "millions of Kubernetes clusters in scope."

A lineage of bugs that take every distribution down together

This is not the first time the Linux kernel has shipped a privilege escalation bug that hits every major distribution at once. Similar-shaped bugs come around periodically, and lining them up helps situate Copy Fail.

PwnKit (2022, CVE-2021-4034): a flaw in polkit's SUID binary. Every major distribution that shipped polkit allowed root.

Dirty Pipe (2022, CVE-2022-0847): pipe_buffer flag initialization missing. Hit every Linux kernel 5.8 and later, including Android phones.

Looney Tunables (2023, CVE-2023-4911): a buffer overflow in the dynamic linker of glibc, the standard C library. Direct hit on Fedora, Ubuntu, Debian, and other majors.

Copy Fail (2026, CVE-2026-31431): this bug.

Each of those four bugs sits in a different place: polkit's SUID binary, the kernel's pipe machinery, glibc's linker, and now the kernel crypto subsystem. The technical surface is entirely different each time, yet from an operator's perspective the impact is identical: "if you run Linux, nearly every server is exposed to root takeover." The response—patch fast, hunt for attackers, narrow the blast radius in the cloud—takes the same shape every time.

A bug of this type used to land every two or three years. Since Copy Fail, the pace has accelerated sharply — and the chain did not stop in May. Dirty Frag (CVE-2026-43284, May 7) and Fragnesia (CVE-2026-46300, May 13) followed within weeks. Then came a ptrace-path root escalation (CVE-2026-46333, May 20), DirtyClone (CVE-2026-46331, July 6, CVSS 8.8), GhostLock (CVE-2026-43499, latent since 2011, with a public exploit circulating in July), and RefluXFS (CVE-2026-64600, an XFS race condition latent since kernel 4.11 in 2017, July 22). Copy Fail was the opening entry of that run, and the decision framework in this article applies to each new arrival.

What operators should do: a four-layer defense framework

Here is what to work through if any of your servers are still unpatched. This is not a vulnerability you can shut off with a single switch, so we work through four layers.

Layer 1: Patch (highest priority)

On Ubuntu, the following picks up the fixed kernel package (Ubuntu's official announcement):

sudo apt update && sudo apt upgrade
sudo reboot

Red Hat, Amazon Linux, and SUSE have each shipped patches. Check each distribution's official advisory for vendor-specific patch information.

Layer 2: Interim mitigation if you cannot reboot immediately

Disabling the algif_aead kernel module closes the path the attack uses. Ubuntu ships a dedicated kmod package that disables it. Doing it manually, create the following file:

blacklist algif_aead
install algif_aead /bin/true

Caveat: in environments that rely heavily on crypto—disk encryption, IPsec VPNs—check dependencies before applying. Rolling this out cold in production may break adjacent services.

Layer 3: Reduce what unprivileged users can do

Cut off the precondition: "an unprivileged user can call kernel crypto." Depending on the server's role:

• Disable unprivileged user namespaces: sysctl kernel.unprivileged_userns_clone=0
• Restrict AF_ALG socket creation and keyctl via seccomp profiles for containers
• Limit which binaries can call socket(AF_ALG, ...) via AppArmor / SELinux

Layer 4: Monitor for "pre" and "post"

Unit 42 recommends two detection patterns:

• A non-root user launching su from a parent process that is not the normally expected one
• curl downloading something followed immediately by su (the typical pattern in the public PoC)

eBPF-based solutions (eBPF is an in-kernel observability and policy mechanism) can alert on the combined invocation of socket(AF_ALG, ...) and splice(). Microsoft Defender has already added Copy Fail-related activity to its detection set, and Splunk and Trend Micro have published detection guides. If your organization runs EDR, confirm the signature update.

Why the impact widens in clouds and containers

There is a second reason Copy Fail is frightening: it bites into the way clouds and containers are built.

Container tech like Docker and Kubernetes run many containers sharing the host's Linux kernel. If an unprivileged user inside a container uses Copy Fail, the chain works like this:

1. Gain root inside the container (still confined to the container)
2. Because the kernel is shared with the host, write into the host's page cache
3. Corrupt a privileged binary on the host and escape the container into the host OS

That is a "container breakout." Microsoft describes "millions of Kubernetes clusters in scope."

On the cloud side, multi-tenant environments where multiple customers' workloads ride the same host face a real risk of lateral movement to neighboring tenants. Patching only runC or other container runtimes is not enough; the host kernel update is mandatory.

As we reported last month, seven Japanese manufacturers disclosed ransomware incidents in March alone. Attackers always need "the next tool after gaining initial access." After landing through an event like the cascading supply-chain compromise of Trivy, Copy Fail offers exactly that next step.

Discovery and disclosure timeline

Some context on public records. The original discoverer is Taeyang Lee of Korean security firm Theori, who identified the initial attack surface while studying the Linux kernel's crypto subsystem. The Xint Code Research Team extended that finding using AI-assisted analysis and identified Copy Fail—the most severe outcome—within about an hour.

The timeline:

• March 23, 2026: initial report to the Linux kernel security team
• April 1, 2026: patches committed to mainline
• April 29, 2026: Xint publishes the vulnerability
• May 1, 2026: CISA adds to KEV; federal civilian agencies must patch by May 15
• May 7 / May 13, 2026: Dirty Frag, then Fragnesia disclosed — the second and third bugs of the same shape
• May 15, 2026: the CISA KEV deadline passes
• May 20, 2026: Qualys discloses the ptrace-path escalation CVE-2026-46333
• July 6, 2026: DirtyClone (CVE-2026-46331, CVSS 8.8) disclosed
• Early July 2026: a public exploit circulates for GhostLock (CVE-2026-43499, latent since 2011)
• July 22, 2026: Qualys discloses RefluXFS (CVE-2026-64600, latent since kernel 4.11 in 2017)
• Status as of July 23, 2026: every stable and long-term kernel series shipping carries the Copy Fail fix; the KEV catalog still lists ransomware use as "Unknown"

The kernel maintainers responded within 24 hours and committed fixes in nine days, a very fast turnaround. Nearly three months on from disclosure, Theori's official PoC is public on GitHub and detection guidance is available from Splunk and Trend Micro. No large-scale ransomware or botnet campaign has been publicly tied to Copy Fail as of July 23, 2026, but VulnCheck counts it among the routinely targeted vulnerabilities of the first half of 2026.

Still unpatched? It is not too late

The May 15, 2026 KEV deadline passed more than two months ago, but the exposure did not pass with it. A server that has not taken a kernel update since spring 2026 is open not only to Copy Fail but to the same-shaped bugs that followed it — Dirty Frag, Fragnesia, DirtyClone, GhostLock, RefluXFS. Updating to a current kernel closes the whole run at once.

The priority: first, inventory which Ubuntu / Red Hat / Amazon Linux / SUSE / Debian / Fedora versions you have in scope. Then split servers into "patch right now" and "depends on other services, patch carefully." For the latter, buying time with the algif_aead disable is reasonable. For Kubernetes clusters, host-kernel updates are mandatory; do not put off planning the rolling update.

Vulnerabilities like Copy Fail do not magically disappear once the news cycle moves on. Servers that remain unpatched—IoT devices, aging on-prem boxes, internal servers whose owners are gone—will stay in attackers' sights for years. As we previously analyzed with Hello Work's core system that has become "untouchable," the same structure sits inside many private-sector systems too.

When the next "every-distro privilege escalation" bug arrives — and between May and July 2026 four more already did — reuse the four-layer framework from this article: patch / module disable / reduce unprivileged user power / step up monitoring. The runbook you build for Copy Fail works for the next PwnKit-class issue too.

References

• ▸ Microsoft Security Blog - CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments (May 1, 2026)
• ▸ Palo Alto Networks Unit 42 - Copy Fail: What You Need to Know
• ▸ Xint - Copy Fail: 732 Bytes to Root on Every Major Linux Distribution (April 29, 2026)
• ▸ Tenable - Copy Fail (CVE-2026-31431): FAQ
• ▸ Ubuntu Blog - Fixes available for CVE-2026-31431 (Copy Fail)
• ▸ CISA - Known Exploited Vulnerabilities Catalog
• ▸ CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")
• ▸ NVD - CVE-2026-31431
• ▸ Theori - copy-fail-CVE-2026-31431 (official PoC, GitHub)
• ▸ Sysdig - CVE-2026-31431 Copy Fail: Linux kernel flaw lets local users gain root in seconds
• ▸ VulnCheck - Routinely Targeted Vulnerabilities, May 2026