Path & Payload

The LPE AI Found and Fumbled: Breaking Down “Copy Fail” (CVE-2026-31431)

Maybe the attacker phished a contractor, maybe they exploited a vulnerable service on the perimeter, maybe they walked in with valid credentials. However they got in, local access on Linux means a shell. They run one command. A minute later, they have root — on nearly any Linux distribution built in the last nine years.

That's the core of CVE-2026-31431, dubbed "Copy Fail" by Theori, the security firm that found it. It’s a local privilege escalation flaw in the Linux kernel that can let an unprivileged local user become root on affected, unpatched systems. CISA added it to the Known Exploited Vulnerabilities catalog on May 2, 2026, and Microsoft has observed early exploitation activity, mostly around proof-of-concept testing. An upstream kernel fix existed before public disclosure, but distribution-level patch availability varied, creating a difficult window for defenders. The disclosure itself created its own set of problems — but more on that later.

What makes this vulnerability worth a detailed breakdown is the secondary story: AI touched every stage of this vulnerability's lifecycle, from discovery to disclosure to the flood of proof-of-concept exploits that followed — and at each stage, it degraded the signal defenders depend on to respond.

The Incident

The attack chain here is drawn from Theori's primary disclosure site and accompanying blog post, researcher commentary from Rapid7 and VulnCheck as reported by CyberScoop, the Microsoft Defender Security Research Team's writeup, the CERT-EU security advisory, and the CISA KEV catalog entry. No single named victim is identified in any of these sources. The chain reflects known exploitation behavior and the documented characteristics of the vulnerability — the specific technique in play, not a named breach.

Stage-by-Stage Walkthrough

Stage 1: Initial Access

ATT&CK: T1190 (Exploit Public-Facing Application), T1078 (Valid Accounts), T1566 (Phishing)

CVE-2026-31431 is a local privilege escalation vulnerability, which means it is not the entry point — it’s what happens after entry. An attacker needs authenticated local access to the target system before the kernel flaw is useful. That access can come from legitimate credentials, a separate vulnerability, or any other initial access technique.

Spencer McIntyre at Rapid7 described this as a meaningful limiting factor. He's right, but it's worth being precise about what it limits and what it doesn't. It just means that the LPE requires a prior foothold. For any organization where that foothold is achievable, the path to root is now significantly shorter.

The populations most at risk are systems where local code execution is already plausible: shared Linux hosts, developer workstations, CI/CD runners, Kubernetes nodes, bastion hosts, and environments with SSH access, shared accounts or weak credential hygiene.

Stage 2: Local Privilege Escalation to Root

ATT&CK: T1068 (Exploitation for Privilege Escalation)

Technically, the flaw sits in the Linux kernel’s crypto subsystem. The exploit can alter the in-memory version of a privileged file without changing the file on disk. If that target is a setuid-root binary such as /usr/bin/su, the attacker can turn a small page-cache corruption into a root shell — while ordinary file-integrity checks may still show the on-disk file as clean.

With a local shell, the attacker can run a small exploit script that turns limited access into root on affected, unpatched systems. Theori describes the escalation path as trivial and automation-friendly, meaning it doesn't require specialized expertise to execute once the initial foothold exists.

The scope is wide. Many mainstream Linux distributions running unpatched kernels with the affected code path are in range. This includes servers, workstations, and CI/CD runners — the systems where a local foothold can become infrastructure-level control.

Stage 3: Post-Exploitation

ATT&CK: T1053 (Scheduled Task/Job), T1070 (Indicator Removal), T1611 (Escape to Host)

With root achieved, the attacker's options expand significantly. Persistent access via cron jobs or startup scripts. Credential harvesting from system memory, SSH keys, and configuration files. Lateral movement across the network from a trusted, fully compromised host. Log manipulation to cover the escalation path.

Because the modification lives in memory rather than on disk, traditional file-integrity checks may not show that the privileged binary was altered. This makes runtime behavior and syscall-level monitoring more useful than relying only on checksum-based validation.

The container escape angle is worth calling out separately. Theori flagged implications for containerized environments including Kubernetes, which adds a meaningful dimension to the post-exploitation picture. A compromised, low-privileged container that can exploit this flaw to escape to the host represents a different threat model than a traditional LPE on a bare-metal server — particularly in multi-tenant environments where host-level access crosses trust boundaries.

