"Copy Fail" is a rare Linux bug that can turn an unprivileged user into a root admin in seconds

Alfonso Maruccia

Posts: 2,559   +950
Staff
Facepalm: Security researchers recently unveiled "Copy Fail," a bug that could potentially bring the entire Linux ecosystem to a screeching halt. The flaw can be reliably exploited across all Linux-based systems, both on local machines and in cloud environments. Vendors are now scrambling to patch the issue.

Tracked as CVE-2026-31431, Copy Fail could represent a significant security risk in the making. The vulnerability was discovered by researchers at Theori, who investigated the Linux kernel's authencesn cryptographic template using an AI-assisted scanning process. The team also developed a 732-byte Python script capable of escalating privileges and granting an unprivileged user full "root" access.

According to Theori's write-up, Copy Fail can trigger a deterministic, controlled 4-byte write operation into the page cache of any file on the system. The proof-of-concept script can modify a setuid binary flag and obtain root access across Linux distributions released over the past decade.

Third-party security researchers have confirmed that the proof-of-concept code released by Theori works reliably on several Linux versions released since 2017. Copy Fail is reported to affect major Linux distributions, including Ubuntu 22.04, Amazon Linux 2023, SUSE Linux 15.6, and Debian 12.

The situation is particularly serious in multi-tenant environments, including hosting platforms and cloud services built on Kubernetes. According to the researchers, an attacker could exploit a known vulnerability in a WordPress plugin to gain unprivileged shell access to a hosting provider. From there, they could run the Copy Fail PoC to escalate privileges and effectively obtain root control over the hosting platform in a short timeframe.

This type of "make-me-root" vulnerability in the Linux world is rare, but when it does appear, it typically carries extremely high destructive potential. A successfully exploited Copy Fail instance could give an attacker unprecedented access to an organization's internal systems, where they could install stealthy backdoors, collect detailed system logs, move laterally across infrastructure, and more.

Copy Fail's potential impact is also amplified by Linux vendors' tendency to maintain and support older releases for extended periods. Many major open-source ecosystems backport critical security fixes to earlier kernel versions, but in this case Theori reportedly released the proof-of-concept before major vendors had prepared or distributed patches.

Some third-party researchers have criticized the disclosure process, arguing that coordination around the vulnerability was insufficient. In its write-up, Theori listed affected vendors and urged customers to apply official patches for CVE-2026-31431, even though no widespread vendor fixes were available at the time of disclosure.

Since the PoC and technical details became public, several Linux distribution maintainers have issued patches to address Copy Fail. In one example, a hosting provider used for a personal blog reportedly took systems offline for several hours while administrators deployed the fix for CVE-2026-31431.

Permalink to story:

 
How is the bug "rare", and at the same time "Affects virtually every Linux distro released in the past nine years" ???

No idea what's the real world significance of this, is it an actual threat or mostly a theoretical one .. the article definitely does not explain it. Anyway, it emphasizes the major flaw of Linux - the absence of an official security related update channel. Every distro exists in its own parallel universe of updates and patches released by different entities .. it's a horrible mess that has to be streamlined somehow.
 
If I understand correctly this vulnerability requires that the attacker have physical access to the computer.
 
I'm pretty sure the implication is that the type of bug is rare to find on Linux (bypassing privilege).

Privilege escalation bugs are actually quite common, what makes this one "special", and not in a ret@rded way, is this, from the CVE:

"Linux LPE CVEs ship daily. Most are race-dependent, narrowly version-specific, or both. Copy Fail isn't — it's a straight-line logic flaw with four properties that almost never appear together:

Portable. Same script roots Ubuntu, Amazon Linux, RHEL, SUSE. No per-distro offsets, no version checks, no recompilation.

Tiny. 732-byte Python script, stdlib only (os, socket, zlib). No compiled payload, no dependencies. Python 3.10+ for os.splice.

