alt Hacker NewsCopy Fail – CVE-2026-31431
Comments
Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines:
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
modprobe algif_aead
This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.
LPE = local privilege escalation
Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!
So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace).
I ran the exploit in rootless Podman, and predictably it doesn't escape the container.
They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine
I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it).
The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.
For mitigation, the page currently basically just says:
> Update your distribution's kernel package to one that includes mainline commit a664bf3d603d
But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now. Some distro kernels may include the fix in other versions, so check for your distribution.
For this crowd, I highly suggest checking out the technical writeup
Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice
Interestingly it fails for me because my `su` isn't world-readable:
$ stat /bin/su
File: /bin/su
Size: 59552 Blocks: 118 IO Block: 59904 regular file
Device: 0,52 Inode: 796854 Links: 1
Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-09-18 13:23:03.117105665 -0500
Modify: 2021-02-13 05:15:56.000000000 -0600
Change: 2023-09-18 13:23:03.119105665 -0500
Birth: 2023-09-18 13:23:03.117105665 -0500
RHEL is listing this as fix deferred for RHEL 8 and 9.
What is "RHEL 14.3"? Was this site a one shot prompt. Quality.
This looks like an extraordinary find at first glance.
Does this mean you can go from a basic web shell from a shared hosting account to root? I can see how that could wreak havoc really quickly.
If this is verified, this is a very big deal. Root access on any shared computer. Additionally do we know what kernel versions and stable versions have the patch?
I'm impressed that such a serious problem popped up out of nowhere.
In my opinion, this mostly affects countries that are still using outdated systems, especially critical systems.
This gives bad actors a direct route to the root. Having an easily accessible root is not funny.
Could this be used to root Android devices? Does Android ship with algif_aead?
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality.
Looking at their source code [1] it starts with this simple line:
import os as g,zlib,socket as s
And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely because zlib is called only once, and os multiple times. As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
Anyway, I could go on. :) Let's just stop fetishizing byte count
[1] https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...
What is the rationale behind naming CVEs and individual domains? Marketing?
For agents, if you are concerned about that, block access to "su" as it is interactive anyway. Not loading it into the memory will block the attack. If you are using AgentSH (https://www.agentsh.org) you can add a rule to block "su" and soon be able to block AF_ALG sockets if you want to further protect things.
Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
Does anyone have a working fix for it?
Quickly dove into this.
1. Yes, it's real.
2. Current chain can write any arbitrary content to any user-readable file (into the page cache).
3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.
4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).
5. The authors say they have other chains (including ones that allow container escapes). I believe them.
6. A mildly de-minified PoC for Alpine with a new payload ELF is at hackerspace[pl]/~q3k/alpine.py . You'll need /bin/ping from iputils. This should be now somewhat reliable on any distro that has a `/bin/sh` and any setuid-and-readable binary (you'll just need to find it on your own).
Better explanation of the write up (still from original exploit author) : https://xint.io/blog/copy-fail-linux-distributions
holy smokes it just rooted my just installed from ISO Ubuntu server
On the downside, I need to push new kernels to all my servers.
On this bright side, does this mean Magisk is coming to all unpatched Android phones?
Works on all my servers. This is terrifying.
Are kernel crypto modules even loaded by default on enterprise distros
I checked it. Very nice efforts made to create it
It does not behave as described on EndeavorOS (arch-based) running kernel 6.19.14-arch1-1. I receive the error:
Password: su: Authentication token manipulation error
I'm guessing this means it's already patched?
So this could be usable in lot of places with Python and Linux running? Not that I have too many Linux devices around. Still, might be handy sometimes on personal devices.
> If your kernel was built between 2017 and the patch
This is why I compile my own kernel. I disable things I don't use. If it's not present it can't hurt you.
> block AF_ALG socket creation via seccomp regardless of patch state.
Likewise I use seccomp to only allow syscalls that are necessary. Everything else is disabled. In the programs I have that need to connect to a backend socket, that is done, and then socket creation is disabled.
> Will you release the full PoC?
> 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.
There is no update available for Ubuntu 24, PoC works and just tried updating.
Despite the copy/images being weird about RHEL 14.3, this seems to work. Wow?
Wow. I tried it on an old testing VM of Ubuntu 24.04 that had not been touched for a few months. Instant root with the bonus that any user that runs "su" gets root too. I updated the VM thinking it would be fixed afterward. Nope.
SUID binaries once again assisted a local privilege escalation attack. This is a major problem that distros can't keep ignoring.
Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)
[dead]
LLM slop detected, tab closed
Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros.
https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred"
https://security-tracker.debian.org/tracker/CVE-2026-31431
https://ubuntu.com/security/CVE-2026-31431
https://www.suse.com/security/cve/CVE-2026-31431.html