Skip to content
CVEVulnerability ResearchCritical Infrastructureendpoint-securitySecure SDLC

Copy Fail: The Nine-Year Linux Bug That Just Got Everyone (CVE-2026-31431)

3 min read
Share

Copy Fail: The Nine-Year Linux Bug That Just Got Everyone

So. CVE-2026-31431. Nickname: Copy Fail. CISA added it to the known exploited vulnerabilities catalog on may 1st. FCEB agencies have until may 22 to patch. and if you think that only matters for federal agencies — it doesn't.

This flaw is in virtually every linux kernel shipped since 2017. ubuntu, amazon linux, rhel, suse, debian, fedora, arch. all of them. nine years.

What actually broke

The bug lives in the algif_aead module inside the AF_ALG socket interface — the part of the linux kernel that exposes cryptographic operations to userspace. specifically, it's in the authencesn cryptographic template.

The logic error creates a deterministic, controlled 4-byte write into the page cache of any readable file on the system. if you aim that write at a setuid binary, you can modify it in memory and get root. the modification is in-memory only. no disk artifacts. nothing to find in a traditional forensic sweep.

Theori researcher Taeyang Lee published the primary research. Wiz and Microsoft published companion analyses. the exploit itself is 732 bytes of python. it's public. you can find it.

Why this is worse than a typical LPE

Most local privilege escalation vulnerabilities require something non-trivial: a race condition that needs to win, a specific kernel version, a particular config flag, some unusual setup. copy fail is different.

It's deterministic. every major distro, every default kernel config. the exploit just works. that makes it genuinely dangerous in environments where:

  • You run shared CI/CD pipelines with untrusted code execution
  • You have multi-tenant kubernetes clusters
  • You do container-based builds where the kernel is shared across containers
  • Any developer or contractor has SSH access to a production-adjacent machine

An attacker with even a low-privilege foothold, a compromised developer account, a RCE in an internal service, a container escape to the host, can use this to get root reliably. and because there's no disk artifact, they can do it and clean up without leaving an obvious trace.

What you need to do

Patch the kernel. there's no workaround that fully mitigates this. the fix versions are:

  • 6.18.22 or later
  • 6.19.12 or later
  • 7.0 or later

For distros: ubuntu, rhel, amazon linux, suse, cloudlinux, debian — all have patches out or in progress. check your vendor's security advisory and update the kernel package. yes, you need to reboot.

After patching, audit your environment for signs of exploitation: look for anomalous privilege escalation events in your audit logs, review any processes running as root that shouldn't be, and check for unexpected modifications to any setuid binaries (even though copy fail is in-memory, look for changes that may have been combined with persistence mechanisms).

For cloud and kubernetes environments: this affects the host kernel, not just containers. if your nodes are running an unpatched kernel, the fix is at the node level. test, then roll out.

The timeline context

The flaw was introduced nine years ago. it was disclosed publicly in late april/early may 2026 and hit CISA's KEV catalog on may 1st, meaning there is confirmed in-the-wild exploitation. the exploit being public and the CISA confirmation together mean you should treat this as a weekend-level urgency patch, not a next-quarterly-maintenance item.

Federal agencies: may 22 deadline. everyone else: treat that as guidance, not a ceiling.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge, cybersecurity intelligence from Georgia.