CVE-2026-31431 (Copy Fail): Linux Kernel LPE Breakdown and Remediation Runbook

CVE-2026-31431, known as “Copy Fail” by Theori who disclosed it on April 29, 2026, is a high severity (CVSS 7.8) Linux kernel local privilege escalation vulnerability that lets any authenticated user gain root access on an unpatched system.

Below is a breakdown of how the Copy Fail exploit works, which kernel versions and environments are affected, what indicators to hunt for, how to patch in the first hour and why conventional tooling can identify vulnerable kernels but miss exploitation behavior.

What Is CVE-2026-31431 (Copy Fail)

CVE-2026-31431, also called Copy Fail, is a Linux kernel local privilege escalation flaw rated CVSS 7.8 that abuses memory handling during kernel copy operations to overwrite privileged memory and elevate any authenticated user to root. The vulnerability was disclosed by Theori researchers in late April 2026, with public exploit material available through copy.fail and GitHub.

Copy Fail is not a remote code execution vulnerability. An attacker needs local execution first, such as a shell account, compromised service, malicious container, or foothold on a CI runner. Once local access exists, the exploit can turn a low-privileged user context into root on an unpatched Linux system.

The exposure is highest in environments where local execution is common or shared across workloads. Kubernetes worker nodes, CI/CD runners, shared Linux VMs, and multi-tenant systems increase the blast radius because one compromised user, container or runner job can become a full host compromise.

The core issue is improper kernel memory handling during copy operations. Under specific conditions, user-controlled data can influence privileged memory writes, allowing root escalation from an authenticated local user. Vendor patches are available, but affected systems must be restarted after patching to load the fixed kernel.

How the Copy Fail Exploit Chain Executes

Copy Fail (CVE-2026-31431) chains a crafted sequence of system calls into a faulty kernel memory copy operation, lets user-controlled data influence privileged memory writes, and overwrites kernel structures to escalate from a low-privileged shell to root. The exploit requires only local authenticated access. No elevated privileges, kernel modules, or special capabilities are required.

Initial Trigger

The exploit starts from a local foothold. An attacker must already be able to execute code on the target system, but that access can come from compromised SSH credentials, an exposed service, a malicious container image, or a compromised CI/CD runner.

No administrator access is required. Once local execution exists, the exploit can run from a low-privileged context against an affected kernel.

Faulty Copy Operation

The flaw resides in kernel memory handling during copy operations. Attackers issue a specific syscall sequence that puts the kernel in a state where user-controlled bytes drive a privileged memory write.

The validation gap sits in the copy path itself. Because of that, mitigations such as KASLR and SMEP do not block reliable exploitation in the published PoC.

Memory Corruption and Root Escalation

The corrupted write modifies kernel data structures associated with process credentials. Exploitation results in a process running with UID 0.

At that point, the attacker has root on the host. Public PoC code demonstrates reliable exploitation paths across mainstream Linux distributions.

Post-Exploitation Implications

Once the attacker holds root on a host, the blast radius depends on the environment.

1. Kubernetes worker node: Full node compromise can expose pod secrets, mounted credentials, service account tokens, and pivot paths toward the control plane.
2. CI/CD runner: Root access can expose build secrets, signing keys, registry credentials, cloud credentials, and artifacts from current or previous jobs.
3. Multi-tenant VM: Root access can create cross-tenant exposure depending on workload isolation, host configuration, and credentials available on the system.

Affected Versions and Environments

CVE-2026-31431 affects Linux kernels built between the 2017 algif_aead in-place AEAD change and the vendor patch, where AF_ALG and authencesn / algif_aead are available. Theori directly verified exploitation on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL and SUSE test kernels, while CloudLinux confirmed impact across CL7h, CL8, CL9, and CL10 with specific patched kernel targets.

Vulnerable Kernels

Theori states that these were directly verified test targets, and that other distributions running affected kernels, including Debian, Arch, Fedora, Rocky, Alma, Oracle and embedded Linux builds, are expected to behave the same if the vulnerable kernel path is present. The relevant condition is not only the distribution name. Teams should verify whether the running kernel includes the affected algif_aead behavior and whether the vendor fix has been applied.

CloudLinux affected versions and patch targets

CloudLinux notes that CL7h and CL8 use CloudLinux kernel fixes, while CL9 and CL10 use the AlmaLinux kernel path. After updating, teams should reboot and verify the running kernel with uname -r. KernelCare livepatch is also available for affected versions as an alternative path where supported.

KernelCare Livepatch Updates

CloudLinux states that KernelCare customers on the main feed receive the fix on their next kcarectl --update. Verification should include kcarectl --patch-info checks for CVE-2026-31431, algif_aead, or copy.fail.

Interim mitigation when patching is not immediate

If a kernel update or KernelCare livepatch cannot be applied immediately, CloudLinux recommends blacklisting the algif_aead initcall using initcall_blacklist=algif_aead_init and rebooting. CloudLinux also warns that the common modprobe.d workaround does not work on CloudLinux, AlmaLinux or RHEL-family distributions when algif_aead is built into the kernel.

