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

• 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.

   1. We also looked at how common AF_ALG loading is (based on the NET: Registered PF_ALG protocol family log). While this event does occur in legitimate environments, its timing appears to matter. Loading during system boot is relatively common, but on-demand loading (e.g., 300+ seconds after boot) was only observed after the CVE became public. This suggests that delayed AF_ALG loading may be a more suspicious signal. However, it is not definitive on its own, and could still occur in benign scenarios.

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.

A missing invoking username suggests that the caller identity could not be resolved. This aligns with the implementation in util-linux, where the invoking user is derived at runtime and passed into the logging routine; corruption of this state can result in incomplete log entries

For example, compare the following lines sourced from the same log file before and after exploitation:

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.

However, this behavior is not observed across all exploitation variants. For example, more common PoCs (such as the Theori implementation) may corrupt /usr/bin/suin a way that prevents normal PAM/logging execution entirely, resulting in no auth.log entry at all rather than a malformed one.
Therefore, this signal should be treated as path-specific and opportunistic: while it can provide high-confidence evidence of exploitation when present, its absence does not rule out compromise. In practice, it is most effective when correlated with additional indicators rather than used as a standalone detection.

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