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
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?
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.
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.
> 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.
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.
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
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
You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.
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.
Yeah, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions.
It's not good... and surely not "responsible/planned" disclosure.
As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now.
111 comments
[ 3.1 ms ] story [ 87.8 ms ] threadSlightly more readable Python version at https://gist.github.com/grenkoca/b82281a4706e936072979acf54b...
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.
> 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.
Password: su: Authentication token manipulation error
I'm guessing this means it's already patched?
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.
On this bright side, does this mean Magisk is coming to all unpatched Android phones?
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
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...
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
wtf
It's not good... and surely not "responsible/planned" disclosure.
Good lesson in how not to do disclosure.