Copy Fail — Linux Kernel Local Privilege Escalation

Executive Summary

Any user who can log in to a Linux server — even with the most basic, low-privileged account — can use this vulnerability to instantly gain full administrative control of that system. From that position, an attacker can read or exfiltrate all data on the machine, deploy ransomware, create hidden backdoors, or move laterally to other systems on your network. In environments running containerised workloads, the same attack can break out of the container and compromise the underlying host. Patches are available from all major Linux vendors and should be applied immediately.

On 29 April 2026, security researchers at Theori's Xint division publicly disclosed a high-severity local privilege escalation vulnerability in the Linux kernel, tracked as CVE-2026-31431 and nicknamed "Copy Fail." The flaw is a logic bug in the kernel's authencesn cryptographic template — part of the AF_ALG userspace crypto API — that allows any unprivileged local user to make a deterministic, controlled four-byte write into the kernel page cache of any readable file on the system. By targeting a setuid binary such as su, an attacker can overwrite its in-memory copy and immediately obtain root access. A working exploit is 732 bytes of Python and takes seconds to execute.

The vulnerability was silently introduced into the Linux kernel in 2017 with version 4.14, meaning it has been present — undetected — for approximately nine years across virtually every major Linux distribution, including Ubuntu, Red Hat Enterprise Linux (RHEL), SUSE, Debian, Amazon Linux, AlmaLinux, and CloudLinux. The exploit is reliable, requires no race condition, no kernel offsets, and is functionally identical across distributions. The page cache is host-wide, which means the attack is also viable as a container escape from unprivileged containers. An upstream kernel fix was committed on 1 April 2026 and stable backports are now available.

Any Monachus customer operating Linux servers — including cloud instances, Kubernetes nodes, container hosts, and on-premises systems — should treat this as a priority patching event. Unpatched systems with multi-tenant access, shared hosting, or container workloads face the highest risk and must be addressed within 24–48 hours.

Vulnerability Details

Copy Fail exploits a logic error in the authencesn template within the Linux kernel's AF_ALG (userspace crypto API) subsystem. The authencesn template implements combined AEAD (Authenticated Encryption with Associated Data) operations, and a flaw in how it handles "in-place" encryption allows an attacker to trigger a controlled four-byte write into the kernel page cache — the shared, host-wide memory structure that caches file contents read from disk.

Because the page cache is shared between all processes and containers on a host, the write primitive applies to any file that is readable by the attacking user — including setuid binaries such as /usr/bin/su, /usr/bin/sudo, and /usr/bin/passwd. By corrupting the in-memory copy of one of these binaries, the attacker causes the kernel to execute attacker-controlled code the next time the binary is invoked, granting an instant root shell. The vulnerability requires no race condition, no brute-forcing, and no kernel symbol offsets — the exploit is fully deterministic and produces a 100% success rate in testing across all major distributions.

Unlike many local privilege escalation vulnerabilities, Copy Fail is also effective as a container escape. Because the page cache is host-wide and is not namespaced by the kernel, an attacker with code execution inside an unprivileged container can use the same primitive to corrupt binaries visible on the host, breaking container isolation entirely. This makes the vulnerability especially severe in Kubernetes, Docker, and other container-based environments where multi-tenancy relies on namespace isolation.

A public proof-of-concept exploit consisting of 732 bytes of Python is already in circulation. Exploitation requires only a local, unprivileged user account. Any Linux host running kernel 4.14 or later that has not been patched or mitigated is fully compromised the moment a malicious local user runs the script.

Exploitation Prerequisites

For this vulnerability to be exploitable, the following conditions must all be true:

Notably, this vulnerability does not require: network access to the target, administrator or sudo rights, any specific application to be installed or running, or the attacker to be physically present. The only barrier to exploitation is obtaining any valid local login — a low bar given common attack vectors such as phishing, credential stuffing, or lateral movement from a compromised adjacent system.

Attack Chain

1. Step 1 — Local Access: The attacker obtains a local, unprivileged user account on the target Linux system. This may be achieved via a compromised web application, stolen credentials, phishing, SSH brute-force, or insider access.
2. Step 2 — Open AF_ALG Socket: The attacker opens an AF_ALG socket of type SOCK_SEQPACKET bound to the authencesn algorithm — a standard, unprivileged system call available on all affected kernels.
3. Step 3 — Trigger Page Cache Write: The attacker sends a crafted AEAD encryption request that exploits the in-place processing logic error in authencesn, causing the kernel to write four attacker-controlled bytes into the page cache entry of any readable file.
4. Step 4 — Target Setuid Binary: The attacker selects a setuid binary (e.g., /usr/bin/su) as the corruption target. The page cache entry for this binary is modified such that a specific instruction is overwritten with a short-circuit that skips the privilege drop.
5. Step 5 — Trigger Execution: The attacker invokes the corrupted binary. The kernel loads and executes the modified in-memory version — the on-disk file is unchanged. The binary runs as root, spawning a root shell under the attacker's control.
6. Step 6 (Optional) — Container Escape: In containerised environments, the same page cache write targets host-visible binaries from within the container namespace, allowing the attacker to escape the container and gain root on the underlying host.