Where Defenders Had a Window

There were at least three points in this chain where the outcome was interruptible.

1. Patch management before broad exploitation. An upstream kernel fix existed before the vulnerability drew broad public attention, but distribution-level patch availability varied. Organizations with rapid kernel patching or interim mitigations had the best chance of reducing exposure before broad public exploit activity. That window was uneven: some teams could patch quickly, while others first had to determine whether their distribution had shipped a fixed kernel package.

2. Auditing for unexpected privilege escalation. Tools like auditd, Falco or EDR/runtime sensors can help surface unusual escalation paths. Useful signals include unexpected AF_ALG socket creation, suspicious use of splice() in combination with crypto interfaces, and unprivileged processes that suddenly execute as root outside a known administrative workflow. This needs tuning: some legitimate tools use AF_ALG, so the goal is not to alert on the interface alone, but on unusual combinations of process, syscall and privilege behavior.

3. Local access restrictions. The foothold requirement is only a limiting factor if local access is genuinely limited. Organizations with strong least-privilege enforcement, no shared local accounts, and controlled remote access have a significantly reduced exposure surface. The vulnerability can't be weaponized by someone who can't get in.

The disclosure itself didn’t give defenders a clean read. Between Theori's AI-generated blog post, the intentional withholding of technical specifics, and the subsequent flood of AI-generated PoC exploits, security teams trying to assess and prioritize had to do significant independent validation work. That validation burden was a cost imposed by the disclosure approach, not by the vulnerability itself.

Technique in Focus: LPE via Kernel Exploitation — and What AI Did to the Signal

T1068: Exploitation for Privilege Escalation

Local privilege escalation through kernel exploitation is not new. What's worth examining here is the combination of factors that made the response environment unusually difficult.

Theori used AI to discover the vulnerability — specifically their penetration testing platform, Xint. They also used AI to produce the disclosure site and the blog post. The result was a disclosure that researchers at VulnCheck publicly described as "AI slop": high on language, low on technical specifics. Caitlin Condon at VulnCheck noted that teams had to do additional validation to separate legitimate risk from what she called AI-generated fear, uncertainty and doubt.

This is a big deal because disclosure quality has direct operational consequences. A rigorous disclosure gives defenders the information they need to triage, prioritize, and validate their own exposure. A thin disclosure forces them to reconstruct what the disclosing researchers didn't provide. Disclosing researchers may intentionally withhold some detail, but when the disclosure is thin because the AI generation process couldn’t produce depth, that's a problem.

It happens because AI can only synthesize what exists. If the underlying technical work wasn't complete, wasn't documented in sufficient depth, or just wasn’t input into the AI system, no amount of language generation closes that gap. Theori's disclosure wasn't thin because the AI wrote badly — it was likely because it didn’t have enough raw material to work from. Everything downstream, including the hundreds of derivative PoCs that followed, was elaborating on a surface without a substrate.

The downstream effect was predictable. Within five days of publication, hundreds of proof-of-concept exploits appeared — most of them AI-generated from the original. Condon's characterization: CLI banner changes, color modifications, ports to different programming languages. The aesthetic of a working exploit without the validation. Security teams trying to find usable technical information were now sorting through an ecosystem where most artifacts were noise.

AI is increasingly embedded in vulnerability research workflows. This will produce more discoveries, but it’s also going to produce more of this — confident-sounding output that degrades rather than improves the information environment when rigor is missing.

Takeaway for Defenders

The foothold requirement is real, but it's not a reason to deprioritize action. If your kernel packages are unpatched, CERT-EU's advisory provides a tested interim mitigation: disable the algif_aead module persistently by running:

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

CERT-EU confirms this does not affect dm-crypt/LUKS, kTLS, IPsec, OpenSSL, GnuTLS, NSS, or SSH. For containerized environments, blocking AF_ALG socket creation via seccomp policies on all workloads prevents exploitation even on unpatched kernels — since opening an AF_ALG socket is the exploit's first step.

Then audit your privilege escalation monitoring and your local access hygiene.

On the disclosure problem: treat AI-generated exploit code from this wave as unverified until a credible independent researcher validates it. Running untested PoC artifacts in production-adjacent environments is always a risk, and right now the Copy Fail PoC ecosystem is mostly noise.

Sources

#Attack Chain Breakdowns