Copy Fail vulnerability allows any Linux user to gain root access

On April 29, 2026, a Copy Fail vulnerability was discovered, it was assigned the identifier CVE-2026-31431. This vulnerability affects all Linux distributions built between 2017 and April 2026.

This vulnerability allows any Linux user to gain root access.

Details

The issue lies in the kernel cryptographic subsystem, specifically the authencesn template and the algif_aead module, which provides access to AEAD encryption via the AF_ALG socket interface.

This vulnerability allows a standard user to write just 4 bytes to the page cache (RAM cache) of any readable file without affecting the file itself on disk. This can be accomplished with a combination of AF_ALG and the splice() system call — standard Linux mechanisms available to all users without exception. The error occurs when authencesn writes data beyond the buffer's bounds during decryption, entering cache pages passed via splice().

The attacker selects a setuid binary, a program that automatically gains administrator privileges when launched (e.g., /usr/bin/su) and replaces four bytes in its cached copy. After this, the program grants root access instead of prompting for a password.

The file on disk remains unchanged. Integrity monitoring systems (AIDE, sha256sum) that compare the file with a reference file detect nothing. There are virtually no traces of the attack: the modified page lives only in RAM and disappears after a reboot or cache clearing.

Who is vulnerable?

All Linux distributions built between 2017 and April 2026 are vulnerable. According to the study, the same exploit works on all architectures without the need for specific modifications.

Multi-user servers, cloud services containing custom code, containers, Kubernetes, and CI runners are at the greatest risk, due to the ability of users to host their own code on the server.

The presence of the vulnerability can be detected with a Python script:

python3 -c 'import socket;s=socket.socket(38,5,0);s.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));print("vulnerable");s.close()' 2>/dev/null || echo "Not vulnerable / blocked"

How to fix

In the operating system

The most important thing to do is update the kernel with the patch from commit a664bf3, as this fix removes in-place optimizations in the algif_aead module. It is also highly recommended to monitor kernel updates on the Red Hat and Ubuntu websites.

As a temporary workaround, until a kernel update is released, the algif_aead module can be disabled:

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

cp -a /boot/grub2/grub.cfg /boot/grub2/grub.cfg_BACK
grub2-mkconfig -o /boot/grub2/grub.cfg

grep initcall_blacklist /proc/cmdline

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

grep initcall_blacklist /proc/cmdline

If containers are used on the server, disable the ability to create AF_ALG sockets via seccomp. Disabling this module should not affect common tasks, including LUKS, IPsec, and OpenSSL without the afalg engine.

If you are using WSL and/or WSL2, manually install the patch and manually rebuild the kernel.

ispmanager 6

In ispmanager 6, as a temporary solution, you can disable Shell access for all users and reset their SSH sessions (user sessions of the built-in Shell client will not be reset!):

while IFS= read -r line; do /usr/local/mgr5/sbin/mgrctl -m ispmgr user.edit elid=$line limit_shell=off sok=ok; pkill -u $line sshd; done < <(/usr/local/mgr5/sbin/mgrctl -m ispmgr user | awk '{print $1}' | cut -c 6-)