• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Copy Fail: One 732-Byte Python Script Gives Root on Ubuntu, RHEL, SUSE, Amazon Linux

4saken

4saken

[H]F Junkie
2FA
Joined
Sep 14, 2004
Messages
14,314
Stupid simple and 100% reliable local privilege escalation that works on Ubuntu, RHEL, Amazon Linux, SUSE, and basically every other mainstream distribution running kernels from 2017 onward.

"It’s a straight-line logic bug in the kernel’s authencesn (AF_ALG) crypto handling that lets any unprivileged local user write controlled bytes into the page cache of a setuid binary (like /usr/bin/su). No races, no offsets, no per-distro tuning — just run the 732-byte Python script and you get a root shell instantly. It even works great as a container escape on shared hosts."

CVE-2026-31431

PoC is public here: https://copy.fail/#exploit
GitHub: https://github.com/theori-io/copy-fail-CVE-2026-31431


I personally tested this on Ubuntu/RHEL servers, worked every time. No fun for multi-tenant/k8 nodes/etc/etc where untrusted users can execute code...and we know virtually everyone can do this.

I ran it against CachyOS on local workstations, does not work.

Bad time for orgs and Insider Threats. This was way too easy.


1777498816858.png
 
Last edited:
Why would they release this to the public? Some people just enjoy burning stuff to the ground?
 
If I read correctly, it was disclosed behind closed doors a month ago to allow time for patch development.

  • 2026-03-23Reported to Linux kernel security team
  • 2026-03-24Initial acknowledgment
  • 2026-03-25Patches proposed and reviewed
  • 2026-04-01Patch committed to mainline
  • 2026-04-22CVE-2026-31431 assigned
  • 2026-04-29Public disclosure

Gonna have to assess this later and hope the users at work don't keep an ear to the ground on this sort of thing.
 
Without looking any deeper than the tweet, I note that apparently you already have to have root access to do this (note the curl command ends in "su".)

I've been noticing for a while now software setup commands that start out with using curl to download and execute a shell script from some random website and this seems insanely stupid.
 
1_rick said:
Without looking any deeper than the tweet, I note that apparently you already have to have root access to do this (note the curl command ends in "su".)

I've been noticing for a while now software setup commands that start out with using curl to download and execute a shell script from some random website and this seems insanely stupid.
Click to expand...
You don't need root to get this working.

From the longer read:
Copy Fail requires only an unprivileged local user account — no network access, no kernel debugging features, no pre-installed primitives. The kernel crypto API (AF_ALG) ships enabled in essentially every mainstream distro's default config, so the entire 2017 → patch window is in play out of the box.
Click to expand...
Step 4: Execute. After all chunks are written, call execve("/usr/bin/su"). The kernel loads the binary from the page cache. The page cache version contains injected shellcode. Because su is setuid-root, the shellcode runs as UID 0. Root.
Click to expand...
 
1_rick said:
Without looking any deeper than the tweet, I note that apparently you already have to have root access to do this (note the curl command ends in "su".)

I've been noticing for a while now software setup commands that start out with using curl to download and execute a shell script from some random website and this seems insanely stupid.
Click to expand...
Can personally confirm you don't need root.
 
westrock2000 said:
Why would they release this to the public? Some people just enjoy burning stuff to the ground?
Click to expand...
Perhaps it was reported, and they reached the disclosure window with none of the big projects replying back and so they released it, to get them to act...
 
westrock2000 said:
Why would they release this to the public? Some people just enjoy burning stuff to the ground?
Click to expand...
Could be just to force the update, some people could have (probably have) been using this for nearly a decade now (has it leave no trace in harddrive and quite stealthy), that something they did found with claude code AI but could have been known by humans for a while. And would have been found by many others now with those tools.

But mostly it is a tool for admins to check if their system is vulnerable or not.
 
Last edited:
4saken said:
Can personally confirm you don't need root.
Click to expand...
What happens if you're not in /etc/sudoers?

In any event I still think the idea of running shell scripts obtained via curl like this is a red flag.
 
1_rick said:
In any event I still think the idea of running shell scripts obtained via curl like this is a red flag.
Click to expand...
The hacker could have wrote it on the machine (it is small) or brought it in many others ways (C binary or all that others you want) ? it is just ~20 lines of codes, small enough to inject this in most things.
 
Last edited:
1_rick said:
What happens if you're not in /etc/sudoers?

In any event I still think the idea of running shell scripts obtained via curl like this is a red flag.
Click to expand...
That's exactly what i tried(not in sudoers). Curl was just the quick easy test example. If python is available anyone can just run the script directly as well. But so much OSS software gets installed via curl these days, just not a great place to be right now.
 
