Protecting your VPS from the Copy Fail Linux kernel vulnerability

On April 29, 2026, Xint Code researchers discovered a high-severity local privilege-escalation vulnerability in the Linux kernel which it has since named Copy Fail. The Linux kernel vulnerability and its published exploit allow a local user to gain unauthorized root privileges and affects most major Linux distributions using kernel versions from 2017 to early 2026. This includes Ubuntu, Red Hat, SUSE, AWS Linux, Debian, and Fedora.

Our team at BitLaunch reacted quickly to update all affected VPS server images with patches for the vulnerability. This will ensure that any new VPS server launches are protected from the Copy Fail local privilege escalation exploit. However, it's important to note that users with existing servers should manually apply update their kernel to keep their VPS servers secure.

To that end, we'll explain what Copy Fail is, how it differs from other Linux kernel exploits, how it affects VPSs, and how to fix it.

What is a Linux kernel exploit and what makes Copy Fail different?

Linux kernel exploits take advantage of a vulnerability in the Linux kernel — the core component that manages hardware, memory, and process permissions. Because the kernel needs to run at the highest privilege level (ring 0), successful exploits are often dangerous, with the potential to grant full root access, bypass security modules, or crash the system entirely.

Copy Fail is far from the first Linux kernel exploit researchers have discovered. Some similar local privilege escalation flaws include:

• Dirty COW: A 2016 bug in the kernel's memory management that led to a race condition in copy-on-write memory, allowing attackers to write to read-only files, including removing root passwords or adding new root users. This had a huge impact, but its race condition made it unreliable as an exploit.
• Dirty Pipe: A 2022 Linux kernel exploit that allowed local users to overwrite data in read-only files via the pipe subsystem. Dirty Pipe was more reliable than COW but had constraints on where in a file you could write.
• Netfilter UAF: A 2024 use-after-free vulnerability in net filter's nf_tables that was exploited in the wild for local privilege escalation. It depended on unprivileged user namespaces being enabled to access nf_tables, which is the default on Debian and Ubuntu but not all distros.

What makes Copy Fail different from other Linux kernel vulnerabilities?

Copy Fail is trivial and reliable to exploit, has near-universal scope, is cross-container, and leaves no typical traces because it's in-memory. This makes it especially dangerous in cloud and multi-tenant host environments, particularly when chained with other attacks such as SSH brute-forcing, a malicious CI job, or a container foothold.

How Copy Fail works in practice

Copy Fail (CVE-2026-31431) allows an unprivileged local user to write 4 controlled bytes into the page cache of any readable file, which can then be used to gain root privileges.

The bug was introduced by a 2017 optimization in the kernel’s AEAD userspace crypto interface (algif_aead), which is used by the AF_ALG socket subsystem. The flaw involves the interaction between AF_ALG, splice(), and the authencesn AEAD implementation.

An attacker opens an AF_ALG socket and uses splice() to pass references to file-backed page cache memory directly into the kernel crypto API without copying the data into a separate buffer first. Due to the flawed 2017 optimization, those cached file pages can mistakenly be treated as writable during AEAD processing. A logic error in authencesn then causes a controlled 4-byte overwrite in those pages.

Because the corruption happens only in the page cache, the underlying file on disk is never modified. This means many traditional file integrity monitoring and checksum-based security tools will not detect the attack.

A typical attack would look something like this:

1. The attacker searches for a Linux host or container running a kernel version vulnerable to Copy Fail. This could be reconnaissance on an environment they already have some visibility over, such as a compromised web container or a compromised user account on a multi-tenant host.
2. They execute a small Python script provided by the researchers either as a standard Linux user or a container process.
3. The exploit abuses the AF_ALG and splice() flaw to corrupt the in-memory copy of a setuid binary like /usr/bin/su . This allows the attacker to gain a root shell when it's executed. Now they have full root access and may be able to access sensitive data, deploy ransomware, disable security tooling, and so on.

What's the impact of Copy Fail on VPSs?

VPS servers that use KVM virtualization (like BitLaunch) are only vulnerable to Copy Fail if it's chained with another attack that specifically affects that server. This is because KVM VPSs have their own kernel. However, that doesn't mean you shouldn't be concerned. Copy Fail allows attacks such as the ones below to escalate significantly from limited access to root privileges:

• Compromised SSH credentials: This could occur as a result of a successful brute-force or social engineering attack, malware on the client user's device, and so on. The attacker can use the credentials to log in as a local user and execute the attack.
• Compromised web apps: An attacker could pair Copy Fail with an RCE in WordPress, Node, PHP, etc. that drops them into an unprivileged service account such as www-data. Copy Fail is then used to escalate that access to root.
• Supply chain compromise: A dependency you use is compromised and runs as your app user, using Copy Fail to silently escalate to root.

So, KVM VPSs are less at risk than shared hosting or containers, where a single compromised account from a different customer can be used to attack every other account on the same node. However, allowing your VPS server to operate in an environment where a single security mistake can lead to root access is extremely dangerous, especially if you have multiple users on your VPS host that you don't control.

How to protect yourself from Copy Fail

The most immediate action you should take to protect yourself from Copy Fail is to patch your Linux machines with a kernel built between 2017 and early 2026.

Here's how to do that step-by-step:

1. Disable the algif_aead module using:

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

This will immediately mitigate the attack.

2. Update your distributions kernel. You'll find the Linux kernel update commands for all of the vulnerable distributions BitLaunch and its partners offer below:

sudo apt update && sudo apt upgrade
sudo reboot

sudo dnf update kernel*
sudo reboot

sudo pacman -Syu
sudo reboot

sudo emerge --sync
sudo emerge -u sys-kernel/gentoo-kernel
sudo reboot

sudo zypper refresh && sudo zypper update kernel-default
sudo reboot

slackpkg update
slackpkg upgrade kernel
sudo reboot

After your system reboots, check your kernel version with uname -r or uname -v and cross-reference it with the kernel versions listed in your distribution's security tracker linked above.

If you cannot immediately reboot your server, still run echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf and rmmod algif_aead, since this should mitigate the attack in the meantime by locking AF_ALG socket creation via seccomp or blacklisting the algif_aead module.

Note that the modprobe mitigation does not work on some RHEL-family distros where thealgif_aead module is built into the kernel. You can check this for yourself with grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r). If it returns =y, the mitigation will not work and you should update your kernel as soon as possible.

Conclusion: How we protect our users at BitLaunch

Copy Fail is a serious vulnerability, but for single-tenant KVM VPS users, the risk is manageable with prompt action. The real danger is leaving it unpatched, giving attackers a free path to escalate from less serious compromises to full root.

At BitLaunch, we've already updated all affected Linux VPS server images so that new launches are protected out of the box. If you're running an existing server, we recommend applying the kernel update and rebooting as soon as possible using the steps above.

As always, keeping your kernel up to date is one of the easiest and most effective ways to secure your VPS. If you're a BitLaunch customer and need help or have questions about patching, our support team is available to assist via live chat.