A new Linux vulnerability was disclosed this week that security researchers are already calling one of the most significant local privilege escalation bugs in years. It goes by the name Copy Fail, and it has been sitting quietly in virtually every major Linux system deployed since 2017.
If your organization runs Linux servers — and statistically, there's a very good chance it does — this one is worth understanding.
We'll keep the technical depth accessible here. For the full technical deep-dive, the original research from Theori's Xint Code team at copy.fail is the authoritative source and well worth reading if you have security staff who can act on it. We've also published a free detection package on GitHub with YARA rules, auditd configurations, and Wazuh rules your team can deploy today.
First: why does Linux matter to you?
It's easy to think of Linux as something only developers and data centers worry about. But the reality is that Linux is the invisible foundation under a remarkable amount of the internet and modern infrastructure.
Linux leads the global server operating system market with a 63.1% share of web-facing servers worldwide.[^1] When you visit a website, check a patient portal, use a cloud-based application, or interact with almost any government online service, there's a strong chance a Linux server is involved somewhere in that transaction.
[^1]: Wikipedia, Usage Share of Operating Systems, citing StatCounter data, March 2026.
For organizations that run their own infrastructure — whether that's an on-premises server, a hosted virtual machine, or a co-located system — Linux is often the operating system powering the whole thing. And for essentially all of those systems deployed since 2017, this vulnerability exists and is exploitable.
What is CVE-2026-31431?
The short version: a flaw in the Linux kernel allows any user who is already logged into a Linux system — even an ordinary, unprivileged user with no special permissions — to instantly gain full administrator (root) access.
The exploit is a Python script. It is 732 bytes long. It takes less than a second to run. It works without any specialized knowledge, without guessing passwords, and without any timing tricks. The same script works unmodified on Ubuntu, Red Hat Enterprise Linux, Amazon Linux, and SUSE — essentially all major Linux distributions.
The vulnerability has existed, undetected, in Linux kernels since a code change in 2017. The researchers who found it — Taeyang Lee and the Xint Code team at Theori — disclosed it responsibly after coordinating with the Linux kernel security team on a patch.
LPE vs. RCE: understanding the difference
You may have seen these terms in security advisories. Understanding the distinction matters here, because it shapes how seriously to take a given vulnerability.
Remote Code Execution (RCE) is when an attacker can run malicious code on your system without having any access to begin with. They send a specially crafted request over the internet, and they're in. RCE vulnerabilities are typically the most severe class — an attacker with no foothold can go straight to executing commands. Think of it like a burglar who can walk through a locked front door.
Local Privilege Escalation (LPE) is different. It requires the attacker to already have some level of access — a login, a running process, a container, anything that gives them a presence on the system. From there, the LPE allows them to elevate that limited access to full administrative control. Using the same analogy: the burglar is already inside (perhaps through a window you didn't know was open), and the LPE is what lets them into the locked office where the valuables are kept.
Copy Fail is an LPE. That distinction is important — it means the vulnerability alone doesn't let a random attacker on the internet break into your system from nothing. But "less severe than RCE" does not mean "not severe."
Why LPE still matters — especially for organizations like yours
Here's where it gets practically significant for small businesses, local governments, schools, and healthcare organizations.
An LPE vulnerability becomes dangerous the moment any attacker has any foothold on the system. And foothold opportunities are far more common than most people realize:
Web applications and contact forms. If your organization runs a website with any kind of interactive functionality — a contact form, a login page, a file upload, a support ticketing system, a content management system — there is a class of vulnerability called injection (SQL injection, command injection, server-side template injection) that can allow a remote attacker to execute limited commands on your web server. Combined with Copy Fail, that limited access immediately becomes full root access on the underlying Linux system. The web form is the window; Copy Fail is the path to the locked office.
Shared hosting environments. Many smaller organizations use shared Linux servers, where multiple customers or applications run on the same underlying system. If any other tenant on that system has a vulnerability that gets exploited, Copy Fail means the attacker can escalate to compromise the entire host — including your data.
Multi-tenant cloud and container environments. The researchers specifically note that this vulnerability crosses container boundaries. The page cache — the in-memory copy of files — is shared across the entire host. A process inside a container can use this vulnerability to affect files outside of it. For organizations using shared container infrastructure or multi-tenant platforms, this is a meaningful risk.
Malicious insiders and compromised accounts. Any employee, vendor, or contractor with even basic shell access to a Linux system can use this to become a full administrator — silently, in under a second.
CI/CD and build pipelines. If your organization uses automated build or deployment systems that execute code from external sources (including pull requests or dependency packages), those execution environments are in scope.
The researchers who disclosed this put it bluntly: if the only users with shell access are fully trusted members of your own team, your risk is lower. But for almost any organization that runs Linux as part of a service, or where external code ever touches a Linux system, the risk is real.
One more thing that makes this unusual
Most file integrity monitoring tools — software that watches for unauthorized changes to important files — work by monitoring the filesystem. If something modifies /etc/passwd or a system binary on disk, they detect it.
Copy Fail doesn't touch the disk. It modifies the in-memory page cache — the kernel's cached copy of a file that it uses when executing programs. The on-disk file remains completely unchanged. Standard integrity tools will see nothing wrong. The file hash will be clean. The on-disk content will be unmodified.
This means that on a system where Copy Fail has been exploited, your existing file integrity monitoring may give you a false sense of security. Detection requires behavioral monitoring at the syscall level — which is exactly what the detection rules in our GitHub repository are designed to provide.
What should you do?
1. Check whether you're affected
If you're running any Linux system with a kernel version between 4.14 and 6.18.21 — which includes the default kernel of essentially every major Linux distribution released between 2017 and the patch date — you are affected. You can check your kernel version by running:
uname -r
If the result is below 6.18.22, you are running a vulnerable kernel.
2. Apply the immediate mitigation
If you cannot patch immediately, a one-line mitigation is available that blocks the exploit primitive entirely without any impact on standard operations:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true
This disables the specific kernel module that the exploit requires. It has no impact on standard networking, TLS, or filesystem encryption. It only affects IPsec configurations using Extended Sequence Numbers — an uncommon configuration outside dedicated VPN gateway hardware. If you're unsure whether this applies to your environment, applying it is the safer choice while you arrange patching.
3. Patch your kernel
Update to kernel 6.18.22 or later. Distribution-specific guidance:
| Distribution | Update command |
|---|---|
| Ubuntu / Debian | sudo apt-get update && sudo apt-get upgrade |
| RHEL / Rocky / AlmaLinux | sudo dnf update kernel |
| Amazon Linux | sudo dnf update kernel |
| SUSE / openSUSE | sudo zypper update kernel-default |
| Arch Linux | sudo pacman -Syu |
After updating, reboot to load the new kernel.
4. Deploy detection rules
Even after patching, it's worth knowing whether anyone attempted to exploit this before the patch was applied. Our detection package at github.com/insomnisec/public_cve_detections includes:
- YARA rules for scanning files and memory for the known exploit
- Auditd rules that capture the syscall chain at the kernel level
- Wazuh correlation rules that chain the auditd events into prioritized alerts
- A MISP event template for threat intelligence platforms
The package also includes detailed notes on what these rules can and cannot catch — including an honest explanation of why the page-cache write itself is undetectable after the fact.
A note on the original research
The discovery of Copy Fail was made by Taeyang Lee at Theori's Xint Code team, with assistance from their AI security scanning software. The full technical write-up — explaining the root cause, the nine-year history of how three separate kernel changes combined to create the vulnerability, and a detailed walkthrough of the exploit mechanics — is available at copy.fail and xint.io. If you have technically oriented staff, we recommend reading it directly.
What we've tried to do here is provide the context that helps non-technical stakeholders understand the risk and the action required. The two perspectives complement each other.
Summary
| CVE | CVE-2026-31431 |
| Nickname | Copy Fail |
| Type | Local Privilege Escalation (LPE) |
| Affected | Linux kernels 4.14 – 6.18.21 (2017 to present) |
| Exploit complexity | Trivial — 732-byte Python script, no race condition |
| Immediate mitigation | Disable algif_aead module (one command, no reboot) |
| Full fix | Update kernel to 6.18.22 or later |
| Detection package | github.com/insomnisec/public_cve_detections |
If you need help assessing whether your systems are affected, applying the mitigation, or deploying detection coverage, get in touch — this is exactly the kind of situation CrowdSOC was built for.