LukeTbk said:
The hacker could have wrote it on the machine (it is small) or brought it in many others ways (C binary or all that others you want) ? it is just ~!20 lines of codes
Click to expand...
Sure...but all you've done is move the problem to "how did the hacker get into my system?"

I'm not denying this is a problem, especially with the other responses I've gotten, but it reminds me of Raymond Chen's phrase about being on the other side of the hatch.

Does this vuln work if you don't pipe the curl into su? If not, it sounds to me like the actual problem is su or maybe the shell loader or something, I'm not really sure.
 
1_rick said:
Sure...but all you've done is move the problem to "how did the hacker get into my system?"
Click to expand...
it can be an legit guest or work account user that do not have sudo right getting them.

1_rick said:
Does this vuln work if you don't pipe the curl into su? If not
Click to expand...
this hack can work on machine that disabled curl/wget yes, you can do it and run it in many different language (python was just an easy one to use, could be in a .exe from a fully compiled language) and bring it on the machine in very different ways, usb keys it is so small you can even just manually write it in VI without bringing it externally.
 
Last edited:
It was fun watching the headlines yesterday as people lost their minds. Yes, this is bad. No, it isn't the end of the world. To be truly dangerous it would have to be an RCE. So a bad guy right now needs an RCE in order to possibly leverage this LPE.

There's also a fully working mitigation that can be applied while you wait on kernel updates. I ran the mitigation against my e-mail server since it's Ubuntu 24.04 and the kernel there is not patched yet. That said I probably didn't have to do that as the module wasn't loaded and that module typically isn't something used by an email server. However, added safety is a good thing.
 
But it is so small even a compiler could inject it, any application ever made in the last 8 years could have it, does not need to be "remote", need to be locally executed true, any binary could have this in it, drivers, libs used by thousands apps, when it is that small and use only standard system calls, who knows.

It seem some things that the example of how use it is particularly relevant, copy fails is just a tool to look for your system vulnability for an attack vector that occur in system ram, but that attack vector can be deployed in anyway code execute on the system that can write on ram, a video game could do it.

You can see it as not too big for your personnal system, but if you need to protect an infracstructure against potential rogue employee that seem quite hard to do.

And we can imagine for some people in charge of those infracstructure the question being for how many years people (CCP, mossad, NSA, North Korea has a good Lazarus group team, who knew that trick for how many years, it took AI just an hour with a simple single prompt) were gaining admin privelege in most Linux device they had access of the world did what with it ? Leaving no trail to be found does not make it easy
 
Last edited:
4saken said:
Just to show it real quick, made a quick capture.
non sudo user, just python script. can just disable/unload the algif_aead module, which is the culprit.

View attachment 800187
Click to expand...
Sadly, all RHEL-like things backed the feature directly into their kernels. But agreed, if you're using SUSE or most Debian style, just prevent the module from loading as an immediate workaround. For RHEL-like (Rocky, Alma, CentOS, Fedora, etc) you can nuke the init point of the feature as a kernel parm on the boot line. But, you'd have to make sure you develop something that persists as new kernels are added to your boot loader. And, does mean a reboot is required.
 
I didn't realize (not sure how I missed it) that the guys who dropped CopyFail did it without proper disclosure. Feels pretty scummy and that they did it like this to push their AI tools with the attention. Apparently, they're in damage control mode now because they're getting bashed pretty hard for doing what they did and rightfully so.

https://nitter.net/brian_pak/status/2050255258098766101

What Brian Pak states is bullshit. There's no way RHEL, Ubuntu, and the like don't patch this quickly if they actually knew about it. There wasn't a single vendor ready for this. If you're on kernel 7.0 you are simply lucky.

Their listed mitigation won't even work on RHEL. RHEL had to release their own mitigation instructions.
 
  • Like
Reactions: ChadD
like this
Vermillion said:
I didn't realize (not sure how I missed it) that the guys who dropped CopyFail did it without proper disclosure. Feels pretty scummy and that they did it like this to push their AI tools with the attention. Apparently, they're in damage control mode now because they're getting bashed pretty hard for doing what they did and rightfully so.

https://nitter.net/brian_pak/status/2050255258098766101

What Brian Pak states is bullshit. There's no way RHEL, Ubuntu, and the like don't patch this quickly if they actually knew about it. There wasn't a single vendor ready for this. If you're on kernel 7.0 you are simply lucky.

Their listed mitigation won't even work on RHEL. RHEL had to release their own mitigation instructions.
Click to expand...
That's what caught my eye. You don't disclose when the majority of targeted platforms don't have patches ready... and you definitely don't release a script that makes life easier for attackers, even if it wouldn't be hard to recreate the file.

