Copy Fail (CVE-2026-31431): How to identify and fix vulnerable assets

May 7, 20265 min

TL;DR CVE-2026-31431 (aka "Copy Fail") is a Local Privilege Escalation (LPE) zero-day affecting virtually all major Linux distributions released since 2017. Unprivileged attackers can exploit a logic flaw in the kernel's cryptographic subsystem to gain root access. Active exploitation is confirmed. Patch immediately or apply the interim boot-level mitigation.

What is Copy Fail (CVE-2026-31431)?

Copy Fail is a deterministic logic flaw in the Linux kernel’s algif_aead module (within the AF_ALG interface). Stemming from a faulty in-place optimization introduced in 2017, the bug allows an unprivileged local user to trigger a controlled 4-byte write directly into the page cache of any readable file.

By targeting binaries (like /usr/bin/su or sudo), an attacker can corrupt the in-memory representation of these executables to escalate user privilege. Because the physical file on disk remains completely untouched, this modification evades standard integrity checks and instantly yields root execution.

Why is CVE-2026-31431 critical?

Active exploitation: The vulnerability is already being exploited in the wild and CISA has added it to its Known Exploited Vulnerabilities (KEV) catalog.
100% reliability: Unlike many kernel exploits, Copy Fail does not rely on race conditions or memory offsets. It is a straight-line logic flaw that works every time.
Massive blast radius: The flaw is present in kernel versions 4.14 to 6.19.12. This impacts essentially every modern Linux distribution, including Ubuntu, Amazon Linux, RHEL, SUSE, and AlmaLinux.
Host/container breakouts: The Linux page cache is shared across the host system. A successful overwrite from inside one container corrupts the cached binary for the entire host and all neighboring tenants. If you run untrusted code in shared-kernel environments (like Kubernetes clusters, CI/CD pipelines, or AI sandboxes), Copy Fail breaks your isolation boundary.

Which systems are affected/not affected by Copy Fail?

Systems affected:

The flaw is present in Linux kernel versions 4.14 through 6.19.12.
Because this module is widely used, it impacts essentially every modern, major Linux distribution that relies on these kernel branches.
That includes the following, but not limited to: Ubuntu, Amazon Linux, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), AlmaLinux, and Debian.
According to community testing on GitHub, this vulnerability also affects Linux virtualized instances running on Windows OS via Windows Subsystem for Linux (WSL2).

Systems not affected:

Non-Linux operating systems: Since this is a logic flaw specific to the Linux kernel's cryptographic subsystem (algif_aead), other systems, such as UNIX derivatives, Solaris, AIX, MacOS, and BSD variants are not affected.
Legacy Linux Kernels (Pre-2017's kernel version 4.14): Any legacy Linux system running a kernel version strictly older than 4.14 (e.g., heavily outdated CentOS 7 running the stock 3.10 kernel) does not contain the vulnerable code path.
Systems with Linux Kernel newer than 6.19.12.

How to identify affected systems with Axonius

Before you begin, run a global discovery to ensure you’re working with the most current data from your environment.

1. Identify vulnerable instances detected by your vulnerability scanners

To find instances of the Copy Fail (CVE-2026-31431) already identified by your vulnerability scanners or CNAPP solutions, go to Assets > Exposures > Aggregated Security Findings and search for:

{"vulnerabilities":"(\"specific_data.data.cve_id\" == \"CVE-2026-31431\")","devices":""}

2. Identify affected Linux devices NOT found by your scanners

Go to Assets > Compute > Devices, and search for Devices with Linux OS and Kernel versions not matching the fixed version:

("specific_data.data.os.type" in ["Linux"]) and not ("specific_data.data.os.kernel_version" == "6.19.12")

3. Identify systems hosting containers visible by your container security tools

Because of the risk of host breakout, devices and servers running containers present additional risk with Copy Fail. To identify these hosts, go to Assets > Compute > Devices, and use the following container relationship query to find Devices running containers (with visibility from your container security tools, such as R7 DivvyCloud, Wiz, and Orca):

('relationship.containers.[656c8429b743246717b0ba07]' in ['AQL=(("specific_data.data.id" == ({"$exists":true,"$ne":""})))'])

4. Identify systems hosting containers NOT visible by your container security tools

To find devices and servers running containers, but not visible by your container security tools, go to Assets > Compute > Devices, and search for devices running container hosting technologies. Here's an example query looking for systems running containerd, docker, lxd, podman, and the Windows Subsystem for Linux (WSL2):

("contains.[specific_data.data.installed_software.name]" in ["containerd","docker","lxd","podman","vmmem"])

5. Identify compute images NOT visible by vulnerability agents and network scanners

To identify images (VM, EC2, etc) vulnerable to Copy Fail (which cannot be found by vulnerability scanners due to no agent running or network scanning active), go to Assets > Compute > Compute Image and run the following query:

("specific_data.data.os.type" in ["Linux"]) and not ("specific_data.data.os.kernel_version" == "6.19.12")

How to remediate and mitigate Copy Fail

1. Track and patch as immediately available: Upstream Linux kernel maintainers have reverted the flawed optimization, with Linux distributions rapidly releasing new patches and mitigating procedures. That includes, but is not limited to: Ubuntu, AWS Linux, RedHat, Debian, Arch Linux, SUSE, and CloudLinux. Patch affected systems as soon as a patch is available. Track the progress of remediation efforts across systems affected by using Case Management in Axonius.

2. Prioritize systems of high risk: Such as CI/CD runners, systems hosting or processing critical data, and systems running containers with breakout risk. With Axonius, you track signs by looking at systems on specific production subnets, running data stores (i.e., Oracle, MongoDB, LDAP), or critical middleware across on-prem and in the cloud. Axonius Risk Scores enable you to automate the assessment and score risk using your own criteria.

3. Prioritize systems with local access: That includes jump servers, bastion hosts, and systems with multiple user access. With Axonius, you track signs of heavy usage by looking at fields such as “Last Used Users”.

Additional Copy Fail resources and advisories

The following resources provide official patch details, exploit analysis, and threat advisories for Copy Fail (CVE-2026-31431):

Copy Fail affects virtually every modern Linux distribution, and active exploitation is confirmed. If you're using Axonius, the queries above give you immediate visibility into affected assets across your environment, including the ones your scanners miss. See how Axonius handles exposures →