Indicators of Compromise (IOCs) and Behavioral Signals

There is no single static IOC for CVE-2026-31431 exploitation because the exploit modifies page-cache state rather than writing a durable on-disk artifact. Detection should focus on behavioral signals: AF_ALG and authencesn reachability, suspicious splice() and sendmsg() activity, page-cache modification, and unexpected UID 0 transitions from low-privileged processes.

Public PoC and Detector Artifacts

The public toolkit describes test_cve_2026_31431.py as a detector and exploit_cve_2026_31431.py as an LPE that flips the running user’s UID to 0 in the page cache view of /etc/passwd, then invokes su for a root shell. Both scripts are Python 3.10+ standard library only.

Kernel and Syscall Behavioral Signals

The public repository explains that the vulnerable path writes 4 bytes from AAD positions 4 to 7 into the destination scatterlist after sendmsg(), splice() and recv() drive the AEAD path. The detector reports VULNERABLE to CVE-2026-31431 or Page cache MODIFIED via in-place AEAD splice path when the marker lands or page cache modification is observed.

Privilege Escalation Indicators

The copy.fail page states that the public exploit edits the page cache of a setuid binary and that the change is not persistent across reboot, but the resulting root shell is real. The GitHub toolkit also notes that a reboot clears the page-cache state. 

Audit and Log Indicators

For Copy Fail, defenders should separate exposure from exploitation. Exposure is a vulnerable running kernel with reachable AF_ALG and algif_aead behavior. Exploitation is a behavioral chain: unprivileged local execution, copy-path abuse, page-cache modification, and unexpected root access.

The First-Hour Response Runbook for CVE-2026-31431

Treat any unpatched Linux host as compromised-pending-proof. The response priority is to patch the kernel, restart affected systems to load the fixed kernel, and audit for prior exploitation in the window between disclosure and patch.

1. Inventory every Linux host running an affected kernel version: Query the running kernel with uname -r and cross-reference Ubuntu, CloudLinux, and upstream advisories against your fleet. For CVE-2026-31431, exposure is tied to the running Linux kernel version, not application package versions.
2. Apply vendor patches immediately: Prioritize Internet-facing systems, Kubernetes worker nodes, CI/CD runners, shared jump hosts, shell servers, and hosts running untrusted or multi-tenant workloads.
3. Restart affected systems after patching: Kernel updates do not protect the host until the patched kernel is loaded. Confirm the active kernel after reboot with uname -r.
4. Restrict local access where immediate patching is not possible: Disable shell access for non-essential service accounts, tighten SSH allowlists, and reduce the number of users who can execute code locally.
5. Apply temporary mitigations only where vendor guidance supports them: Use mitigations such as disabling affected kernel functionality only as a short-term control. Patch and reboot remain the required remediation path.
6. Audit privileged activity from April 29, 2026 onward: Look for UID 0 transitions, unexpected sudo activity, anomalous process trees, and root shells spawned from low-privileged users, service accounts, containers, or CI jobs.
7. Rotate credentials accessible from any potentially compromised host: Include Kubernetes service account tokens, CI/CD secrets, cloud provider keys mounted as environment variables, SSH keys cached on the host, registry credentials, and secrets available to workloads running on the affected system.
8. Hunt for persistence on hosts that ran an unpatched kernel: Check cron jobs, systemd timers, kernel modules, new authorized_keys entries, shell profile changes, suspicious binaries in writable directories, and unexpected changes to service definitions.
9. Document patch state per host: Record the running kernel version, patch date, reboot status, mitigation status, audit findings, and any follow-up remediation needed for incident response and compliance handoff.

Why Conventional Tooling Caught Patch Status but Missed Exploitation

Vulnerability scanners can identify hosts running an unpatched kernel for CVE-2026-31431, but they do not prove whether Copy Fail was exploited. CVE-based tooling answers “is this host vulnerable?” while runtime detection answers “did a process actually escalate to root?”

For Copy Fail, the exposure check is the running kernel version, not an application package version. A scanner can identify hosts that still need patching, but patch status alone does not show whether exploitation occurred before the fix was applied.

That gap matters because CVE-2026-31431 does not behave like a file-based compromise. The exploit operates through kernel memory handling and privilege transition behavior. It does not need to drop a persistent binary, write a recognizable file, or generate a network callback during escalation.

The reliable signal is behavioral: a process that should not have root suddenly gains root. 

For Copy Fail, teams should monitor for:

1. Low-privileged processes transitioning to UID 0 without sudo, setuid or an expected administrative path.
2. Suspicious copy-related syscall activity before privilege gain.
3. Unexpected capability changes, including CAP_SYS_ADMIN.
4. Root shells spawned from service accounts, containers, CI jobs, or low-privileged SSH sessions.
5. Post-exploitation activity on hosts that ran an affected kernel between disclosure and patch.

Static and CVE-based tools are still necessary, they identify vulnerable hosts and help prioritize patching but they often don’t confirm exploitation.