Responsible disclosure means waiting a reasonable amount of time. If there's a laggard or two that's one thing, but some of the targets are corporate Linux heavyweights that have no shortage of talent or motivation to get things fixed. Theori sounds like it was just trying to get some extra coverage by disclosing prematurely. Hopefully would-be clients see through this.
 
cjcox said:
Sadly, all RHEL-like things backed the feature directly into their kernels. But agreed, if you're using SUSE or most Debian style, just prevent the module from loading as an immediate workaround. For RHEL-like (Rocky, Alma, CentOS, Fedora, etc) you can nuke the init point of the feature as a kernel parm on the boot line. But, you'd have to make sure you develop something that persists as new kernels are added to your boot loader. And, does mean a reboot is required.
Click to expand...

Wouldn't any new kernels though be patched? I mean the fix has been back ported to basically every supported kernel including the 5 series still found in android things.
 
ChadD said:
Wouldn't any new kernels though be patched? I mean the fix has been back ported to basically every supported kernel including the 5 series still found in android things.
Click to expand...
Right. But, just like the "workaround", a reboot is required. But yes, kernel patches are starting to come out. I just tested Almalinux's "test" kernel (which worked fine). So, not in the standard update channels, not yet.

In enterprise land, you don't go "off script" (for stability reasons). But sure, if "you" are the maintainer (effectively) of every package of your distro (that is, your Linux is unique by definition), you can do whatever you want. Many aren't ready for that level of work or risk though.
 
cjcox said:
Right. But, just like the "workaround", a reboot is required. But yes, kernel patches are starting to come out. I just tested Almalinux's "test" kernel (which worked fine). So, not in the standard update channels, not yet.

In enterprise land, you don't go "off script" (for stability reasons). But sure, if "you" are the maintainer (effectively) of every package of your distro (that is, your Linux is unique by definition), you can do whatever you want. Many aren't ready for that level of work or risk though.
Click to expand...
These things make me happy I'm on the "dark side" now. Definitely not losing sleep, but customers are.
 
cjcox said:
That's the mitigation workaround approach. So, the module is disabled. Which, for most, is going to be fine. In a true patched module/kernel it would "run", just wouldn't be able to trash/takeover su.
Click to expand...
Is there a way to find out if the mitigation is enabled apart from failing to run the script?
 
Mazzspeed said:
Is there a way to find out if the mitigation is enabled apart from failing to run the script?
Click to expand...
You have to check to see the that module is enabled or not. algif_aead
If it's disabled you're running the mitigation. Since KDE Neon is Ubuntu based i'm guessing you're mitigated since Ubuntu hasn't pushed a patch yet. Even worse that they've been under attack.
 
  • Like
Reactions: xx0xx
like this
Vermillion said:
You have to check to see the that module is enabled or not. algif_aead
If it's disabled you're running the mitigation. Since KDE Neon is Ubuntu based i'm guessing you're mitigated since Ubuntu hasn't pushed a patch yet. Even worse that they've been under attack.
Click to expand...
Code: 
lsmod | grep algif_aead
produces no result, so I assume it's disabled?
 
Proof there are some really clever people still left in this world, even AI assisted it shocks me someone just noticed this super obscure bug.

Wonder if anyone will research the group/person behind the "optimization" that caused it.
 
Mazzspeed said:
Code: 
lsmod | grep algif_aead
produces no result, so I assume it's disabled?
Click to expand...
That just means the module isn't currently loaded.
You would have a file like this if it is mitigated: /etc/modprobe.d/disable-algif.conf

The file would have this in it: install algif_aead /bin/false

That will disable the algif_aead module. After your kernel gets updated you just delete the conf file and reboot.
 
longblock454 said:
Proof there are some really clever people still left in this world, even AI assisted it shocks me someone just noticed this super obscure bug.

Wonder if anyone will research the group/person behind the "optimization" that caused it.
Click to expand...
Often times you find bugs (bug or exploit?) through testing on accident.
 
Thing is, you still need local access to the machine to run the exploit.
 
Mazzspeed said:
Thing is, you still need local access to the machine to run the exploit.
Click to expand...
For inside cracks and espionage using standard accounts, this is a very real security threat.
Just because outside bad actors can't utilize it doesn't mean inside bad actors can't.

This "needs local access lulz" nonsense is getting real old.
 
Red Falcon said:
For inside cracks and espionage using standard accounts, this is a very real security threat.
Just because outside bad actors can't utilize it doesn't mean inside bad actors can't.

This "needs local access lulz" nonsense is getting real old.
Click to expand...

Right. So as stated, you still need shell access to run this exploit. So outside of data centers, this exploit is concerning, but of no immediate threat unless you're giving shady people access to your machines.
 
You must log in or register to reply here.
Back
Top