Copy Fail (CVE-2026-31431) is a trivially exploitable logic bug in Linux, reachable on all major distros released in the last 9 years. A small, portable python script gets root on all platforms.
Posted by Haniro@reddit | sysadmin | View on Reddit | 286 comments
10 lines of python to gain root access on shared machines running Linux kernels from 2017 onward:
https://github.com/theori-io/copy-fail-CVE-2026-31431
Big-Business-2505@reddit
Not saying this isn’t completely horrifying, but I could have really used this as a consultant. Image how many servers I would not have had to rebuild because someone forgot the root password or an internal sysadmin left on bad terms with zero documentation.
autogyrophilia@reddit
Resetting the root password is usually trivial if you have access to the VM volume, and encryption keys if present.
Do environments where people forget the admin password and use exhaustive encryption exist?
mschuster91@reddit
Yes. Homebrew LUKS installation, forget where the paper with the password on it is…
zrad603@reddit
Thats different than a root password
JeanneD4Rk@reddit
Yes, but needed to edit /etc/passwd from a live boot
Gnonthgol@reddit
If you are able to boot the server the disk encryption password needs to be stored in plain text on the server somewhere, for example in the boot partition.
autogyrophilia@reddit
https://support.microsoft.com/en-us/topic/what-s-a-trusted-platform-module-tpm-705f241d-025d-4470-80c5-4feeb24fa1ee
Gnonthgol@reddit
With physical access to the server it is trivial to get the TPM to hand over the decryption keys to the disk.
MrSanford@reddit
You think it's trivial because you've done it in the last 5 years or because you read an article?
Gnonthgol@reddit
Because I have done it to customer servers who claims their TPM is somehow a magic way to secure their data.
MrSanford@reddit
What trivial method did you use?
itishowitisanditbad@reddit
I will say as someone who has done it that its not trivial.
Its fun and I think people should try things and find they're easier than they imagined but TMP exploits are far from trivial.
I don't know any random people with soic clips...
MrSanford@reddit
I agree.
JeanneD4Rk@reddit
At that point just don't use encryption
Gnonthgol@reddit
The only reason to use local disk encryption on servers is compliance. It does not add much security if any.
mschuster91@reddit
You might not have another choice due to external requirements (legal like GDPR/HIPAA/... or contractual like PCI-DSS).
A password to be entered inside the VM is as secure as it gets and prevents data exfiltration in case of theft and data exfiltration in case of a compromised storage solution.
Big-Business-2505@reddit
For a VM, sure. How about on a Hypervisor like ProxMox? Lol. Doable but we chose to build anew and migrate over. This was before PDM so it was painful and slow.
autogyrophilia@reddit
https://vmware.github.io/photon/assets/files/html/3.0/photon_troubleshoot/enabling-systemd-debug.html
Big-Business-2505@reddit
Your credibility just dropped a notch. I mentioned ProxMox and you reply with a link to a VMware article. Similar? yes. Helpful? Not so much.
BortLReynolds@reddit
Ironic
zomiaen@reddit
https://pve.proxmox.com/wiki/Root_Password_Reset
Like u/autogyrophilia said, it's just systemd. You reset it the same way you reset quite literally any modern linux based system.
autogyrophilia@reddit
You know what is great about systemd ? It runs everywhere. This article tells you how to boot to a root shell from the bootloader and it works in all systems using systemd.
Hotshot55@reddit
It's quite literally the same process. If your recommendation as a consultant is to rebuild over a forgotten password, then you probably shouldn't be consulting on anything.
VexingRaven@reddit
Consultant moment tbh
MalletNGrease@reddit
All I read is billable hours
billy_teats@reddit
Your hypervisor doesn’t let you mount data storage to another VM? That either says a lot about your understanding of your hypervisor or about your choice of hypervisor. Both of which are fairly fundamental pieces to administrating systems.
Cley_Faye@reddit
Same? You boot on anything else, which you can do whether it's a remote server with any decent provider or something you have physical access, mount the volume using a valid encryption password you have in a secure place, and change the root password in there manually.
It being called "an hypervisor" doesn't change what it is under the hood.
nethack47@reddit
It has been a few years, but I have had some machines like that because PCI compliance required it.
Machines PXE booted from a read only medium. No root password. We had to keep the VMs alive since they had critical legacy data. Someone screws up the sudo config and we're unable to get back in. User auth breaks, we are locked out.
Not dealing with anything PCI anymore but it look like they may have found ways to make it less horrible. Also, moving card payments to a third party means you don't need to deal with that yourself.
marks-buffalo@reddit
But this method is zero downtime.
mrjamjams66@reddit
Yes but don't ask me how I know
reseph@reddit
"Image"? What?
heinternets@reddit
How many times did people forget the root password and not have sudo?
purplemonkeymad@reddit
Considering that servers where people don't know the password probably don't get patched, you can probably still use it.
420GB@reddit
Uh just boot to single user mode
Big-Business-2505@reddit
Not always an option. And compare that to a 3 second script. Would’ve preferred the script.
Hotshot55@reddit
When do you honestly think it couldn't be an option?
Mrhiddenlotus@reddit
Bro, you're a Linux engineer. LUKS.
zomiaen@reddit
if it were this trivial you wouldn't even bother setting a password for root.
Big-Business-2505@reddit
I’m not talking about passwordless root accounts. This was back in the day where root always existed but documentation usually didn’t. And back then, we ALWAYS set a root password.
zomiaen@reddit
What I'm saying is that if unauthorized priv escalation was easy as a shell script and wasn't immediately fixed there would not be much point in auth at all.
willdeleteacct1year@reddit
I did work at a site with an old sun microsystems / unix based ERP system from the 80s or some shit that was just used to reference old things once and awhile by like 2 people who had access to it.
I had to change the IP to move it onto a new subnet/vlan when rebuilding things and just straight up went to milw0rm.org back in the day when that was the thing and found a unix exploit that got me root access because no one knew the password.
UltraEngine60@reddit
Damn that takes me back.
willdeleteacct1year@reddit
I may or may not have been directly involved to a very minimal amount.
str0ke or SourceX & later on Green, if yall are still around hit me up.
BrockLobster@reddit
Sometimes just being in the same room is cool. I found myself in the same space as a Pixar animator and a developer for QuakeWorld.
GNUr000t@reddit
init=/bin/sh?
plantbasedlivingroom@reddit
Am I the only one that thinks the PoC looks suspicious as fuck? A responsible disclosure, even a public one, never uses minified and or compressed code, and even if. It would be documented and explained very verbosely.
This post and especially the PoC smells like an attack itself
furiouspotato24@reddit
I just tried to search that CVE and came up with nothing. Crazy it would have it's own domain but no official release from a CNA.
yrro@reddit
https://security-tracker.debian.org/tracker/CVE-2026-31431
https://access.redhat.com/security/cve/cve-2026-31431
FarToe1@reddit
Only a 7.8 "Important" - not a critical, from RHEL
dougmc@reddit
Numbers don’t give the whole story.
It doesn’t give remote access, but if somebody already has shell access it gives them root trivially in most cases.
If you have no untrusted local users it’s not a big deal but if you do it’s huge.
fatmanwithabeard@reddit
This is very scary in research computing. Local users everywhere, lots of easy ways to get access to systems, and once root is gained anywhere it's gained everywhere.
The good news is that it's fairly easy to patch. The (very) bad news is that we can't just scream security and reboot. We're going to be fighting uphill on this unless one of the big research leads gets scared enough about it; which they won't if they hear about it from us. (we just did a restart a month ago, and while we've got estimates on most jobs, we just started something interesting that has a range of 10 to 20 weeks, and we trust neither of those numbers)
dougmc@reddit
The good news is that you don't really have to.
The site suggests this --
... as long as the module isn't currently in use, this should work fine. Now, I don't know that this would fix an already exploited system, but if you add this --
it would undo any currently buggered executables in cache, and then you'd be back to normal unless somebody already used this access to add some sort of backdoor.
fatmanwithabeard@reddit
Yeah, we know.
But we can't drop caches without breaking running jobs.
We don't think anyone running current jobs has exploited the system.
We're confident that new jobs will not be able to.
We're much less confident that a user would not be able to exploit an existing job. We can't really validate either way.
A reboot in our system should fix most backdoors. Everything is stateless, and a compromise of the deploy system would require someone on the admin team to be a bad actor, which is always a weak point.
Bleh. We've turned on some off hours paging, just in case something really weird happens (biggest worry would be someone trying to copy certain data off the cluster, which would likely be noticeable. big enough deal that I could roll the entire cluster and just have a week of uncomfortable meetings about it, if I have logs showing it happening.)
Fredouye@reddit
It seems algif_aead is not a module on RHEL 10 :
# cat /etc/redhat-releaseRed Hat Enterprise Linux release 10.1 (Coughlan)# uname -aLinux phoenix.localdomain 6.12.0-124.52.1.el10_1.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 11 20:17:08 EDT 2026 x86_64 GNU/Linux# rmmod algif_aeadrmmod: ERROR: Module algif_aead is builtin.thedanyes@reddit
Even if it were a deeper kernel issue, kernel livepatching has been available in major distros for like a decade now.
JeanneD4Rk@reddit
If you have untrusted users on a machine where something else is important, the problem comes from you not the CVE. It's not 1990 anymore, VMs exist.
Not-the-best-name@reddit
Also, are you saying there's no point to the Linux user permission model for security? A user being able to gain root access with a single line is about as 10/10 as you can get.
pandaro@reddit
So... if that's 10/10, what's RCE?
Not-the-best-name@reddit
It escapes docker...
JeanneD4Rk@reddit
Did I speak about docker? Vms are completely isolated.
Not-the-best-name@reddit
Well, I didn't say it, but it's not 2010 anymore, who still uses VMs?
JeanneD4Rk@reddit
Yeah, tell that to AWS when you ask them how they run Lambda
ycnz@reddit
Luckily nobody's running any kind of overly aggressive automated local agent on their machine.
aten@reddit
unluckily there are lots of exploitable websites on shared servers that can now be used to get root privileges.
VexingRaven@reddit
It's not remotely exploitable or exploitable without existing access, so it's never going to be a 10.0.
furiouspotato24@reddit
I guess I was just too quick lol. Thanks.
hellobeforecrypto@reddit
Does it have a logo and tiktok dance yet?
TurnItOff_OnAgain@reddit
https://www.cve.org/CVERecord?id=CVE-2026-31431
ScoobyGDSTi@reddit
Whoever wrote the description for that should never be allowed near a computer again.
iansaul@reddit
RED ALERT.
hasthisusernamegone@reddit
Are you sure? It does mean changing the bulb.
Sp3eedy@reddit
I agree, looks a bit suspicious, but the exploit is definitely sound. I've tested it on a few VMs and it absolutely works, overwrites the page cache and if you do it on a SUID binary, you can execute arbitrary code as root (i.e. get a root shell).
renegadecanuck@reddit
Claude refused to unravel it for me. I was going to try ChatGPT or Grok, but lost interest before I could do that.
Sp3eedy@reddit
Yeah it's very hit and miss with public LLMs, if you used some of their API models like through Cursor you'd probably get away with it, but in my case I just used an uncensored local LLM because I genuinely cannot be bothered with these annoying guardrails.
renegadecanuck@reddit
Grok is shockingly helpful. I was able to get it to decompress the payload, and then it immediately offered to tell me how to properly compile and execute said payload.
Amazing what happens when you put a nut job in charge of an AI company.
raesene2@reddit
Which model did you try? IME Opus 4.7 is likely to refuse on security things, where 4.6 or Sonnet 4.6 will happily carry on.
renegadecanuck@reddit
That makes sense. It was Opus 4.7. I tried to push and it just got very pissy in its response.
itishowitisanditbad@reddit
Claude went through a whole rundown with me and at the end the chat got locked for safety reasons.
Tricky-Chance3457@reddit
Looks like its made by AI
T_Thriller_T@reddit
Or discovered by it.
I'd love to know how much of these actual 20 something lines I could pull into a whole script, and if the compressed parts are needed and what they say.
But I'm way to lazy to get into that
TurnItOff_OnAgain@reddit
The extended write up linked specifically says AI helped find the exploit.
munkisquisher@reddit
and then they say "see how good it is, you can buy they AI tools we used for this right here, call now, our sales weenies are waiting"
Tricky-Chance3457@reddit
All the tech bros think AI will replace pentesters and security researchers, yet half the vibe coded crap is full of vulnerabilities and there are vulnerabilities in the AI itself.
mineral_minion@reddit
It's LLMs all the way down. "Did your LLM tool create a bug? Buy our LLM tool and we'll find it for you!"
theuniverseisboring@reddit
AI-assisted they claim, but it sounds like most of the work was done by the AI. But that doesn't make it any less real??
OpenGrainAxehandle@reddit
Might have been. Anthropic's Mythos AI is a security nightmare, rampantly finding vulnerabilities in everything its aimed at.
Sp3eedy@reddit
The vulnerability was apparently discovered with the assistance of AI so wouldn't surprise me.
TheDizDude@reddit
it calls out RHEL 14?
Standard-Potential-6@reddit
That was a weird version number. If you look closely it’s el10, aka RHEL 10.
TheDizDude@reddit
oh i agree, but even the github calls out 14.
I mean they fixed it but man ... something feels weirdly AI about all of this. Not that it makes it fake... just odd.
FarToe1@reddit
That is explained, although I don't see why it matters.
JewishTomCruise@reddit
Just that the AI is probably instructed to create a PoC, and so it minified the code as part of that instruction.
dioptase-@reddit
its a shellcode, paste it into claude : In short: this is a classic setuid(0) + execve("/bin/sh") shellcode
Burgergold@reddit
Yeah Ive read that and told myself no way I'm running this on my box to test it haha
petr_bena@reddit
It doesn't contain any virus. I analyzed the code. That "suspicious" payload is a bunch of 4 byte chunks of ELF binary, it's an extremely tiny binary that does this (converted from bin to ASM)
it basically just runs /bin/sh as root
The exploit uses some bug in some cryptographic stuff - now that's outside of my league, I have no idea how that works, but after exploiting that bug it overwrites THE CACHED /usr/bin/su in RAM with that binary I posted.
That means it will seemingly "corrupt" your /usr/bin/sh with that. After you execute it, your /usr/bin/sh will give root to anyone until you clear the cache or reboot the machine. IT WILL NOT corrupt your /usr/bin/su on filesystem (permanently).
So from my perspective it's RELATIVELY harmless - it doesn't cause any permanent damage, it doesn't install any malware or do any network stuff, just demonstrates the concept. And while it "looks fishy" there isn't really any much nicer way to embed a binary blob into python script.
It could have at least warn you what it's going to do though :)
kentrak@reddit
Because in my testing this was super annoying, and after the POC you can't su to another user without just being dropped to root, the following command should help clear it from memory so you don't have to reboot entirely to get normal behavior again.
sync && echo 3 > /proc/sys/vm/drop_cachesThanks for your breakdown of the payload code and note about /usr/bin/sh, it saved me a alot of time tracking down WTF was going on. Unfortunately, testing this on the system I need to mitigate might have actually caused some users to have things run as root if the system tried to spawn a shell for them after I tested? I hope I'm not right about that. That's a major problem of a POC test if true and not noted as something to be aware of.
Frothyleet@reddit
Am I misreading or are you saying you ran exploit POC code on a production server?
kentrak@reddit
TL;DR - Yes, I did a lot of work ahead of time to make sure it was deemed safe enough, and these specific systems were deemed a risk enough that we needed verification of them either being non-affected or that we had a mitigation in place, ASAP.
---
This was one server of multiple in an HA setup, where I could turn it off at will, and if needed could destroy and rebuild with some effort amounting to a few hours of restoring a freshly kickstarted system and our host role applied. These were deemed the only servers of our fleet of hundreds with actual exposure (local delivery mail servers running sendmail that run user .forward and procmail recipes), and the first step of proving you have mitigated the problem is proving you can actually exploit the system and then that your mitigations prevent it.
I had reviewed the exploit code, and the risk of it doing something unreversible or connecting externally is extremely small (the amount of compressed code there is easily dealt with, and as assembly instructions is not credibly large enough to do much).
The risk trade off was of leaving a publicly available server possibly open to exploit by any of many tens of thousands of accounts (of which some are routinely compromised and need to be locked and dealt with), or running the POC code, given what I outlined above, and also given that I could turn that server off at a moments notice without impact.
Under almost any other circumstances, of course running POC exploit code in production wouldn't be something that should be done, but under the constraints present, and given that it had been out and used and talked about for a few hours already, I think there was very minimal risk and a lot to gain. FWIW the Tl:DR is that RHEL 9 variants running sendmail are protected by selinux if running it in enforcing mode (which we are).
yrro@reddit
FYI I think confined services are prevented by SELinux policy from creating AF_ALG socket, but containers and confined user domains are not. And unless you've changed things, your human users are running as unconfined_t anyway...
Ilrkfrlv@reddit
Are you for real ? The usr/bin/su reference is in plain text even in the minified python poc. Lot of work my ass.
petr_bena@reddit
It depends on how these users were "trying to spawn a shell" if it was just a regular login, then their login shell is executed (typically /bin/bash). You wouldn't run to any anomaly unless any of them needed to execute /usr/bin/su
Cyhawk@reddit
Harmless now, what about 24h from now when anyone who can check already did and its changed?
Never trust obfuscated code for any reason.
petr_bena@reddit
The md5sum of code I analyzed (10 lines copied from that github snippet) was 75b009a56079eef56d8b845ffab385eb if you see anything else, then yes it may have been changed.
BuonaparteII@reddit
I think they didn't make it more readable because they wanted to publish as fast as possible. The sha256 should match this tweet:
https://x.com/brian_pak/status/2036173171280486422
gerry_mandy@reddit
I mean, they could have stuck a non-obfuscated copy next to it... especially since the sales pitch states "every Linux distribution shipped since 2017", yet the code posted includes an embedded x86_64 executable, meaning it doesn't immediately work on non-x86_64 Linux systems...
Burgergold@reddit
Might deploy a sandbox to be scrapped after just to see if our edr catch it haha
plantbasedlivingroom@reddit
Additionally, a CVSS of 7.8, which most still consider "moderate" does not really justifies a name, or logo for an exploit. You do that with CVSS of 9.5 and greater
intorio@reddit
If an LPE requires you to already have a shell on the system, it isn't going to go much higher than a score of 8. You have to do site specific adjustments.
If you are running a web server, not really worrying.
If you are running an HPC center with thousands of users logging in by SSH, giant concern!
NoPriorThreat@reddit
yep, I am scientist using several HPC clusters and I got several mails in span of few hours that they are closing access to clusters due to this LPE.
bbbbbthatsfivebees@reddit
Yeah, was just about to say the same thing.
This is a REALLY bad exploit if you're a sysop running anything where people have shell access. But because it's a privesc and not a full RCE vulnerability it's not really going to get more than an 8, 8.5 at the max. Already having shell access to a machine takes this down from a 10.
But as a Linux sysop where we DO have users logging in via SSH, this is as good as a 10.0 as you're going to get. It's bad, I tested in a few VMs and this works 100% reliably up to Ubuntu Server 24.04LTS patched a few weeks ago. I'd imagine this is currently a nightmare for sysops that run university computing where SSH access is provided on large clusters/anything involving shared infra.
fatmanwithabeard@reddit
it's not thousands, but it's not 10, either.
from what I can tell, new sessions seem to be fixed, but I can't just kill all the jobs and reboot (there are easy fixes).
I'm going to need another crate of antacids.
dougmc@reddit
It's not really a matter of "justify" -- it's more a matter of "this is somebody's 15 minutes of fame, so how hard are they going to push it?"
And when they've got a name, a logo, a domain, a website, a github repo, a slick write-up with video of parallel pwning in real time, well ... clearly, they're going to go hard.
greg_kennedy@reddit
I do still remember Holey Beep, which was playing with these grandiose CVE reveals by doing its own goofy site / name combo - https://holeybeep.ninja/
dougmc@reddit
Now I know who started this craze! /s
Frothyleet@reddit
I mean there's a lot of survivorship bias. Pretty much every major exploit is going to get a nickname. You don't remember an unquantifiable but surely large number of exploits of all sorts of impact that tried to get nickname traction, but weren't memorable.
Which is to say, major exploits will invariably get nicknames, but that doesn't mean you can attribute the nicknaming to them being memorable (necessarily).
PaulTheMerc@reddit
Making it sound better so they can throw it on a resume is my guess?
BemusedBengal@reddit
They could have sold that exploit for at least 100k instead of disclosing it, so I'm ok with them trying to capitalize on the disclosure.
F0rkbombz@reddit
Honestly, if it does what they claim then let them have the name and logo.
oskark-rd@reddit
Red Hat and Ubuntu have just revised their assessments from moderate to high/important, seems that they misunderstood the severity initially.
bbbbbthatsfivebees@reddit
I took a look at this and dissected it today -- The PoC is sound and the exploit is pretty bad and still valid.
My best guess is that they did this specifically to get the "Exploit in 10 lines of Python" figure rather than posting the full un-minified PoC, which is likely 30-40 lines fully expanded. 10 just sounds like a good number, something that people can wrap their heads around, and something that's going to generate headlines like "Hacker finds way to break all Linux machines with 10 lines of code" or something similar to maximize the publicity figure.
mikeblas@reddit
It's like a code obfuscation contest entry.
HighRelevancy@reddit
Given that one of the tells of compromise is pulling in large external tools full of binary code, executing from a small text script is pretty cool.
Ramast@reddit
here is my attempt to make it more readable
https://pastebin.com/iW8BRrdX
tested against my up to date kernel and it gave root access (scary). the script permanently modify your "su" command so take back up first
cp -a /usr/bin/su /usr/bin/su~if you will test it.Own_Back_2038@reddit
No it doesn’t, it overwrites the binary in the page cache, the file on disk stays the same
Ramast@reddit
Yes, you are correct
After doing
echo 3 > /proc/sys/vm/drop_cachesto flush the cache, /usr/bin/su returned back to its original form.serg06@reddit
Anything to get to "10 lines" I guess? It seems like this dude's just fishing for attention.
DNSGeek@reddit
We dissected the payload internally. It overwrites the su header (really, it could be any SUID binary) with a payload that simply execs /bin/sh, which will be root because of the suid and because the su checks did not run.
IdealParking4462@reddit
Hard to say intentions, but I do wonder if they thought a small snippet of code would look more impressive. I agree it reduces credibility.
pangapingus@reddit
On Debian:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
To not do anything but check, if this is =m you're likely fine-ish for now:
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
i.e. CONFIG_CRYPTO_USER_API_AEAD=m (module, as long as it's not loaded)
yrro@reddit
It's built-in in RHEL and Fedora. :'(
Far-Whereas-5365@reddit
On RHEL you can disable it via kernel flag: initcall_blacklist=algif_aead_init
Edit GRUB_CMDLINE_LINUX in /etc/default/grub , then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot
put_it_in_the_air@reddit
This is not a viable remediation in my testing and the vulnerability remains exploitable.
yrro@reddit
Oh that's awesome thanks!
pangapingus@reddit
Yikes, one of the many reasons I love daily driving gramps OS, anything in their security repos yet?
yrro@reddit
No and their CVE database says fix deferred. I assume this will change once they realise this is more serious than first assumed.
oskark-rd@reddit
They've just changed it.
yrro@reddit
phew
Junior-Spring-5557@reddit
Thanks for sharing.
SentinalOne at https://www.sentinelone.com/vulnerability-database/cve-2026-31431/#Workarounds says to do this, but it's not enough, at least on Ubuntu 24. If someone at SentinalOne could fix, that'd be great.
Wasn't good enough to block this:
sleemanj@reddit
You want
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.confBlacklist does not do what the poster of that thinks it does.
pangapingus@reddit
Yea I'm all for building each other up to chase the right solution here and I was fairly sure blacklist was insufficient, thank you for the deep dive, I erred on the /bin/false route feeling brute-ish at first but I knew it'd work at least
Hotshot55@reddit
What is the benefit of the
install ... /bin/falseimplementation for this case?DerfK@reddit
lsmod | grep algif_aeadto see if the module is already loaded, in which casermmod algif_aeadwill attempt to unload it. Then the modprobe trick to prevent it from getting loaded back in.pangapingus@reddit
Good add! Just finished checking my fleets in the meantime but yea this is good it it's already loaded
Murky-Office6726@reddit
Has anyone proved it could be used to escape containers even if for a local docker setup?
yrro@reddit
If you have two containainers with a common base layer, then one of them can write to the base layer's
libc.so.6file, affecting processes in the other.If you have bind-mounted files in from the host, yikes! I'm sure glad that exposing NVIDIA GPUs to containers requires you do do this!!
PaulTheMerc@reddit
complete amateur learning:
If I understand this right, it means this exploit allows you to use a container you have access to, to escalate your privileges, AND gives you access to other containers that are running on the same machine, something containers are designed to prevent?
Say, on a cloud provider?
yrro@reddit
Yes, although you wouldn't want a cloud provider that only relies on Kernel DAC and MAC to protect themselves & other tenants from a hostile tenant.
PaulTheMerc@reddit
Thank you.
masheduppotato@reddit
Cross-container impact. The page cache is shared across all processes on a system, including across container boundaries. Copy Fail is not just a local privilege escalation. It is a container escape primitive and a Kubernetes node compromise vector (Part 2).
Source: https://xint.io/blog/copy-fail-linux-distributions
cofe-table@reddit
Could it be used from adb shell - anyone tried? As I saw checked the apps (termux), but adb shell usually have better privileges in selinux...
Burgergold@reddit
Wth is RHEL 14.3?
daschande@reddit
I'll sell you a cert for it for $300.
Fredouye@reddit
GCC version used to compile the RHEL 10 kernel :
Linux version 6.12.0-124.52.1.el10_1.x86_64 (mockbuild@5dae21272fa54b7bbf81be69676a1c15) (gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), GNU ld version 2.41-58.el10_1.2) #1 SMP PREEMPT_DYNAMIC Sat Apr 11 20:17:08 EDT 2026
stilldebugging@reddit
Its a message from the future
meisterlala@reddit
AI halucinations
ChaoPope@reddit
Vuln testing from the future!
calc76@reddit
Apparently a typo, the kernel mentioned is for RHEL 10.1
Alternative-Spread10@reddit
Waiting official Red Hat correction but here is an help....
On RHEL family (not module but compiled) current unofficial workaround (Tested ok on RHEL8, 9 and 10) with a prvileged user (root or sudo) :
1 - grubby --update-kernel ALL --args="initcall_blacklist=algif_aead_init"
2 - reboot
Note : plane it for production server to make a reboot into a window time (time to reboot)
After it will be safe for this CVE.
Good luck...
FarToe1@reddit
Wonder how many government funded teams around the world are about to lose one of their toys thanks to this disclosure?
BatemansChainsaw@reddit
good
neo-raver@reddit
So, if I’m understanding this right, if the kernel module
algif_aeadisn’t loaded, this exploit can’t be carried out?Deiskos@reddit
Tried it on rocky linux 9.6 vm and I got a root shell using the C version from u/wesmarpl,
lsmod | grep algif_aeadshows nothing. Unless I did something wrong it seems that it works without the module loaded.robreddity@reddit
You likely have it built into your kernel target than as a module. I did.
dustojnikhummer@reddit
It seems like that is the case for RHEL/Cent based distros
robreddity@reddit
I'm having difficulty removing it to a module, or disabling it at all, as LUKS needs it for my root volume. I don't understand why LUKS can't be happy with it as a module in the initrd.
haHAArambe@reddit
You can blacklist it in GRUB on RHEL systems, in case you're still looking for a mitigation.
robreddity@reddit
I patched and rebuilt my kernel with the fix.
haHAArambe@reddit
Also possible, but for anyone else looking into mitigating this issue until upstream kernel's have the relevant fixes, you can blacklist algif_aead_init using grubby.
Simple to do with ansible, we're mitigating the issue on all our systems (1000+ vm's) in a few hours using this method.
ifq29311@reddit
tried on Ubuntu 24
there was no algif_aead module loaded before executing the exploit demo
there was one loaded after.
so i think its loaded automatically when something opens the af_alg socket
Gnonthgol@reddit
A lot of kernels have this module as a built-in rather then a module. In which case you are vulnerable. In addition it is possible for an attacker to load the module by using the functionality it provides, even as an unprivileged user. So you need to blacklist the module to prevent this from happening.
solracarevir@reddit
I read other comment that implied that, but I need confirmation
BemusedBengal@reddit
This is what I get for not browsing Reddit at work...
I'm going to pretend I didn't see this until tomorrow morning.
haHAArambe@reddit
A very irresponsible thing to do, and if I were your employer I'd have a strong opinion about this.
BemusedBengal@reddit
I was being a little bit facetious, but it's going to take me several days to patch all of our systems. 12 hours won't make a difference.
haHAArambe@reddit
Unless you build your own kernel you can simply blacklist the affected module for now until the patch is available in your relevant upstream repo.
We're using ansible to check affected systems and place the relevant configs to disable modules where necessary, all in all it's a couple of hours of work. (1000+ vm's)
twelfthmoose@reddit
Good thing I still have some legacy servers running Ubuntu 1404!
zero_cool09@reddit
I literally looked at my list of servers and said the same, mostly Ubuntu 14.04 lol.
Crihexe@reddit
I was a bit concerned about the fate of my ctf platform with RCE challenges, so I had fun making this super size-(sl)optimized Linux x86_64 no-libc ELF build of the original Python PoC for research/reproduction purposes after (hopefully) having patched it.
Current size: 801 bytes on GCC 13.3.0 / Ubuntu 24.04.
Repo: https://github.com/Crihexe/copy-fail-tiny-elf-CVE-2026-31431
Crihexe@reddit
UPDATE: 756 bytes now!
Xzenor@reddit
So much for responsible disclosure.
What an dick move to just throw this out there.
Gnonthgol@reddit
The kernel patch is over a month old at this point, but it was not tagged as a security patch. The CVE got published a week ago. It is certainly a unique disclosure path, which does not seam to have worked correctly. A lot of distributions still do not have a patch out which is very bad. Normally you would at least expect the issue to be disclosed fully to the distribution vendors as well as major hosting services in order for them to be ready with the patches. I do not know what happened here but it might be that some distributions did not take this serious enough, shown by the low score some of them gave it.
errindel@reddit
I dunno. They worked for a kernel fix. I'm not sure why it's taken RH and Canonical 5 weeks to issue new packages with the fix, but that's probably too long for something this easy to use.
Confident-Plane-2579@reddit
My friend executed PoC code on ARM computer. However it failed. This attack is only x86 ?
Gnonthgol@reddit
The POC is for x86_64, but the attack also applies to ARM. It is trivial to recompile the bytecode in the POC to ARM code.
Veyron180@reddit
The attack is also for ARM, but it needs different bytecode, so you need something like this: https://github.com/theori-io/copy-fail-CVE-2026-31431/pull/25
Drunken_Economist@reddit
wait what
TheNewl0gic@reddit
RHEL doesnt seem to have a fix yet.
IngwiePhoenix@reddit
The exploit shared on the site installs a x86_64 version of
su- which does not work on my aarch64 xDEither way, the fact that it even could overwrite that particular binary is insane. Pretty scary, all things considered.
On the other hand, this is PERFECT for breaking into corporate black boxes that you rent. Think Reddoxx systems or alike. Heck, someone should try this on ESXi and see if it works - iirc, they use a Linux kernel (albeit modded) - would love to know if it works there too x)
Veyron180@reddit
I got the exploit to work now on aarch64 with https://github.com/theori-io/copy-fail-CVE-2026-31431/pull/25
ifq29311@reddit
esxi is custom kernel, not linux based. linux based hypervisor has been discontinued like 15 years ago. also, no python.
NuAngelDOTnet@reddit
CVSS of 7.8. Definitely high, but no sense in causing panic, especially when patches aren't even out for most distros yet.
T_Thriller_T@reddit
I think getting it over 8 would be hard.
Needs python and likely established, local access.
I don't like it, but it's not the worst - albeit Linux without python seems unlikely.
oskark-rd@reddit
It doesn't need python. They wrote the exploit in Python, but you could do this in any language, as long as you can do system calls. But yeah, it needs local access.
haHAArambe@reddit
This exactly, half the comments here do not understand that their specific PoC is just a showcase, their code not running out of the box is irrelevant, a bad actor with sufficient knowledge will find a way to exploit this.
picklednull@reddit
? All mainstream OS’es except Windows have Python built-in…
thunderbird32@reddit
Yeah, I think even a 'minimal' install of RHEL 10 has Python installed by default.
gumbrilla@reddit
Yeah, I nearly thought I'd have a day in front of me, then I remembered I have hundreds of linux servers on AWS. You get on one of those machines, you're sudo already.
Elavia_@reddit
Elaborate?
gumbrilla@reddit
EC2, you are dumped in as either user ubuntu (Ubuntu) or ec2-user (Amazon Linux) with full sudo rights, no password. If you want to become root you can simply su.
The security is built on getting to the machine, so SSM, roles & polices within AWS.
Elavia_@reddit
There is no sudo password by default because those users are authenticated using RSA keys. How you alter this or configure any other users is up to you, as per the shared responsibility model.
If the attacker has access to your AWS console and SSM (which, by the way, should be completely disabled unless you have proper configurations in place) you are royally screwed already.
gumbrilla@reddit
Yeah, we only allow non admins to operate any where near productiin on a time limited basis, with ticket and approvals, using conditional management SSO authentication, and entitlement management with auto timed revoke, and even then it's via a dynamic fargate instance that they can trigger within their window. They never touch a production instance.
ycnz@reddit
Yeah, it's totally fine, unless you happen to have any linux machines with users you don't want to have root access, or agents you don't want to have root access..
Junior-Spring-5557@reddit
> especially when patches aren't even out for most distros yet.
Maybe you meant to say this differently; but if exploit code is out, but distros don't have a patch, that's worrying.
NuAngelDOTnet@reddit
Well, if you run "pro fix CVE-2026-31431" in Ubuntu 24.04.4 LTS, it says "Sorry, no fix is available yet." If Ubuntu hasn't released one, many mainstream OS's are still waiting.
Apachez@reddit
RedHat seems to downplay this to 5.5:
https://www.cvedetails.com/cve/CVE-2026-31431/
Burgergold@reddit
High would probably be at least 7.5 no?
https://bugzilla.redhat.com/show_bug.cgi?id=2460538
wise0wl@reddit
JUST FYI, if you run this on a system to test it likely will corrupt your page cache so calling `su` in the future you won't have your environment and things won't work right. Run it on a system you don't care about to test, or if you do run it on something you care about you have to drop the kernel page cache after to make `su` right correctly again.
```
echo 1> /proc/sys/vm/drop_caches
```
haHAArambe@reddit
Or just reboot the system, anybody running this on a system they own shouldn't be running it on a system that can't just take a reboot.
ronchaine@reddit
I tried to run the POC with 4 different systems, some of them running pretty old kernels (still newer than 2017) and none of them were affected. The website is overselling it by a lot.
6.12.33-0-lts and 6.12.33-0-virt (Alpine) 6.6.33-0-generic (Chimera) 6.17.0.1017-oem (Ubuntu 24.04, explicitly stated as affected)
haHAArambe@reddit
Like you said the POC is just a showcase of what is possible, somebody with in depth knowledge will be able to build their own exploit.
As long as your kernel is built after 2017 and includes the commit they mentioned, it IS affected.
ZAFJB@reddit
From: https://www.theregister.com/2026/04/30/linux_cryptographic_code_flaw/
Debian: https://security-tracker.debian.org/tracker/CVE-2026-31431
Ubuntu: https://ubuntu.com/security/CVE-2026-31431
Suse: https://www.suse.com/security/cve/CVE-2026-31431.html
HN: https://news.ycombinator.com/item?id=47953340
GitHub: https://github.com/advisories/GHSA-2274-3hgr-wxv6
wesmarpl@reddit
Static-compiled working version, tested on a fully updated WSL (30 KB):
http://kvc.pl/CVE-2026-31431.zip
It probably works on other systems as well; it doesn't require Python and has no dependencies
po_stulate@reddit
Here's the source file:
Zockling@reddit
None of my kernels are affected. So distro kernels are not only slow and bloated, but also have a larger attack surface? Who knew!
Akeshi@reddit
But with all the magic hidden in a zlib-compressed string decompressed on the fly
73tada@reddit
Will this work on Android via Termux?
CrazyKilla15@reddit
No. Androids security model with SELinux 1) doesnt expose AF_ALG sockets to apps and 2) doesnt expose setuid binaries to apps.
dulange@reddit
Termux runs isolated and brings its own user land binaries non of which have uid root and have the setuid bit set, so it doesn’t look possible. I wonder if it works in an adb shell but I can’t find a setuid binary there either.
nullbyte420@reddit
Oh shit. Does selinux protect against this?
yrro@reddit
Depends on your policy & what domain your processes are confined by. Out of the box on Fedora:
allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write }; allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write }; allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write }; allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write }; allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
... so most services won't be able to create such a socket; however confined users and containers can, and of course unconfined users are expected to be able to do anything.
Xzenor@reddit
Updating all our linux systems now.. However, Rocky Linux 10 seems to lag behind for some reason and doesn't have a fix yet
Moocha@reddit
For what it's worth, this was patched in kernel 7.0. Look for
Fixes: 72548b093ee3in the changelog. The patch fixing the vulnerability is this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5From what I can tell, none of the currently released LTS kernel versions fix this yet (there are algif_aead changes but they don't seem to interrupt the chain necessary to trrigger this) -- but I may be wrong, we'll have to see.
imtoowhiteandnerdy@reddit
I get the following on
Python 3.9.6(Running Fedora Core 34):nullbyte420@reddit
It's not a python bug, you're just running an ancient version. It's a kernel bug.
imtoowhiteandnerdy@reddit
Yep yep, I wasn't attempting to say otherwise, just pointing out the POC code isn't as portable as it appears. Obviously running the code in a venv wouldn't be too difficult.
NoPriorThreat@reddit
there are already C codes posted in this threads which can do it instead of python
PissTitsAndBush@reddit
I’ve got a couple of linux boxes that I’ve inherited, but not super clued up on everything (basically a junior!) yet until the new Linux guy gets hired.
There all internally locked with restricted access to myself and one other colleague. ONE of them is externally facing but has a firewall etc in front of it.
Anyone able to throw a suggestion out as to if I’m going to work to fix it now or is it alright to wait until tomorrow before I touch it?
ycnz@reddit
Go easy on the risk monitor folks - the distro people have badly fucked the assessment here.
T_Thriller_T@reddit
The easiest but stupid answer is: throw python off.
That's at least a real, full mitigation if possible. I'm somewhat sure it won't be possible with most distros.
For the externally facing one, if you have logging / monitoring and an alerting option, you could try to grab python commands being run and alert if anything close to this shows up.
But with realistic honesty, the advice you already received is solid. The boxes are locked, if someone gets in and can run Python locally there, anyhow, is a pretty big security issue.
HighRelevancy@reddit
There are layers to how bad this advice is.
Hotshot55@reddit
Enjoy breaking all of your system tooling.
dougmc@reddit
Definitely stupid, because
Runnergeek@reddit
Please don’t provide security advice when you clearly don’t know what you are talking about
CrazyKilla15@reddit
Python is in no way required for the exploit, its just simple, essentially every single distro has it, and requires no outside dependencies. Anyone able to run code can trigger the exploit.
Itz_Raj69_@reddit
Unless someone you don't trust has SSH or code running ability on it, no need to worry today
PissTitsAndBush@reddit
Lovely, thank you.
Junior-Spring-5557@reddit
Ubuntu's page at https://ubuntu.com/security/CVE-2026-31431 has a truncated description. It's been this way for hours. I have no way to tell them to fix their goram page.
spin81@reddit
The important parts are not truncated.
i_likebeefjerky@reddit
Check if you have the module loaded before you go rebooting and taking downtime:
lsmod | grep algif_aead
BemusedBengal@reddit
An attacker could unload the module after gaining root
HighRelevancy@reddit
If you assume you've already been exploited there's nothing you can do anyway. Are you restoring from clean backups every single morning?
BemusedBengal@reddit
I was arguing against the idea that you could assume you weren't exploited if the module wasn't loaded when you check.
spin81@reddit
The idea was that if you had not been exploited yet, you could assume you were not vulnerable if the module was not loaded.
HighRelevancy@reddit
They weren't asking how to check for exploitation, they were asking about exploitability.
spin81@reddit
Sir are you being nuanced and reasonable on Reddit? I think you'll find that this is illegal to do in these parts
intorio@reddit
If you are running a Redhat variant, the code is compiled directly into the kernel and will not show up in the module list. There is no patch yet.
i_likebeefjerky@reddit
Ok, so it is baked into the kernel and always on? The big issue for me is scheduling downtime for reboots. If I could at least prove its not exploitable right now, that buys a lot of time for reboots.
solracarevir@reddit
If the module is not loaded it can’t be exploited?
Standard-Potential-6@reddit
and if the module isn’t built into the kernel.
03263@reddit
Wish somebody would have done a real write-up instead of this LLM generated crap. Did a human even discover the bug?
Swaggo420Ballz@reddit
The whole company is AI focused. Their homepage specifically sells AI products.
tjbecker@reddit
https://xint.io/blog/copy-fail-linux-distributions#the-demo-5
real writeup, and answers your question about discovery
03263@reddit
Mazeltov
OpenSourcePenguin@reddit
The unminimized code is just minimized code formatted.
MSgtGunny@reddit
Buddy, that gist is not unminified. It’s just minified with white space. Post the original script with actual well written and easy to understand variable and function names along with comments.
Gist for reference https://gist.github.com/grenkoca/b82281a4706e936072979acf54b608df
icebalm@reddit
Doesn't work on my arch system.
yenshe@reddit
the script is for x86
Haniro@reddit (OP)
I haven’t validated it on arch (which I use) so I’m glad you checked
andonevriis@reddit
Hack the box and TryHackMe just became a lot easier 😬
ifq29311@reddit
this is kinda interesting from a different perspective. the fix is to basically remove the offending code and revert to previous behavior (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d) and the commit says theres no benefit for the change to even exist, so theres a chance this bug was introduced on purpose
Lower_Fan@reddit
Imagine this is how we discover a 10 year old backdoor into any Linux box ever.
dustojnikhummer@reddit
xz utils backdoor part 2, kernel boogaloo?
Xzenor@reddit
Thanks
kudikarasavasa@reddit
Does this also affect docker containers that run with a specific uid/gid? Can a compromised container run code on the host?
Smooth-Zucchini4923@reddit
Ugh. A CVE with a logo and a domain name.
I will observe that sensible container designs do not mount host binaries into the container.
SirHaxalot@reddit
I haven’t read too much into it but I think the implication is that if it can access the file inside the container it will be able to poison all the copies that are backed by the same physical file, which could be in a shared image layer. Container boundaries probably only means that you can move laterally to other containers, provided that you can poison a file in a shared layer, and also manage to get it executed in another container.
I don’t see how this could be used to infiltrate the host, assuming that the container isn’t privileged or subject to another exploit that would require root in the container to escape. Also assuming that there isn’t something that would deduplicate files in the page cache bit I don’t think that’s a thing. Or if I’m misunderstanding something about the exploit (very possible at this point)
straighttothemoon@reddit
Yes, you're exactly right from my findings. For example the POC modifies the
subinary, and it's easy to see that containers that share the same image (or at least the same image layer that contains/bin/su) can be compromised from another container. https://i.imgur.com/1NnfJ4D.pngSmooth-Zucchini4923@reddit
That's a fair point. It could also be used to achieve persistence inside a container whose filesystem is intended to be non writable.
yrro@reddit
sighs deeply
ChrisTX4@reddit
None of those should be problematic, as the exploit needs a suid-root binary and those are mounted
nosuid:Mounting such a binary in a container shouldn't normally be happening.
CrazyKilla15@reddit
Sure, but thats only from the containers perspective. Its still the same file and kernel cache, so the next time the host where it is setuid runs it(absent memory pressure), attacker code runs, and could then trivially exploit directly or open a channel into the container.
And it would not be weird for the host to run
nvidia-smi, for example. Perhaps automatically to monitor usage details?yrro@reddit
While these are not setuid, if root later runs them then won't root unwittingly execute the attacker's code?
ChrisTX4@reddit
From the description of the exploit I would understand it as such that the cached copy of any binary can be injected with shellcode. They use setuid-root binaries because the injected shellcode then runs as root - but that's all they need the setuid for.
So, for the exploitation path in an LPE, this wouldn't work. However, if an attacker was to inject different shellcode, like a malware downloader, this should corrupt the copy in the entire hosts memory and would run upon invocation of any of those binaries. Alas, what you've brought up is probably correct.
ehhthing@reddit
They mention K8s escape which they haven't released the blog post for yet.
I assume the exploit will be different from the one they described initially but it would still work to escape from containers.
The primitive underlying is still out-of-bounds write, so you can still likely exploit it as a normal kernel vulnerability with a lot more plumbing (and likely would not work across distros).
antiduh@reddit
If ever a bug deserves a logo and a name, this is one of them.
DeathScythe676@reddit
I'm tired boss. . . .
wesmarpl@reddit
Statically compiled working version, tested on fully updated WSL (30KB):
kvc.pl/CVE-2026-31431.zip
wesmarpl@reddit
Static-compiled working version, tested on a fully updated WSL (30 KB):
http://kvc.pl/CVE-2026-31431.zip
usa_reddit@reddit
It works on Linux pop-os 6.17.9-76061709-generic, not good.
RBeck@reddit
This would be a big deal if we didn't give everyone sudo already anyway.
/s
Sp3eedy@reddit
This is really bad. This is just like the critical dirty pipe vulnerability we've had a couple of years ago. Doesn't look like Debian has a patch for it yet either.
PissTitsAndBush@reddit
Looks like they have for forky & sid but not bullseye, bookworm & trixie and I’ve just learned one of the boxes I inherited is bookworm
great
Sp3eedy@reddit
Just seen that on the page:
> Yes — it's on this page. We held it for a month while distros prepared patches; the major builds are out as of this writing.
I'm using Trixie though and for some reason I don't have a patch for it available (and I did test it on my machine and it absolutely works), so not sure what's going on.
CrazyKilla15@reddit
Yes. And then debian didnt properly patch it. This is normal for debian and other distros using special outdated forks of upstream kernels and trying to only backport "important" and "security" fixes because "stability". This is a manual process so a lot of things fall through their cracks, get lost track of, ignored because someone decided they "werent important enough" and then turns out oops they were, etc.
Sp3eedy@reddit
That makes sense, thanks a lot for the insight.
Effective_Ad_2455@reddit
Time to pump my HTB stats