Runtime Intelligence observes what processes and workloads actually do across containers, VMs and Linux hosts. For Copy Fail, that means detecting syscall and process behavior associated with successful Linux kernel local privilege escalation, including unexpected UID 0 transitions.

ADR detects and responds to runtime exploitation attempts as they happen, reducing the window between privilege escalation and security team response.

Attack Chain Analysis shows how an initial foothold combines with CVE-2026-31431 to compromise a Kubernetes node, CI runner or shared Linux host. That context helps teams prioritize patching based on actual attack paths, not only vulnerable kernel presence.

Frequently Asked Questions

These FAQs cover what CVE-2026-31431 is, which Linux environments are affected, how to verify exposure, and how to respond. Copy Fail is a Linux kernel vulnerability, so exposure depends on the running kernel version, not application package versions.

1. What is CVE-2026-31431 (Copy Fail)?
   CVE-2026-31431, branded Copy Fail, is a Linux kernel local privilege escalation vulnerability disclosed by Theori researchers on April 29 to 30, 2026. The flaw allows any authenticated local user to gain root access by abusing improper memory handling during kernel copy operations. The CVSS rating is 7.8 HIGH.
2. Which Linux distributions are affected by Copy Fail?
   Confirmed affected environments include multiple Ubuntu LTS releases prior to the May 2026 patch, CloudLinux, and general upstream Linux kernel builds. Talos Linux is largely unaffected per Sidero Labs analysis. Verify the running kernel version against your vendor advisory rather than assuming the OS version alone is sufficient.
3. How do I know if my environment is vulnerable to CVE-2026-31431?
   Check the running kernel version on every Linux host with uname -r and compare it against your distribution’s security advisory. Vulnerability scanners that use CVE feeds can also flag affected hosts. Patch status does not prove whether exploitation occurred, so audit for unexpected privilege transitions during the disclosure window.
4. Is there a public proof of concept for Copy Fail?
   Yes. A public PoC is available on GitHub under rootsecdev/cve_2026_31431, and CISA / Canadian Centre for Cyber Security advisories confirm active exploitation. Treat the gap between disclosure and patch as an active exposure window, especially on shared Linux hosts, CI runners, and Kubernetes worker nodes.
5. How does Copy Fail differ from other Linux LPE vulnerabilities?
   Copy Fail abuses kernel memory copy operations specifically. In the published PoC path, common kernel mitigations such as KASLR and SMEP do not block reliable exploitation. The exploit requires only authenticated local access with no elevated privileges, no kernel modules, and no special capabilities.
6. Can EDR or container security tools detect Copy Fail exploitation?
   Signature-based tools may detect the public PoC binary if it is run unmodified, but modified or recompiled variants require behavioral detection. Stronger signals include unexpected UID 0 transitions, anomalous syscall sequences, capability changes, and root shells spawned from low-privileged users, containers, or CI jobs.
7. What is the fastest way to remediate CVE-2026-31431?
   Apply the kernel patch from your Linux distribution, restart the affected system to load the patched kernel, and verify the running kernel version after reboot. Patching without a reboot does not protect the host. Rotate credentials that were accessible from any host running an unpatched kernel during the exposure window.
8. How does Copy Fail impact Kubernetes and multi-tenant environments?
   On Kubernetes worker nodes, successful exploitation can give an attacker full node control, access to pod-mounted secrets, service account tokens, and pivot paths toward other workloads or the control plane. On multi-tenant VMs and shared CI runners, the blast radius extends across every workload and credential exposed to the affected host.

References

1. Bugcrowd. April 29, 2026. What we know about Copy Fail (CVE-2026-31431). Bugcrowd.
2. Canonical Ubuntu. April 30, 2026. Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability. Canonical Ubuntu.
3. CloudLinux. April 30, 2026. CVE-2026-31431 (Copy Fail): Mitigation and Upcoming Patches for CloudLinux. CloudLinux.
4. CloudLinux. May 1, 2026. CVE-2026-31431 (Copy Fail): Kernel Update on CloudLinux. CloudLinux.
5. CloudLinux. May 1, 2026
6. Infosecurity Magazine. May 1, 2026. Nine-Year-Old Zero-Day Flaw in Linux Kernel Discovered by AI-Equipped Security Researcher. InfoSecurity Magazine.
7. Microsoft. May 1, 2026. CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments. Microsoft.
8. NIST. April 22, 2026. CVE-2026-31431 Detail. NVD.
9. Rootsecdev. April 29, 2026. cve_2026_31431. GitHub.
10. Sidero. April 30, 2026. Exploit Fail: Why CVE-2026-31431 (Copy Fail) barely scratches Talos Linux. Sidero.
11. Sophos. May 1, 2026. Proof-of-concept exploit available for Linux 'Copy Fail' vulnerability (CVE-2026-31431). Sophos.
12. The Hacker News. May 3, 2026. CISA Adds Actively Exploited Linux Root Access Bug CVE-2026-31431 to KEV. The Hacker News.
13. Theori. April 29, 2026. Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. Xint Code.