Everything We Know About Copy Fail CVE-2026-31431 So Far

Illustration of Linux Tux under attack amid a zero-day style security incident

Apr 29, 2026

Copy Fail, tracked as CVE-2026-31431, is one of the most disruptive Linux privilege-escalation disclosures in recent years. The vulnerability is not remote by itself, but it is unusually practical: researchers published a tiny public proof of concept, described the exploit as deterministic rather than race-based, and showed it working across Ubuntu, Amazon Linux, RHEL, and SUSE.

That combination matters because many Linux kernel bugs are either difficult to exploit reliably or heavily tied to one kernel build. Copy Fail appears different. For teams running shared infrastructure, CI workers, container hosts, or developer-accessible Linux systems, this is the kind of issue that warrants immediate review.

What Copy Fail is

According to the Xint write-up, CVE-2026-31431 is a logic flaw in Linux's authencesn cryptographic template that can be reached through AF_ALG and splice(). The published research says an unprivileged local user can turn that into a controlled 4-byte write into the page cache of any readable file.

That is what makes the bug so dangerous. The exploit does not need to overwrite the file on disk. Instead, it corrupts the in-memory page-cache copy that the kernel actually serves to processes reading or executing that file. Xint says that lets an attacker alter a setuid binary in memory, obtain root, and leave ordinary on-disk checksum comparisons looking clean because the underlying file is unchanged.

The public PoC targets /usr/bin/su by default, and the Copy Fail project page says the page-cache corruption is not persistent across reboot. The root shell, however, is real while the corrupted page stays resident in memory.

Why this bug is getting so much attention

The Copy Fail disclosure page and the public GitHub repository make three points defenders should take seriously:

The exploit is described as straight-line and reliable rather than timing-sensitive.
The published Python PoC is only 732 bytes and uses standard library modules.
The same exploit path was demonstrated across multiple major Linux distributions.

This is not just an ordinary "local user to root" story either. Xint also says the page cache is shared across containers on the same host, making CVE-2026-31431 relevant to container escape and multi-tenant Linux environments, not just classic shell-user privilege escalation.

What is confirmed so far

The Copy Fail timeline says the issue was reported to the Linux kernel security team on March 23, 2026, acknowledged on March 24, patched in mainline on April 1, assigned CVE-2026-31431 on April 22, and publicly disclosed on April 29.
The upstream kernel fix is the commit a664bf3d603d, titled crypto: algif_aead - Revert to operating out-of-place. The patch notes say it mostly reverts commit 72548b093ee3, which dates the vulnerable logic back to 2017.
The NVD entry shows the kernel CNA assigned a CVSS v3.1 score of 7.8 with a local, low-complexity attack path requiring low privileges.
Ubuntu's security tracker marks the issue as High priority and explicitly labels it a "Trivial local privilege escalation."
Amazon Linux Security Center currently shows affected kernel packages in Pending Fix status for Amazon Linux 2 and Amazon Linux 2023.
Debian's security tracker currently shows several releases still vulnerable, while unstable has moved to a fixed source package version.

Who should treat this as urgent

Not every Linux system carries the same practical risk, but some environments should move faster than others.

Shared Linux servers: If multiple users can run code on the same host, this is an obvious priority because the bug turns local execution into root.
CI runners and build agents: The Copy Fail site specifically calls out self-hosted runners and similar shared build systems. If untrusted pull-request code or external jobs run there, the path from job execution to host root is the real concern.
Container hosts: Xint frames CVE-2026-31431 as a container escape primitive because page cache is shared across the host.
Single-user workstations: The risk is lower in the sense that the bug is not a remote entry point by itself, but any malware or local code execution on that machine may be able to step up to root.

How to check whether you are impacted

There is no single universal command that answers this for every distribution. The practical approach is to combine kernel inventory with your vendor's advisory status.

Check the running kernel

Start with:
```
uname -r
```
Then check which kernel package is installed on your distro:
```
dpkg -l | grep '^ii  linux-image'
rpm -qa | grep '^kernel'
```
Compare that package against your vendor tracker

Use your distro's advisory page rather than guessing from the kernel version alone:
If your vendor still marks the running kernel package as vulnerable or pending fix, assume the host is exposed for local attackers.
Check whether the host has the higher-risk usage pattern

Move this to the top of the queue if any of the following are true:
- Untrusted users can log in locally.
- Untrusted code runs in CI on the host.
- The system runs containers from less-trusted workloads or tenants.
- The host contains secrets, signing keys, cloud credentials, or deployment credentials that become much more valuable after root access.
Check temporary-mitigation viability

The Copy Fail page says a pre-patch mitigation is to disable algif_aead, and the researchers say that will not measurably affect the vast majority of systems. If you need to understand whether you rely on AF_ALG, they suggest checking active usage with commands like:
```
ss -xa
lsof | grep AF_ALG
```

How to remediate

The long-term fix is straightforward even if the operational rollout is not: update to a kernel package that includes the upstream fix, then reboot into that kernel.

Install the vendor's patched kernel package

The upstream fix is the revert commit a664bf3d603d. In practice, most teams should not cherry-pick that commit manually. Use the kernel package your distribution publishes for your release.
Reboot and verify

Kernel fixes are not complete until the host is actually booted into the fixed kernel. After maintenance:
```
uname -r
```
Then confirm the running package is the one your vendor marks fixed.
Apply a temporary mitigation if patching cannot happen immediately

Both copy.fail and the Xint write-up recommend blacklisting algif_aead or blocking AF_ALG socket creation via seccomp until patched. The published module-blacklist example is:
```
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
```
That is a mitigation, not a final fix. You still need the patched kernel and a reboot window.
Reduce exposure on shared hosts

If the host runs CI jobs, notebooks, user-submitted workloads, or containers from different trust levels, it is reasonable to pause or isolate those workloads until the kernel update is complete.
Treat suspicious local activity seriously

Because the bug enables local root, any system where you suspect exploitation should be treated as a host-compromise event, not just as a failed patch-management task. Review privileged access, secrets on disk, build credentials, and what untrusted local users or workloads may have been able to reach.

One subtle point defenders should not miss

Part of the reason Copy Fail stands out is that the corruption lives in page cache rather than the on-disk file. That means teams relying only on simple file-integrity comparisons can miss what is happening during active exploitation. The published research is explicit on this point, and it is one reason shared environments deserve extra attention.

Bottom line

As of April 29, 2026, CVE-2026-31431 is a publicly disclosed Linux local privilege-escalation bug with a public PoC, a clear upstream fix, and active vendor tracking across major distributions. If you run shared Linux systems, container hosts, or CI infrastructure, the right posture is to verify exposure immediately, patch the kernel package from your vendor, reboot into the fixed build, and use the algif_aead mitigation only as a short bridge.