Stealthy. The write bypasses the VFS path entirely; the corrupted page is never marked dirty. Nothing hits disk — on eviction or reboot, the cache reloads clean and a forensic disk image shows the original file. (See the integrity-tool FAQ entry below for the in-cache detection window.)

Cross-container. The page cache is shared across the host. A pod with the right primitives compromises the node and crosses tenant boundaries — container escape primitive, not just LPE."

The CVE is worth the read. The cross-container angle is the one that makes the hair on the back of the neck stand up.

I just wish the researchers had followed protocol and advised distros of the flaw before releasing their proof of concept, which is pretty sh1tty.
 
...
I just wish the researchers had followed protocol and advised distros of the flaw before releasing their proof of concept, which is pretty sh1tty.

This is a confusing article. Brodie Robertson already made a video on this and he said if you have a kernel released in March or later it has already been patched. I believe that is correct now based on the copy.fail website. Also, kernel maintainers were notified first and foremost:

Disclosure timeline:
2026-03-23 Reported to Linux kernel security team
2026-03-24 Initial acknowledgment
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainline
2026-04-22 CVE-2026-31431 assigned
2026-04-29 Public disclosure (https://copy.fail/)
 
I'm pretty sure the implication is that the type of bug is rare to find on Linux (bypassing privilege).

Nope, privilege bypasses and escalations are actually quite common in Linux, just like Windows and Mac OS! You're not all that special Linux.
 
Last edited:
This is a confusing article. Brodie Robertson already made a video on this and he said if you have a kernel released in March or later it has already been patched. I believe that is correct now based on the copy.fail website. Also, kernel maintainers were notified first and foremost:

Disclosure timeline:
2026-03-23 Reported to Linux kernel security team
2026-03-24 Initial acknowledgment
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainline
2026-04-22 CVE-2026-31431 assigned
2026-04-29 Public disclosure (https://copy.fail/)

I received debian security list emails advising of the new kernels on April 30 and May 1 for stable and old-stable, respectively, and applied them as soon as possible. It's extremely rare for production systems to be configured for unattended application of kernel updates followed by required reboot - scheduling install/reboot rather than having systems just reboot at some random time is nearly always necessary, and that incurs an inherent delay. It also takes time for kernel maintainers to apply patches to mainline - which, as open source, is effectively the 'public disclosure' day for black hats - and fully test for stability and regressions; nobody likes to apply an update, reboot, and find their machine catastrophically borked.

So, all what Theori says for the timeline may be true, but the turnaround was unreasonably thin. Five or so weeks isn't a whole hell of a lot of time for kernel patching and distribution. The de facto 'standard' timeline from notification to publication for critical vulnerabilities in the real world is about 45 to 90 days. It's also not instantaneous that end-users will install the updated kernels the moment they're available. It's further complicated by the depth of the bug - going back to 2017 - each older OS version going back that far (depending...) needs to be patched, so that amplifies the time it takes for maintainers to fully mitigate from their end.

Releasing a polished 'proof of concept' exploit the day of public disclosure is simply not cool however.
 
It's further complicated by the depth of the bug - going back to 2017 - each older OS version going back that far (depending...) needs to be patched, so that amplifies the time it takes for maintainers to fully mitigate from their end.

To refine that statement a bit - anyone foolish enough to be running an OS that's years past LTS - well, that's on them, not on the maintainers to fix. In other words, if you're still running debian Buster (LTS ended June 2024), time to man-up and upgrade your damned system so you can get the patched kernel.

I say this partly for myself, as I have a critical system still running Bullseye, which falls out of LTS in August. So I need to put on my big-boy pants and stop putting off upgrading to stable...
 
To refine that statement a bit - anyone foolish enough to be running an OS that's years past LTS - well, that's on them, not on the maintainers to fix. In other words, if you're still running debian Buster (LTS ended June 2024), time to man-up and upgrade your damned system so you can get the patched kernel.

I say this partly for myself, as I have a critical system still running Bullseye, which falls out of LTS in August. So I need to put on my big-boy pants and stop putting off upgrading to stable...

No one wants to go through the effort of upgrading an in-production Linux system once they get it working. 2024? You sweet innocent child; I'm still maintaining a RHEL server that was set up like 15 years ago.
 
No one wants to go through the effort of upgrading an in-production Linux system once they get it working.

"No one". Awfully broad statement there. A lot of variables at work; are you just running a junk personal website? That's your path then. Have hundreds of thousands to millions of paying customers who will be affected by an exploit? You're damn right they want to upgrade in-production systems beyond 'once they get it working'.

2024? You sweet innocent child; I'm still maintaining a RHEL server that was set up like 15 years ago.

Good for you. You're free to assume whatever risks you choose. If you have a support contract and RH is distributing patches for it, it's just plain silly not to apply them. On the other hand, if you don't care if your server gets hacked or destroyed, great!

'sweet innocent child' is offensive. I worked professionally as a systems and network engineer for nearly thirty years. It sounds like you're an amateur with little experience managing systems. And that's fine too. But saying you're still maintaining a fifteen year old server isn't even probative - it's not a matter of how old the server is, it's a matter of what version of RHEL you're running and whether it's patched appropriately - assuming you care whether or not it gets exploited, which is the overarching variable.
 
Good for you. You're free to assume whatever risks you choose. If you have a support contract and RH is distributing patches for it, it's just plain silly not to apply them. On the other hand, if you don't care if your server gets hacked or destroyed, great!

'sweet innocent child' is offensive. I worked professionally as a systems and network engineer for nearly thirty years. It sounds like you're an amateur with little experience managing systems. And that's fine too. But saying you're still maintaining a fifteen year old server isn't even probative - it's not a matter of how old the server is, it's a matter of what version of RHEL you're running and whether it's patched appropriately - assuming you care whether or not it gets exploited, which is the overarching variable.
The overarching variable is "the dedicated program we wrote 20 years ago won't run on newer kernels, and no one has any idea how it works or how to fix it", not security. That, and upgrading the application to run would cost the program money that hasn't been budgeted for, so we'll never get approval in any case.
 
The overarching variable is "the dedicated program we wrote 20 years ago won't run on newer kernels, and no one has any idea how it works or how to fix it", not security. That, and upgrading the application to run would cost the program money that hasn't been budgeted for, so we'll never get approval in any case.

In that case, good luck to you - not being flip or dismissive. Organizational dysfunctions at higher than one's pay grade are often a nightmare - or one waiting to happen.

The San Francisco Municipal Transit system still relies on 5 ¼ floppy discs as the only means of keeping the system software running. They've spent tens of millions so far trying to replace them with something perhaps a little newer...maybe eventually they'll be able to upgrade to 3 ½ inch disks!
 
Tried it at home and at office. It works. What makes this one special is that it works across a huge range of distributions and is really easy to run.
Anyway, I installed the latest updates, and now it no longer works.
 
How is the bug "rare", and at the same time "Affects virtually every Linux distro released in the past nine years" ???

No idea what's the real world significance of this, is it an actual threat or mostly a theoretical one .. the article definitely does not explain it. Anyway, it emphasizes the major flaw of Linux - the absence of an official security related update channel. Every distro exists in its own parallel universe of updates and patches released by different entities .. it's a horrible mess that has to be streamlined somehow.
Rare, because it's one bug that was found, which doesn'thappen very often. When one of these "rare" bugs are found, it's reach can be wide. Just like COVID - rare (the last time something similar happened was the Spanish flu), but its reach was definitely wide.
 
How is the bug "rare", and at the same time "Affects virtually every Linux distro released in the past nine years" ???

The type of vulnerability in Linux is rare in general. The kernel, however, isn't rare, which is why it can effect multiple distributions.
 
Back