Vendor Response

The Linux kernel security team assigned CVE-2026-31431 on 22 April 2026, one week before public disclosure. The upstream fix — reverting the problematic "in-place" crypto behaviour introduced in kernel 4.14 in 2017 — was committed on 1 April 2026 and backported to the stable series. Patched kernel versions 6.18.22, 6.19.12, and 7.0 are now available from kernel.org.

Major distribution vendors have responded as follows:

CERT-EU has issued Security Advisory 2026-005 for this vulnerability, recommending immediate patching and interim mitigation via AF_ALG socket blocking.

Immediate Mitigation Recommendations

Tier 1 — Immediate (Within 24–48 Hours)

1. Apply vendor kernel patches: Update to the patched kernel for your distribution immediately. This is the only complete remediation. Use apt-get upgrade, dnf update kernel, zypper update kernel-default, or the equivalent for your distribution. Reboot to activate the new kernel.
2. Disable the algif_aead module as an interim workaround: On systems that cannot be immediately patched or rebooted, prevent the vulnerable module from loading by running:

   echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
   rmmod algif_aead 2>/dev/null || true

   This workaround does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. It persists across reboots when written to /etc/modprobe.d/.
3. Block AF_ALG sockets via seccomp on containerised workloads: Since the exploit requires opening an AF_ALG socket as its first step, adding a seccomp policy that denies socket(AF_ALG, ...) calls to all container workloads prevents exploitation even on unpatched kernels. Apply this to all pods, Docker containers, and similar workloads immediately.
4. Audit for active exploitation: Review system logs for unexpected privilege escalation events, new root-owned processes spawned by non-root users, unexpected su or sudo invocations, and signs of setuid binary tampering. Kernel audit rules for setuid execution should be enabled if not already in place.

Tier 2 — Short-Term (Within 1–2 Weeks)

1. Inventory all Linux hosts: Identify every system in your estate running an affected kernel version (4.14 through 7.0-rc). Include cloud instances, on-premises servers, developer workstations, CI/CD runners, and Kubernetes nodes.
2. Verify patch deployment across the full estate: Confirm that patched kernels are running — not merely installed — by checking uname -r output post-reboot. Automate this check via your configuration management tooling (Ansible, Chef, Puppet, etc.).
3. Harden container runtime security profiles: Review all seccomp profiles, AppArmor/SELinux policies, and Kubernetes PodSecurityAdmission settings. Ensure that AF_ALG socket creation is blocked at the runtime level for all non-privileged workloads. Consider adopting a default-deny seccomp profile baseline.
4. Review multi-tenant and shared access environments: Systems with multiple local users, shared developer environments, and CI/CD agents with shell access should be treated as highest priority. Restrict local user access where possible until patching is confirmed.

Tier 3 — Medium-Term (Within 30 Days)

1. Integrate CVE-2026-31431 into your vulnerability management programme: Ensure your vulnerability scanner signatures are updated to detect unpatched kernels. Add detection for exploitation artefacts (unexpected setuid binary modifications, AF_ALG socket usage by unprivileged users) to your SIEM alerting rules.
2. Review kernel hardening baselines: Assess whether your current kernel hardening configuration (seccomp defaults, capability restrictions, Yama LSM settings) would have limited the impact of this class of vulnerability. Update baselines accordingly.
3. Test container escape detection capability: Validate that your runtime security tooling (Falco, Sysdig Secure, Aqua, etc.) generates alerts when AF_ALG sockets are opened by processes inside containers. Adjust detection rules as needed.

Tier 4 — Strategic

