Copy Fail: The Nine-Year-Old Linux Bug That Hands Attackers the Keys to Your Server

A newly disclosed vulnerability quietly sat inside nearly every Linux system on the planet since 2017. Here's what it does, why it matters, and what you need to do about it.

The short version

If you run Linux, whether that's a personal server, a cloud virtual machine, or a containerised workload, there is a good chance you were vulnerable until very recently. A security flaw nicknamed "Copy Fail" (officially tracked as CVE-2026-31431) allowed any ordinary, unprivileged user already on a machine to quietly promote themselves to the most powerful user on the system: root. No password required. No special skills. Just a 732-line Python script.

The good news: a patch is available. The action you need to take is simple: update your Linux kernel.

Let's Start with an Analogy

Imagine a large office building. Every employee has a keycard that opens the doors they're supposed to access: their own office, the kitchen, the meeting rooms. Only the building manager has a master key that opens everything, the server room, the payroll office, the safe.

Now imagine there's a quirk in how the copy machine works. You hand it a document to duplicate, but due to a flaw in its internal logic, it accidentally stamps the word "MANAGER" onto your keycard while you wait for your printout. You didn't ask for that. The machine didn't intend to do it. But now your card opens every door in the building.

That is essentially what Copy Fail does, and the "copy machine" in this case is a part of the Linux kernel responsible for handling encrypted data.

What Is the Linux Kernel, and Why Should You Care?

The kernel is the deepest, most trusted layer of an operating system. Think of it as the building's foundation and electrical wiring, everything else (your apps, your files, your network connections) relies on it. Because the kernel is so trusted, a bug there is far more dangerous than a bug in, say, a web browser. If someone exploits the kernel, they effectively own the entire machine.

What Actually Goes Wrong

In 2017, a developer added an optimisation to a part of the Linux kernel that handles encryption and decryption, specifically a component called algif_aead. The intention was sensible: instead of making an extra copy of data during a cryptographic operation, the code would work on the data in place to save memory and time. A small efficiency win.

The problem? When data is decrypted "in place," the kernel ends up pointing its writable workspace at the same memory location used by the page cache, a system-wide, shared memory region where the contents of files are temporarily stored for fast access.

Here is why that is a big deal: the page cache is shared across the whole system. Files like /etc/passwd, the file that records who each user is and what their user ID number is, live there. Because the decryption process briefly makes that memory writable, an attacker can sneak in a small, targeted change to the cached contents of that file, swapping their own user ID from an ordinary number (like 1000) to zero, which is root.

The change never even touches the actual file on disk. It only alters the in-memory copy. But that is enough, because the operating system reads from the cache when it needs to check who you are. From the system's point of view, you are now root.

No race condition to win. No guessing memory addresses. Just a straight-line logical flaw that works reliably, every time, across every major Linux distribution.

How was it found?

This is where the story gets even more interesting. Copy Fail was not found by a human painstakingly reading through thousands of lines of kernel source code. It was discovered by Xint Code, an AI-assisted security research system built by the offensive security firm Theori — the same team that has won the DEF CON Capture the Flag competition nine times.

According to Theori, the vulnerability was surfaced with a single operator prompt and roughly an hour of automated scanning against the Linux cryptography subsystem. A flaw that had hidden in plain sight for nine years was found in about sixty minutes.

This has significant implications beyond the bug itself. Security researchers have historically assumed that finding kernel-level vulnerabilities is hard, slow, and expensive work, and that this naturally limits how many new ones appear each year. Copy Fail challenges that assumption. If AI-assisted tools can find bugs like this in an hour, the landscape of vulnerability discovery is changing faster than most organisations have accounted for.

Who is affected

Virtually every mainstream Linux system running a kernel released between 2017 and now. That includes:

  • Ubuntu (all common versions)
  • Red Hat Enterprise Linux (RHEL) and its derivatives (CentOS, Rocky Linux, AlmaLinux)
  • Amazon Linux (used extensively in AWS cloud environments)
  • SUSE Linux Enterprise
  • Debian and its derivatives

The vulnerability also has serious implications for containerised environments (Docker, Kubernetes). Containers on the same host share a kernel. That means a vulnerable container can affect the host machine and every other container running alongside it, a "container escape" that bypasses isolation entirely.

What can an attacker actually do with this?

To exploit Copy Fail, an attacker needs to already have some access to the target machine, they must be able to run code as a regular, unprivileged user. This rules out purely remote attacks where the attacker has no foothold at all.

However, "already having some access" is a very common scenario in the real world:

  • A disgruntled employee or contractor with a standard account
  • An attacker who gained a low-privilege foothold via a phishing attack or web application vulnerability
  • A malicious process running inside a container on a shared cloud host

Once exploited, the attacker has full root access: they can read every file, install backdoors, exfiltrate data, modify system logs, or take any other action on the machine.

The Fix and What You Should Do

The Linux kernel team has released patches. The fix is straightforward in principle: the 2017 in-place optimisation has been reverted. Decryption operations in algif_aead now work on a separate copy of the data rather than the shared page cache, closing the window entirely.

If you manage Linux systems, your action items are:

  • Apply kernel updates immediately. Check your distribution's security advisories and update to the patched kernel version. For most distributions, this means running your standard package manager update (apt upgrade, dnf update, yum update, etc.) and rebooting.

  • If you cannot patch right now, you can disable the vulnerable kernel module as a temporary stopgap by running:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead

This prevents the vulnerable component from being loaded. Note that this may affect software that relies on kernel-level AEAD cryptography.

  • If you run containers, treat any unpatched host as compromised in terms of isolation. Prioritise patching host kernels before anything else.

  • Audit local access. Review which users have shell access to your systems and remove or restrict accounts that no longer need it.

The bigger picture

Copy Fail is not the most exotic vulnerability ever disclosed. It does not involve clever cryptographic attacks or hardware side-channels. It is a straightforward logic flaw: a misplaced pointer in a nine-year-old optimisation, and that is precisely what makes it sobering.

The closest historical comparison is Dirty Pipe (CVE-2022-0847), a 2022 Linux privilege escalation that worked through a similar mechanism. Copy Fail is the same class of primitive, in a different subsystem, found four years later.

The lesson for organisations is not just "patch faster," though that is certainly true. It is that the tools available for finding these bugs are improving rapidly, on both sides of the security divide.

Defenders need to assume that the bar for discovering kernel-level vulnerabilities is dropping, and plan accordingly, through faster patch cycles, stronger network segmentation, and a hard look at whether shared-kernel container deployments are the right default for sensitive workloads.