Copy Fail (CVE-2026-31431): Linux Kernel LPE Actively Exploited

CISA has added the CVE-2026-31431 (Copy Fail) vulnerability in the Linux kernel to its CISA KEV Known Exploited Vulnerabilities catalog, confirming its active exploitation: the flaw, rated CVSS 7.8, allows any unprivileged local user to gain root privileges by corrupting cached in-memory executable files, including setuid binaries, which makes it critical to immediately update Linux distributions (especially in cloud and container environments) to kernel versions that contain the fix.

Technical details of the vulnerability

Copy Fail (CVE-2026-31431), described in the NVD entry CVE-2026-31431, is a local privilege escalation vulnerability in the Linux kernel’s authentication template cryptographic subsystem. CISA describes it as improper “resource transfer between spheres,” which in practical terms means a user-space process can affect objects in a more privileged domain.

Key facts about the vulnerability:

• Identifier: CVE-2026-31431 (Copy Fail)
• Score: CVSS 7.8 (high severity)
• Type: local privilege escalation (LPE) to root
• Vector: local (AV:L), low required privileges, no user interaction
• Affected systems: Linux distributions shipped since 2017
• Fixes: Linux kernel versions 6.18.22, 6.19.12, and 7.0

Researchers from Theori and Xint have shown that the issue did not arise from a single faulty commit, but from three individually “safe” changes to the kernel made in 2011, 2015, and 2017. Taken together, they resulted in a logical error in handling the authentication cryptographic template, which can be reliably exploited using a very compact (about 732 bytes) Python exploit. Based on this variant, implementations in Go and Rust have already appeared in public repositories.

A critical characteristic of Copy Fail is its attack target: the page cache, the in-memory page cache in which the kernel stores file contents. The vulnerability allows an unprivileged user to corrupt cached pages of any readable file, including setuid binaries. As Wiz emphasizes, the page in the cache is what the processor actually executes when a binary is launched, so changing the page cache effectively modifies the program on the fly without any writes to disk.

This leads to a typical exploitation scenario:

• an attacker with local access to the system uses the vulnerability to alter cache pages corresponding to a privileged binary (for example, /usr/bin/su);
• arbitrary code is injected into the modified pages;
• when the privileged binary is launched, the already modified code is executed, granting the attacker root privileges.

The exploit uses only legitimate system calls and does not rely on race conditions or guessing memory addresses. This immediately lowers the bar for exploitation and complicates behavioral detection: from the system’s perspective, it looks like normal application activity using the cryptographic subsystem and files.

According to the Microsoft Defender Security Research Team, “preliminary testing activity” around CVE-2026-31431 is already being observed, and by including the vulnerability in the KEV catalog, CISA explicitly indicates the presence of exploitation in the wild.

In essence, this technique corresponds to a typical privilege-escalation exploitation scenario which, in MITRE ATT&CK terms, falls under exploitation of local privilege vulnerabilities (Exploitation for Privilege Escalation).

Impact assessment and risk profile

The potential impact of Copy Fail is determined less by its CVSS score and more by the real-world contexts in which Linux is used:

• Cloud and virtualization. Linux dominates cloud infrastructures. Any scenario where an attacker can run code on a virtual machine or container (for example, via leaked SSH keys or a vulnerable web application) can be escalated to full control of the guest operating system and, under certain conditions, to attacks on the host platform.
• Container platforms (Docker, LXC, Kubernetes). According to Kaspersky, Copy Fail poses an elevated risk for containerized environments, since processes inside a container by default gain access to the AF_ALG subsystem if the algif_aead module is loaded into the host kernel. In that case, exploitation inside the container can lead to container breakout and full control of the physical (or virtual) host, effectively breaking the isolation model.
• Shared servers and multi-tenant systems. Training platforms, hosting providers, and any environments where different users obtain shell access to the same Linux host become especially vulnerable: a single uncontrolled user can gain root and compromise other customers’ data.
• Critical infrastructure and government agencies. For U.S. federal civilian executive branch (FCEB) agencies, CISA has set a strict deadline for applying patches—by May 15, 2026. This reflects the risk to integrity and availability of critical services in the event of successful local compromise.

From a business risk standpoint, the consequences of inaction include:

• complete server takeover with the possibility of subsequent horizontal and vertical movement within the infrastructure;
• undermining trust in application integrity: code injection into privileged binaries can be used as a low-visibility mechanism for long-term persistence and for bypassing integrity controls that operate only at the file-system level;
• compromise of CI/CD pipelines: if an attacker gains root on build agents, they can silently modify produced artifacts;
• regulatory repercussions in incidents where root access is used to exfiltrate or destroy data classified as critical or personal.

Practical security recommendations

1. Assessing exposure

The first priority is to determine which systems may be vulnerable:

• check the kernel version using the uname -r command on Linux servers and workstations;
• compare the obtained versions with those into which the fix has already been integrated (6.18.22, 6.19.12, 7.0) or with updates released by your distribution vendor;
• analyze environments where it is possible to run code as non-privileged users: container clusters, servers with SSH access for developers, CI machines.

If in doubt, refer to the information on CVE-2026-31431 in the NVD database and the documentation of your distribution or kernel vendor (for example, the official kernel.org website).

2. Patch management and prioritization

Recommended update sequence:

1. Highest priority (urgent): nodes where third-party or malicious processes can gain local shell access: servers with public SSH access, Kubernetes nodes, nodes running external containers, shared servers.
2. High priority: CI/CD agents, infrastructure services, and databases where root compromise would cause cascading effects.
3. Other systems: include kernel updates in the nearest scheduled maintenance window.

For FCEB agencies, the deadline is set by CISA—by May 15, 2026. For commercial organizations, it is reasonable to aim for similar timelines: a matter of days rather than months.

3. Temporary measures when immediate patching is impossible

If promptly updating the kernel is impossible (for example, due to downtime constraints):

• Disable the vulnerable functionality. CISA recommends temporarily disabling the affected functionality. In practice, this means restricting the use of the AF_ALG subsystem and related modules (in particular, algif_aead) in line with your distribution vendor’s guidance.
• Strengthen network isolation. Minimize an attacker’s ability to gain local access: restrict SSH to VPN only or to trusted addresses, tighten access policies to bastion hosts.
• Review access policies in container clusters. Restrict the execution of untrusted containers on nodes where the updated kernel has not yet been installed, and where possible, avoid running containers with excessive privileges and access to the kernel’s cryptographic subsystems.
• Tighten account controls. Minimize the number of users with interactive system access and apply the principle of least privilege to service accounts.

4. Monitoring and detection

Given that the exploit relies only on legitimate system calls and does not modify files on disk, traditional file-system integrity monitoring is of limited use. Nonetheless, some auxiliary measures are possible:

• strengthen auditing of privileged binary execution (especially setuid) and anomalous behavior of processes running with root privileges;
• track atypical use of the kernel’s cryptographic subsystems and AF_ALG where they are not normally used by application software;
• review behavioral analysis rules in EDR or EDR-like solutions for Linux, adding a focus on unexpected privilege escalation of applications running as unprivileged users.

The key takeaway is that any environment where a potential attacker can run code on a vulnerable Linux host should be treated as being at risk of full compromise until the kernel is updated to a version that fixes CVE-2026-31431 or the relevant functionality is disabled. The most practical step is to update the kernel (or distribution kernel packages) to patched versions in the next maintenance window, prioritizing hosts with containers, public SSH access, and multi-user scenarios.