Get Your Free Report
Start for Free
SOCRadar® Cyber Intelligence Inc. | CVE-2026-31431: “Copy Fail,” the Nine-Year-Old Linux Bug Introduced in 2017
Apr 30, 2026
4 Mins Read
Moon

CVE-2026-31431: “Copy Fail,” the Nine-Year-Old Linux Bug Introduced in 2017

A vulnerability hiding in plain sight for nearly a decade, capable of granting full root access to almost any Linux server with just a 732-byte Python script. Meet “Copy Fail” (CVE-2026-31431), a critical local privilege escalation flaw in the Linux kernel that affects virtually every major distribution shipped since 2017.

How Is This Vulnerability Exploited in Real Life?

The vulnerability known as Copy Fail (CVE-2026-31431) is exploited using a tiny, 732-byte Python script that relies solely on standard library modules. The exploit chains a logic bug in the authencesn cryptographic template with AF_ALG and the splice() system call to trigger a controlled 4-byte write directly into the page cache of any readable file.

Details of CVE-2026-31431 (SOCRadar Vulnerability Intelligence)

Details of CVE-2026-31431 (SOCRadar Vulnerability Intelligence)

In a real-world scenario, an unprivileged attacker targets a setuid-root binary (such as /usr/bin/su) and uses the exploit to inject shellcode into the in-memory cached copy of that binary. When the attacker executes the corrupted binary, it runs as UID 0, granting an immediate root shell. The exploit is highly stealthy because it bypasses the standard VFS write path; the corrupted page is never marked for writeback, meaning nothing is written to the physical disk. As a result, standard file integrity tools comparing on-disk checksums will fail to detect the compromise.

Which Versions Are Affected?

This vulnerability affects essentially every mainstream Linux distribution shipped since 2017. The bug was inadvertently introduced by a 2017 kernel optimization in algif_aead.c that allowed page cache pages to be placed into a writable destination scatterlist.

Because the exploit does not rely on race conditions or version-specific offsets, the exact same script is 100% reliable across a massive 9-year window (2017 to 2026). The vulnerability has been directly verified to work out-of-the-box on kernels spanning the 6.12, 6.17, and 6.18 lines, specifically rooting Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 (kernel 6.12), and SUSE 16. Other distributions like Debian, Arch, Fedora, and Oracle running affected kernels behave the exact same way.

Who Is Actually at Risk From This Issue?

The highest risk falls on administrators of multi-tenant Linux hosts such as shared dev boxes, build servers, shell-as-a-service platforms, and jump hosts where any user with a local account can instantly become root.

Furthermore, Kubernetes and container clusters are at extreme risk. Because the Linux page cache is shared across the entire host, this vulnerability acts as a container escape primitive. A single pod containing an attacker with the right primitives can compromise the underlying node and cross over into other tenants’ boundaries.

While single-user laptops and workstations are technically vulnerable, they are at a lower immediate risk. The bug does not grant remote access on its own, meaning an attacker would already need a foothold to execute local code, though any such execution would result in a full root compromise.

What Should They Do Now?

Patch first. Administrators should immediately update their distribution’s kernel to a version that includes mainline commit a664bf3d603d and reboot the system to load the new kernel. This patch reverts the problematic 2017 in-place optimization, ensuring that page cache pages can no longer end up in a writable destination.

If patching immediately is not possible, there are effective mitigations:

  • Disable the algif_aead module: This stops the exploit path and will not affect most standard cryptographic systems (like dm-crypt, SSH, or default OpenSSL), as they bypass AF_ALG entirely.
  • Implement Seccomp filters: For untrusted workloads such as containers, sandboxes, and CI runners, administrators should block AF_ALG socket creation via seccomp, regardless of the system’s patch state.
  • Blue teams should also adjust detection: since the attack leaves no on-disk trace and bypasses file integrity tools entirely, defenders should pivot to behavioral telemetry such as alerts on AF_ALG socket creation by unprivileged processes, paired splice() calls feeding setuid binaries into AF_ALG sockets, and EBADMSG return codes from AEAD decrypt operations.