A nine-year-old bug in the Linux kernel lets any logged-in user become root in seconds, on nearly every Linux server and desktop released since 2017. The exploit is a 732-byte Python script. It does not require luck or special timing. It just works.
Key Takeaways#
- CVE-2026-31431, nicknamed Copy Fail, is a local privilege escalation vulnerability in the Linux kernel rated CVSS 7.8 (Tenable FAQ)
- Any unprivileged local user can use it to become root. The exploit is a 10-line, 732-byte Python script that works on Ubuntu, Red Hat, SUSE, Amazon Linux, and most other major distributions released since 2017 (Help Net Security)
- The exploit requires no race condition, no timing luck, and no special setup. Run it once, get root (Xint)
- The attack works by corrupting the kernel’s in-memory file cache, not the file on disk. The change is invisible to integrity monitoring tools that check files rather than memory (DeepWiki)
- On Kubernetes and other containerized environments, this is a container escape. Because the in-memory file cache is shared across the entire host, a compromised container can attack the host and every other container running on it (OVHcloud Blog)
- The kernel fix was committed on April 1, 2026. As of April 29, most major distributions had not yet shipped patched kernel packages. Check your vendor’s security advisories and update as soon as a patch is available (CERT-EU Advisory)
What “Local Privilege Escalation” Actually Means#
Privilege escalation is what happens when someone who should have limited access to a system manages to get unlimited access. “Local” means they already have a foothold: a shell, a user account, a container. They do not need to break in from the outside first.
In practice, that covers a lot of ground. A malicious insider. A compromised contractor laptop. An attacker who phished one employee’s credentials. A web application with a shell injection bug. Anyone who gets even a low-privilege shell on a Linux machine can now use this to become root.
Root on Linux is not just administrative access. It is full, unconditional control of the machine: every file, every process, every network connection, every credential stored anywhere on the system.
The Bug: A Nine-Year-Old Mistake in Cryptographic Code#
The vulnerability lives in a part of the Linux kernel called algif_aead, which handles a specific category of cryptographic operations used for authenticated encryption (Help Net Security). The bug has been there since 2017. It was discovered by Taeyang Lee, a researcher at Theori, who was studying how the Linux crypto subsystem interacts with page-cache-backed data. Lee fed his hypothesis into Xint Code, Theori’s AI-assisted security scanning tool, which scanned the entire crypto subsystem in roughly an hour and surfaced Copy Fail as its highest-severity finding (Xint).
The bug itself is subtle: under certain conditions, the cryptographic code can be tricked into writing four bytes of controlled data into the wrong place in memory. Four bytes does not sound like much. But the specific wrong place is the kernel’s page cache, and that changes everything.
The Page Cache: Why Four Bytes Is Enough#
When your operating system reads a file, it does not go to disk every time. That would be too slow. Instead, it reads the file once and stores a copy in memory, called the page cache. Every subsequent read of that file comes from memory, not disk.
The page cache is also shared. If two processes read the same file, they are both reading from the same cached copy in memory. Importantly, on a single host running containers (Kubernetes, Docker, etc.), the page cache is shared across all of them.
Here is how it plays out:
flowchart TD
A([Attacker has low-privilege shell]) --> B["Trigger the kernel bug via\ncryptographic API call"]
B --> C["Kernel writes 4 attacker-controlled\nbytes into the page cache"]
C --> D["Target: a setuid binary\n(e.g., /usr/bin/sudo)"]
D --> E["Page cache copy is now corrupted\nDisk copy is untouched"]
E --> F["Any process that reads sudo\ngets the corrupted version from cache"]
F --> G(["Attacker runs modified sudo\nand gets root"])
style A fill:#6b2f2f,color:#d4cebe,stroke:#8b3535
style G fill:#c49a3c,color:#0f0e0b,stroke:#c49a3c
style C fill:#b87a52,color:#0f0e0b,stroke:#b87a52
style E fill:#2a2218,color:#8a8275,stroke:#3d3830
The attacker targets a setuid binary: an executable that runs with root privileges regardless of who launches it. Tools like sudo and passwd are examples. By writing a few bytes into the cached version of that binary, the attacker modifies what the system actually executes without touching the file on disk at all.
The kernel never marks that modified page as dirty, so the change never gets written back to disk. File integrity monitoring tools that hash files on disk see nothing wrong. The file on disk is fine. The file the system is actually running is not.
Why This One Is Different#
The Linux kernel has had local privilege escalation vulnerabilities before. The most useful comparison is to Dirty Cow (2016) and Dirty Pipe (2022).
Dirty Cow required the attacker to win a race condition: a narrow timing window where two things have to happen simultaneously. Getting it right sometimes took thousands of attempts. Dirty Pipe was more reliable, but it came with write-position constraints that made it awkward in practice. It could not touch the first byte of a file and could not write past the original file size, which made targeting setuid binaries tricky (Bugcrowd).
Copy Fail has none of those limitations. No race condition, no positional constraints. The exploit runs once and succeeds reliably. The same 732-byte script works across architectures and across distributions with no tuning. It is not the kind of exploit that occasionally works in a lab. It is the kind that works on the first try, in production, on your machines.
The Kubernetes Problem#
If you run workloads in containers, this vulnerability is worse than it sounds for standalone servers.
Containers on the same host share the host kernel. The page cache is part of the kernel, which means it is shared too. A container that exploits Copy Fail does not just escape its own sandbox: it corrupts a page cache entry that the host and every other container on that host are also using. A compromised application container becomes a vector to root the entire host and everything running on it (OVHcloud Blog).
This is sometimes called a container escape primitive: it does not matter how locked-down your container runtime is if the kernel underneath it is compromised.
Timeline#
| Date | Event |
|---|---|
| March 23, 2026 | Theori reports the vulnerability to the Linux kernel security team |
| April 1, 2026 | Fix committed to the mainline Linux kernel |
| April 22, 2026 | CVE-2026-31431 assigned |
| April 29, 2026 | Public disclosure; proof-of-concept exploit released |
| April 30, 2026 | Most major distributions have not yet shipped a patched kernel |
The gap between the fix landing in the kernel and it reaching distribution packages is normal but uncomfortable. Kernel patches have to be tested and backported by each vendor before they ship. That process takes time, and that is the window where organizations are most exposed.
What To Do#
Right now:
- Check your Linux distribution’s security advisory feed. Red Hat, Ubuntu, SUSE, and Amazon Linux all publish CVE-specific advisories. Watch for a kernel update that references CVE-2026-31431 (Red Hat CVE page).
- When the patched kernel ships for your distribution, treat it as an emergency update and deploy it promptly. This is not a “schedule it for next maintenance window in six weeks” situation.
- If you cannot patch immediately, consider restricting access to the affected cryptographic APIs using Linux Security Modules (AppArmor, SELinux) or seccomp filters. Cloud vendors like OVHcloud published specific guidance for their managed Kubernetes clusters within hours of disclosure.
- Audit who has local shell access to your Linux systems. This exploit requires a local account. Every user account that should not exist is an opportunity.
Longer term:
If your organization does not have a process for rapidly deploying kernel patches when a critical vulnerability ships, this is a good reason to build one. The window between public disclosure and exploitation in the wild tends to be short when a working exploit is already public on day one.
Greymantle Risk Advisory is in the business of making the complex legible. If your team is trying to understand what this means for your environment and where to start, that is exactly the kind of conversation we have. Get in touch.