Copy Fail (CVE-2026-31431): When "Local" Becomes a Full System Problem

Local privilege escalation (LPE) bugs have a reputation for being lower-priority than remote code execution (RCE) exploits. The logic makes sense on the surface: an attacker already needs access to your system. How much worse can it get?

Copy Fail answers that question clearly. Worse. Much worse.

CVE-2026-31431 allows any unprivileged local user to escalate to root on most major Linux distributions released since 2017. But what makes it stand out is the combination of reliability, stealth, and the fact that it doesn't stay local for long.

What's Actually Happening

The vulnerability lives in the Linux kernel's authencesn cryptographic template, part of the AF_ALG kernel crypto API. By chaining AF_ALG sockets with splice() system calls, an attacker can corrupt the page cache of a setuid binary without touching the file on disk.

This is the detail that matters most.

When a binary executes, the kernel runs the in-memory version, not the on-disk version. Copy Fail poisons that in-memory version. The file on disk looks completely clean, with hash checks passing and file integrity monitoring seeing nothing, but what actually runs is the attacker's code.

The Container Problem

Copy Fail doesn't stay contained to the host it's run on. In environments where containers share a base image with privileged containers on the same node, an attacker with access to an unprivileged container can corrupt shared binaries and use a privileged container as a pivot point to reach the host.

For Kubernetes environments, this means a compromised pod can become a node-level breach. The blast radius extends far beyond where the initial access occurred due to realistic post-exploitation paths possible in shared infrastructure environments.

Why Traditional Detection Misses It

Most detection and integrity tooling is built around a core assumption: if something malicious happened, it left a mark on disk. Copy Fail invalidates that assumption entirely.

• File integrity monitoring checks the disk. The disk is untouched.
• Hash-based validation compares against the on-disk binary. It matches.
• Disk-based scanning finds nothing, because there's nothing to find there.

By the time you go looking for forensic evidence, there may not be any. Proper detection has to happen at the runtime layer by observing what the system is actually doing, not through after-the-fact artifact inspection.

Immediate Steps

Patch. The fix is available upstream (commit a664bf3d603d). As of early May 2026, patches are available or in progress for many distributions, but not all. Check your distribution's security channel and prioritize:

• Kubernetes nodes
• Multi-tenant systems
• CI/CD runners processing external code
• Any host running untrusted workloads

If you can't patch yet, reduce your exposure by disabling the vulnerable module:

bash

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

rmmod algif_aead

Alternatively, block AF_ALG socket creation via seccomp policies.

What to Monitor

Because Copy Fail is designed to evade artifact-based detection, focus on behavioral signals:

• AF_ALG socket usage associated with authencesn templates
• splice() activity targeting setuid binaries
• Unprivileged processes interacting with privileged execution paths
• Unexpected root shell spawning
• Anomalous execution of trusted binaries following cryptographic activity

No single signal here is conclusive. But correlated together, they paint a picture that disk inspection cannot.

The Underlying Shift

Copy Fail is part of a pattern worth naming directly: modern exploits are increasingly designed to operate inside trusted systems rather than attacking them from the outside. They live in memory, leverage built-in kernel interfaces, and exploit assumptions that defenders have relied on for years, like container isolation or file integrity.

That pattern demands a shift in how security teams think about detection. The question can't just be "is this system vulnerable?" It has to also be "is this system being exploited right now?"

How Oligo Approaches This

Oligo’s approach answers both questions definitively. 

On one hand, Oligo's Runtime Vulnerability Management identifies vulnerable kernel versions across your environment, giving you a clear picture of where Copy Fail exposure exists, including which container hosts and shared infrastructure are most at risk.

On the other hand, Oligo CADR monitors the runtime behaviors that this attack chain relies on: AF_ALG socket activity, suspicious splice() usage, and privilege escalation attempts. Because detection operates at the runtime layer rather than against disk artifacts, it surfaces attacker activity as it's happening rather than after the fact, when the trail has gone cold.

Final Thoughts

Copy Fail is a strong reminder that "local" vulnerabilities can have systemic consequences, especially in containerized, multi-tenant, or shared environments. The combination of reliability, stealth, and container escape potential puts it in a different category than most kernel CVEs.

Defenders are urged to patch quickly, mitigate in the interim, and make sure that detection posture always looks at runtime behavior.