Information about the Copy Fail vulnerability, which allows attackers to gain root access on virtually any modern Linux distribution

A working exploit written in Python (later released in other programming languages as well) consists of about ten lines of code and uses standard system calls that are indistinguishable from normal system activity. We explain what the CVE-2026-31431 vulnerability, unofficially named as Copy Fail and published on April 29, is. We also have some advice on its mitigation and detection.

Presumably, the root of the problem is commit 72548b093ee3, added to the Linux kernel in 2017. It introduced support for in-place operations for AEAD encryption in the algif_aead module, which led to a buffer handling error. Thus, the vulnerability affects kernels released between 2017 and 2026. Both outdated server configurations and modern distributions are at risk: Ubuntu, RHEL, certain WSL2 builds, and other systems with the algif_aead module installed.

The nature of the vulnerability and how the exploit works

During operation, the authencesn cryptographic algorithm uses a portion of allocated memory as a temporary buffer and writes four bytes directly to the file page cache. This allows an attacker to maliciously modify the contents of the cache for any readable file.

The working exploit is a minimalistic Python script (~732 bytes) that uses the AF_ALG interface and the splice() system call to write four controlled bytes to the cache of, for example, an executable file with the setuid bit set. As a result, the program’s code is modified directly in RAM: upon the next launch, it performs malicious actions with superuser privileges. Meanwhile, the file itself on disk remains unchanged, allowing to bypass the integrity checks.

The vulnerability cannot be exploited remotely — an attacker needs local access to the system; however, this flaw can be used in an attack chain after gaining RCE, or, for example, by an insider.

The vulnerability is especially significant in the context of containerized environments. By default, Docker, LXC, and Kubernetes technologies grant processes inside a container access to the AF_ALG subsystem if the algif_aead module is loaded into the host kernel. Thus, Copy Fail poses a risk of breaching container isolation and gaining control over the physical machine. At the same time, exploitation does not require the use of complex techniques, such as race conditions or memory address guessing, which lowers the entry barrier for a potential attacker. Detecting the attack is difficult because the exploit uses only legitimate system calls, which are hard to distinguish from normal application behavior.

The fix has already been incorporated into the stable branches of the Linux kernel (commit a664bf3d603d): developers have addressed the issue of incorrect buffer validation when processing in-place cryptographic operations. In cases where an immediate kernel update is not possible, it is recommended to temporarily disable the loading of the algif_aead module. To do this, add the rule install algif_aead /bin/false to the modprobe.d configuration directory and unload the module using the rmmod command. On systems where the cryptographic interface is compiled into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), it may be necessary to add the initcall_blacklist parameter to the boot settings. Additional technical documentation on the AF_ALG interface and the CVE-2026-31431 vulnerability is available in open sources.

How to detect an attack in the case of a Python exploit

The original Python exploit leaves visible traces. Pay attention to specific command lines. The sh -c command directly launches privileged SUID utilities (su, sudo, mount, umount, passwd, gpasswd, chfn, chsh, newgrp, fusermount3).
The execution is tracked via following command lines:

Any Python process that launches a shell is also a red flag. Here is a process chain that could indicate an attack: Python – Shell – privileged executable. Artifacts of the initial exploit being launched via Python can be seen in the screenshot:

Detecting an attack using a SIEM system

To detect the exploit using a SIEM system and auditd events, the following recommendations are provided:

Detection of binary files reading (syscall: openat) with the suid bit (su, sudo, newgrp, passwd, gpasswd, chfn, mount, umount, fusermount, fusermount3, chsh — the list may be expanded) on behalf of a process not from /usr/bin, /bin, or on behalf of Python. Logging can be enabled with the following rule:
-w /usr/bin/su -p r - example for /usr/bin/su

Detection of the splice data transfer function (syscall: splice) between file descriptors after reading of a binary file with the suid bit (see above) by a non-root user. Logging for splice can be enabled with the following rules:

Detection based on characteristic command lines (syscall: execve), where the command line is sh -c -- su — example for /usr/bin/su

Detection of socket creation with the SOCK_STREAM=AF_ALG parameter (syscall: socket), where the argument is a0=26. Note that in the auditd event, the argument value is specified in hexadecimal format, while in the audit rule it must be specified in decimal format. Logging can be enabled with the following rules:

Detection by Kaspersky products

As mentioned above, new exploits are emerging for the Copy Fail vulnerability: in addition to the original Python implementation, working variants in Go and Rust have already been detected in open-source repositories. These implementations may use different techniques to bypass security mechanisms and vary the sequence of system calls, which requires adapting detection rules.

In this regard, we recommend paying attention to anomalous activity related to changes in user IDs (UIDs) within process chains. In particular, you should monitor instances where parent and child processes launched from unknown executables or files uncommon for the protected infrastructure exhibit a mismatch in expected privileges — for example, privilege escalation without an explicit setuid or sudo call. Such events may indicate an attempt to exploit LPE-class vulnerabilities, including Copy Fail.

Kaspersky experts are currently finalizing the development of a universal method for detecting attacks that exploit this vulnerability.

If we are talking about attacks using an exploit from the initial PoC written in Python, Kaspersky EDR Expert successfully detects this activity.

This activity can be detected by monitoring a scenario where a shell process, not running as root, is launched from a Python process, and its arguments contain an attempt to execute the su command or any other SUID binary file.

This approach allows for the detection of potentially dangerous actions when a Python script attempts to execute privileged commands via a shell without the necessary permissions. This may indicate attempts of privilege escalation or attempts to bypass established access restrictions. Kaspersky EDR Expert detects this activity using the possible_lpe_by_python rule.

Additionally, as noted earlier, this activity can be detected by analyzing specific command lines. In particular, attention should be paid to constructions of the form sh -c -- su, where the consistent pattern sh -c is used to pass the command to the shell. Kaspersky EDR Expert detects this activity using the possible_copy_fail_cve_2026_31431 rule.