1. Adopt a live kernel patching capability: Vulnerabilities of this class — reliable, local privilege escalation with public exploits — demand rapid patching without service disruption. Evaluate live kernel patching solutions (e.g., KernelCare, SUSE Live Patching, Red Hat kpatch, Canonical Livepatch) to reduce future mean-time-to-patch for critical kernel CVEs.
2. Establish kernel update SLAs: Define and enforce a service-level agreement for critical Linux kernel CVEs, targeting patch deployment within 72 hours for High/Critical LPE vulnerabilities with public exploits.
3. Invest in kernel security monitoring: Deploy or mature kernel-level threat detection that baselines normal AF_ALG usage patterns and alerts on anomalous activity. Page cache integrity monitoring should be added to your detection engineering roadmap.

Ecosystem Context

Copy Fail follows a well-established pattern of page cache corruption vulnerabilities in the Linux kernel. Like Dirty Pipe before it, the primitive does not require a race condition and is fully reliable — characteristics that make it particularly dangerous compared to typical kernel LPEs. The nine-year dormancy period also highlights the ongoing challenge of auditing complex cryptographic subsystems for non-memory-safety logic bugs.

Compliance Implications

SOC 2

Copy Fail has direct implications for the following SOC 2 Trust Services Criteria:

• CC7.1 — Vulnerability Detection: Organisations must demonstrate that critical vulnerabilities with public exploits are detected and tracked promptly. Failure to identify CVE-2026-31431 in your estate within a reasonable timeframe may constitute a control gap.
• CC7.2 — Vulnerability Remediation: A public LPE with a 732-byte PoC exploit demands prioritised remediation. Auditors may scrutinise patch timelines for this vulnerability given its severity and exploit availability.
• CC6.1 — Logical Access Controls: A vulnerability that allows any local user to become root represents a direct failure of the least-privilege principle. Container environments relying on namespace isolation for multi-tenancy must implement compensating controls.
• CC6.6 — Logical Access Restrictions: Systems with multiple users sharing local access (shared CI/CD runners, developer VMs, jump hosts) require immediate mitigation or isolation.

ISO 27001:2022

• A.8.8 — Management of Technical Vulnerabilities: Requires timely identification and remediation of technical vulnerabilities. CVE-2026-31431 should be assessed and remediated in accordance with your documented vulnerability management timescales.
• A.8.15 — Logging: Detection of exploitation attempts requires appropriate kernel audit logging. Organisations should ensure auditd rules cover setuid binary execution and unexpected privilege escalation events.
• A.8.22 — Segregation of Networks: Container escape capability reinforces the need for network-level controls between container workloads; isolation should not rely solely on kernel namespace separation.
• A.5.29 — Information Security During Disruption: Emergency patching procedures should be invoked for this vulnerability. Organisations should document the decision-making process and timelines for auditors.

Conclusion

Copy Fail is one of the most broadly exploitable Linux kernel vulnerabilities disclosed in recent years. Its nine-year dormancy, trivial exploitation requirements, 100% reliability across all major distributions, and the immediate availability of a public proof-of-concept place it in the same tier as Dirty Pipe and Dirty COW — vulnerabilities that caused genuine disruption across the industry when disclosed. The difference here is that patches are already available, which means the window for remediation is open now. Organisations that act quickly can close this exposure before attackers incorporate it into commodity toolkits.

The strategic takeaway is straightforward: if you run Linux, you are affected, and the only question is how quickly you can patch. The interim mitigation — disabling a single kernel module — is low-risk, takes under a minute, and requires no reboot. There is no good reason to leave systems exposed while patching is scheduled. Apply the module workaround today on any system that cannot be immediately rebooted, then complete kernel patching across your full estate within 48 hours.

References

• copy.fail — Official Researcher Disclosure Site
• Xint / Theori — Copy Fail: 732 Bytes to Root on Every Major Linux Distribution
• GitHub — Cross-platform C port of Copy Fail PoC (tgies/copy-fail-c)
• Bugcrowd — What We Know About Copy Fail (CVE-2026-31431)
• Bleeping Computer — New Linux 'Copy Fail' Flaw Gives Hackers Root on Major Distros
• Securelist — Copy Fail: Root on Virtually Any Linux
• CERT-EU — Security Advisory 2026-005: High Vulnerability in the Linux Kernel
• Ubuntu — Fixes Available for CVE-2026-31431 (Copy Fail)
• Tenable — Copy Fail FAQ: Linux Kernel Privilege Escalation
• Sophos — Proof-of-Concept Exploit Available for Linux Copy Fail
• AlmaLinux — Copy Fail (CVE-2026-31431) Patch Ready for Testing
• Amazon Linux — CVE-2026-31431
• Picus Security — Copy Fail: Critical Linux Kernel Privilege Escalation Vulnerability
• The Hacker News — New Linux 'Copy Fail' Vulnerability Enables Root Access on Major Distributions