CVE-2026-31431 (dubbed "Copy Fail") is an easily exploitable vulnerability in the Linux kernel that allows escalation from an unprivileged local user account to root access. The vulnerability was discovered by Xint, and affects nearly all versions of the Linux kernel since 2017. While a fix is available upstream, many Linux distributions have not yet released patches as of May 1st.

What is CVE-2026-31431?

As described by Xint, “an unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.”

The vulnerability stems from a logic flaw in the Linux kernel’s AEAD crypto implementation (algif_aead), where improper handling of scatter-gather lists allows a write beyond intended bounds. By chaining this flaw with AF_ALG sockets and splice(), an attacker can overwrite 4 bytes in the page cache of any readable file, including setuid binaries.

Because the page cache represents the in-memory version of executables, modifying it effectively alters binaries at execution time without touching disk. This enables attackers to inject code into privileged binaries (e.g., /usr/bin/su) and thereby gain root privileges.

Beyond local privilege escalation, the vulnerability also allows for container escape in certain scenarios. For example, if an attacker gains access to an unprivileged container sharing a base image with a privileged container running on the same node, they can override specific binaries in the base layer and thereby escape to the host through the privileged container (see this public POC exploit for reference).

Affected Products

Linux kernel versions built between 2017 and the patch release (2026).

Patch Status

The following is the current status as of May 1, 2026, 9AM UTC, but Linux distributions are rapidly releasing new patches:

What steps should security teams take?

Triage

1. Since this vulnerability is incredibly prevalent, we recommend prioritizing remediation efforts on affected hosts running applications that may execute external untrusted code. This includes (but is not limited to) production multi-tenant services and CI runners operating in public repositories.

2. For more specific triage, defenders should leverage context such as whether the underlying host contains sensitive secrets or has high privileges in the environment.

Remediation

Update to a kernel version that includes the fix (mainline commit a664bf3d603d).

Alternatively, or until patches are available for your distribution, apply the following temporary mitigations (note that these methods aren't equally effective on all distros):

• Disable the vulnerable module

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

• Block AF_ALG socket creation via seccomp policies.

Exploitation Detection

Note that currently known detection methods may be overly biased towards surfacing behavior exhibited by early POC exploits, and as new research emerges, threat actors are likely to adopt new exploits that evade these initial methods. Therefore, this section is currently incomplete, and we will update this blogpost with additional information as it comes to light and as our own research progresses.

As of now, the following indicators have been identified as detecting exploitation on certain systems (but as mentioned above, they might not detect all variants):

1. Correlate AF_ALG loading with other suspicious signals: exploitation using currently known POCs triggers the message NET: Registered PF_ALG protocol family in kern.log and syslog. It is normal to observe this message during boot and on-demand loading by legitimate applications, but it should warrant investigation when correlated with other indicators.

2. Alert on curl commands for https://copy.fail/exp (Xint’s website storing POC exploit code, which non-stealthy attackers may use despite being obvious).

3. Monitor for anomalous AF_ALG socket behavior.

Additionally, our internal testing has demonstrated that execution of a page-cache-modified /usr/bin/su can produce malformed auth.log entries, likely resulting from partial corruption of the binary’s runtime state. Under normal conditions, su logs both the target account and the calling user (resolved from process credentials). However, a missing invoking username indicates that the caller identity could not be resolved. For example, compare the following lines sourced from the same log file before and after exploitation:

2026-05-01T09:11:16.296455+00:00 ip-172-31-38-240 su[1765]: (to root) alice on pts/1

2026-05-01T09:14:19.993416+00:00 ip-172-31-38-240 su[1781]: (to root) on pts/1

This can also occur normally under rare legitimate scenarios, but in combination with other signals (such as those listed above), this effect can serve as a potential post-exploitation detection signal that can be leveraged by defenders. We therefore recommend checking for such auth.log entries that contain su records with a missing invoking username.

How can Wiz help?

Wiz customers can use the pre-built queries and advisory in the Wiz Threat Intel Center to search for relevant instances in their environment.

References

• Xint “CopyFail” site

• Xint Technical Writeup