Copy Fail (CVE-2026-31431): Linux Kernel LPE & Container Escape — QMasters Threat Advisory

Copy Fail (CVE-2026-31431): Linux Kernel LPE & Container Escape — QMasters Threat Advisory

TLP:AMBER · Priority: PATCH NOW · Advisory v3.0 · Date: May 2, 2026

CVE-2026-31431, named Copy Fail, is a Linux kernel local privilege escalation and container escape vulnerability disclosed on April 29, 2026. It abuses the algif_aead AF_ALG interface to write four attacker-controlled bytes directly into the kernel page cache. The result: any unprivileged local user becomes root in milliseconds, the on-disk file is never modified, and on multi-tenant Kubernetes nodes the corruption crosses container boundaries without a traditional escape. CVSS is 7.8 HIGH. Every major Linux distribution shipped since August 2017 is affected. Patches are available from every vendor — apply them this week.

If you operate Linux servers, container clusters, CI/CD runners, or shared-hosting infrastructure, this is the most consequential local-privilege-escalation bug in years. Here is the full QMasters playbook: what it is, how the exploit works, what to detect, and what we are doing for protected customers right now.

Bottom line for executives: A 732-byte Python script grants root from any unprivileged user account on every supported Linux distribution. The exploit leaves no on-disk forensic trace and bypasses file-integrity monitoring. Combined with any initial-access vector — a phished SSH foothold, a web RCE, a poisoned CI runner — the attacker gets root and, in container environments, can pollute the in-memory copy of shared libraries across co-resident tenants. Patch the kernel, or blacklist the module, before the weekend.

At a glance

| Field | Value |

| --- | --- |

| CVE | CVE-2026-31431 ("Copy Fail") |

| Class | Local Privilege Escalation + Container Escape |

| CVSS v3.1 | 7.8 HIGH — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |

| EPSS | < 1st percentile at disclosure (PoC-just-published artifact) |

| CISA KEV | Not yet listed. CISA ADP: Exploitation = PoC, Automatable = No, Technical Impact = Total |

| Affected | Linux kernel 4.14+ since August 2017 — Ubuntu, RHEL/Rocky/Alma, SUSE, Debian, Amazon Linux, CloudLinux |

| Auth required | Any unprivileged local user (PR:L) |

| Reliability | Deterministic — same 732-byte Python script works unmodified across every major distro |

| Stealth | Page-cache only. No on-disk change. Bypasses AIDE, Tripwire, debsums, rpm -Va |

| CrowdStrike intel | CSA-260589 — "Exploitation Trivial and Almost Certain" (Apr 30, 2026) |

| Detection content | Falcon Rapid Response Content 2026.04.30.0439 + custom IOAs in this advisory |

How the exploit works (in plain language)

The Linux kernel offers a userspace crypto interface called AF_ALG. Inside it, a 2017 performance optimization let cryptographic operations work in place — the same memory region was used as both input and output buffer. That optimization quietly placed live page-cache pages into a writable kernel scatterlist.

The authencesn template — used in IPsec ESN authentication — writes 4 bytes of internal scratch data (the sequence-number-low field) just past its output buffer boundary. When the buffer is short enough, those 4 bytes land in the next page, which now happens to be a page-cache page belonging to a real file the attacker can read.

So an unprivileged user can:

1. Open an AF_ALG socket bound to authencesn(hmac(sha256),cbc(aes)).
2. splice() from a target file (say /etc/passwd) into the socket.
3. Trigger decryption with a crafted AAD; authentication fails and returns EBADMSG, but the 4-byte scratch write persists in the page cache.
4. Modify the UID field of a user account in /etc/passwd from 1000 to 0000.
5. Run su that-user. PAM validates the password against /etc/shadow (still untouched). The kernel reads UID 0 from the corrupted page cache. Root shell.

The disk file is never modified. File integrity monitors see nothing. Only a reboot or a POSIX_FADV_DONTNEED clears the corruption.

This is what makes Copy Fail unusual: it is a write primitive into kernel-managed memory of files the attacker can read. The cleanest LPE primitive we have seen since Dirty Pipe.

Why containers make this much worse

Container runtimes — runc, containerd, CRI-O — share read-only base-image files at the kernel page cache layer. When 12 pods on the same Kubernetes node mount the same ubuntu:24.04 base, the kernel keeps one copy of /lib/x86_64-linux-gnu/libc.so.6 in the page cache and hands every container a read-only view of it.

If a container in tenant A corrupts those pages, the corruption is visible to every container on that node — including tenants B, C, and D. There is no traditional container escape required, because the data is already shared.

Multi-tenancy failure mode. An attacker who lands one local-user execution slot in one tenant's container can pollute the in-memory image of a shared library across every co-resident tenant for the entire page-cache reclaim window. This is not just a privilege escalation bug. It is a cross-tenant data-integrity failure. — Vulnios Investigation No. 001

Vulnios models the practical blast radius as the intersection of three factors: containers per host sharing the corrupted layer (median in Kubernetes clusters: 6–14 sibling pods share at least one base layer) × processes per container that read or exec the corrupted file (for libc or shell: every container, continuously) × time-to-detection (corrupted pages persist for hours to days on busy hosts with low memory pressure).

For our customers running Kubernetes — and especially those running mixed-tenant clusters or sharing nodes between dev and prod — this is the failure mode we are sizing the response around.

What we are doing for protected customers right now

QMasters' StrongHold MCSS ran the Copy Fail playbook on the morning of April 30, 2026 — within hours of the Theori/Xint disclosure. Three coordinated actions:

1. Detection content deployed. All CrowdStrike-protected estates received Rapid Response Content 2026.04.30.0439 automatically. Our SOC layered the custom IOAs in section 4 below on top, scoped per customer. QRadar customers received the four custom rules in section 5.

2. Retroactive hunt. Our 16-analyst SOC ran the full hunt query set across the prior 30 days of customer telemetry — every Falcon ProcessRollup2 event with a python3 parent invoking su or sudo, every QRadar audit log with an AF_ALG socket family, every Linux command-line containing authencesn or algif_aead. No prior exploitation found across protected fleets. The hunt is now a standing daily query in DailyIOC.

3. Customer notifications. Every customer received a structured advisory by 09:00 IDT on May 1: affected asset count from Falcon Exposure Management, patch status by host, and our recommended mitigation cadence. No advisory inbox. No vague "review when convenient." A specific patch list for a specific customer.

If you are not seeing this kind of response from your current MDR provider on this CVE, talk to a QMasters SOC analyst. The 60-minute response loop is what an MDR is supposed to deliver.

Evidence and IOCs

Behavioral indicators

| Indicator | Pattern | Confidence |

| --- | --- | --- |

| AF_ALG socket | socket(38, 5, 0) + bind("aead", "authencesn(hmac(sha256),cbc(aes))") | HIGH — extremely rare outside IPsec ESN |

| Exploit command-line | python3 with arguments matching copy.?fail, cve.?2026.?31431, or authencesn | HIGH |

| Syscall sequence | socket(38,5,0) → bind → sendmsg(MSG_MORE) → splice → recv | HIGH |

| Process chain | python3 → su or sudo (parent → child) | HIGH when correlated with AF_ALG |

| Target files | /usr/bin/su, /usr/bin/sudo, /etc/passwd | MEDIUM (needs AF_ALG context) |

| Post-exploitation | UID 0 shell from a non-root user account | HIGH |

| Module load | algif_aead module loaded on a system where it was blacklisted | HIGH — mitigation bypass attempt |

Log artifacts to capture

• auditd: SYSCALL records for socket(family=38), splice(), and execve(/usr/bin/su) from the same PID/session. Keys: arch=b64, syscall=41 (socket), syscall=275 (splice), a0=26 (AF_ALG = 38 decimal).
• Falcon telemetry: ProcessRollup2 events showing the python3 → su chain. The native IOA fires as Detection - High with action Process Killed.
• syslog / auth.log: Successful su for a user whose UID was modified — PAM validates the password against /etc/shadow (untouched) but grants UID 0 from the corrupted page cache.

CrowdStrike Falcon — detection and response

Native coverage shipped April 30

Per CrowdStrike Trending Threats:

• Endpoint IOAs. New IOAs deployed automatically for Linux. They detect Python script execution attempting to exploit CVE-2026-31431. Process tree shows Detection - High with action Process Killed.
• Rapid Response Content. Package 2026.04.30.0439. Confirm sensors have updated to this content version — falconctl -g --rfm-state plus a Falcon Console sensor health check is the fastest sweep.
• Falcon Exposure Management. Filter CVE-2026-31431 in Exposure Management → Vulnerability Management → Vulnerabilities. Reports all instances including backported fixes per distro.
• Falcon Cloud Security. Image Assessment coverage for vulnerable kernels in container images. Navigate to Cloud Security → Vulnerabilities → Image Assessments → Image Vulnerabilities and filter on CVE ID 2026-31431.
• Falcon Intel Brief. CSA-260589 — "Recently Disclosed Linux LPE Allows Unprivileged Local Users to Gain Root; Exploitation Trivial and Almost Certain" (April 30, 2026).

CQL threat-hunting queries

For Advanced Event Search, NG-SIEM, or LogScale. Field names may need adapting to your environment.

Query 1 — AF_ALG exploit script detection

#event_simpleName=ProcessRollup2 event_platform=Lin
| ImageFileName=/python3/
| CommandLine=/(?i)(copy.?fail|authencesn|algif_aead|AF_ALG)/
| select([aid, ComputerName, UserName, ImageFileName, CommandLine, ParentProcessId, timestamp])
| sort(timestamp, order=asc)

High-signal. Hunts for python3 with command-line references to the exploit name, CVE ID, or crypto algorithm.

Query 2 — python → su/sudo post-exploitation chain

#event_simpleName=ProcessRollup2 event_platform=Lin
| ParentBaseFileName=/python3/
| ImageFileName=/(^\/usr\/bin\/su$|^\/usr\/bin\/sudo$)/
| select([aid, ComputerName, UserName, ParentBaseFileName, ImageFileName, CommandLine, UID, timestamp])

Detects post-exploitation process chains. Very low false-positive rate in production environments.

Query 3 — anomalous setuid execution after script activity

#event_simpleName=ProcessRollup2 event_platform=Lin
| ImageFileName=/(su$|sudo$|passwd$)/
| UserName!=root
| UID=0
| select([aid, ComputerName, UserName, UID, ImageFileName, ParentBaseFileName, CommandLine, timestamp])

Broader hunt: any non-root user executing setuid binaries that result in UID 0. Correlate with AF_ALG activity within the same session.

Query 4 — container-context exploit detection

#event_simpleName=ProcessRollup2 event_platform=Lin cid=*
| ImageFileName=/python3/
| CommandLine=/(?i)(authencesn|splice|AF_ALG|copy.?fail)/
| ContainerInfo.ContainerId=*
| select([aid, ComputerName, ContainerInfo.ContainerId, ContainerInfo.ImageId, UserName, CommandLine, timestamp])

Container-scoped. Identifies exploit attempts inside containers — critical for catching cross-container page-cache attacks on Kubernetes nodes.

Custom IOA recommendation

In addition to the native IOAs deployed via Rapid Response Content, deploy this custom IOA via Falcon Console → Configuration → Custom IOAs:

• Name: AF_ALG Crypto Socket from Scripting Interpreter
• Platform: Linux
• Type: Process Creation
• Severity: Critical
• Condition: ParentImageFileName contains python3 AND (CommandLine matches authencesn OR CommandLine matches algif_aead)
• Action: Detect + Prevent (kill process)

This catches variants that rename the exploit script — the most common evasion pattern we expect to see once weaponization begins.

QRadar — SIEM correlation

For QMasters customers running IBM QRadar on the StrongHold MCSS stack, our detection engineering team published the following four custom rules.

Rule 1 — Suspicious AF_ALG socket from non-system user

When an event matches auditd SYSCALL with syscall=41 AND a0=26 (AF_ALG, family 38), AND the source user is not in the system_users reference set, AND the parent process is in the scripting_interpreters reference set (python, perl, ruby*) — generate a Critical offense.

Rule 2 — Privilege-escalation chain: scripting interpreter to setuid binary

When two events occur within 60 seconds on the same host: (a) a scripting interpreter spawns, (b) /usr/bin/su or /usr/bin/sudo is executed by the same session — generate a High offense. Aggregates well with rule 1 for full chain detection.

Rule 3 — UID transition without /etc/shadow read

When a setuid(0) succeeds for a process whose recent ancestry includes a scripting interpreter, AND there is no corresponding read of /etc/shadow in the same session — generate a Critical offense. This is the page-cache UID corruption signature: shadow validates the password, but UID came from the corrupted passwd page.

Rule 4 — algif_aead module load on hardened host

When a kernel: event indicates algif_aead module load on a host in the hardened_hosts reference set (where the module was blacklisted) — generate a Critical offense. Catches mitigation bypass attempts.

We are publishing the full QRadar AQL and rule XML to existing customers via the StrongHold MCSS portal. If you would like the same content for self-managed QRadar deployments, our SIEM and automation practice can walk you through the integration.

Mitigation and remediation

1. Patch (preferred)

| Distribution | Patch command | Verify |

| --- | --- | --- |

| Ubuntu | apt update && apt upgrade linux-image-$(uname -r) | apt-cache policy linux-image-$(uname -r) |

| RHEL / Rocky / Alma | dnf update kernel && reboot | rpm -q --changelog kernel \| head -40 |

| SUSE | zypper update kernel-default && reboot | zypper se -s kernel-default |

| Debian | apt update && apt upgrade linux-image-$(uname -r) | apt-get changelog linux-image-amd64 |

| Amazon Linux | yum update kernel && reboot | dnf updateinfo info ALAS-XXXX |

| CloudLinux | kcarectl --update (KernelCare livepatch — no reboot) | kcarectl --info |

Reboot the host. The patch reverts the in-place AEAD optimization that made the primitive possible.

2. Immediate workaround — module blacklist

If you cannot patch and reboot today, blacklist the algif_aead module. CERT-EU's recommended mitigation closes the attack surface completely:

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

Functional impact: None on dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. Only applications explicitly using the AF_ALG afalg engine for AEAD are affected — extremely rare outside dedicated VPN gateways. Verify with lsof | grep AF_ALG before applying in a regulated environment.

3. For Kubernetes clusters

Deploy a DaemonSet that blacklists the module on all nodes. OVHcloud has published a reference manifest using priorityClassName: system-node-critical — link in the references section. If you run mixed-tenant or production-shared nodes, treat this as the highest-priority Kubernetes operational change of the quarter.

4. Verify before declaring done

The non-destructive safe detector from rootsecdev is the cleanest way to confirm a host is no longer vulnerable. Exit code 0 = not vulnerable; exit code 2 = still vulnerable. It uses a sentinel file and never touches system binaries — safe to run in production.

What every CISO should take from this

Three operational lessons, none of them new but all of them sharper after Copy Fail:

Linux is not a quiet operating system anymore. Every cluster, runner, container, and VM is a privilege-escalation target the moment any unprivileged code lands. The threat model that put all the eggs in prevent initial access now needs the second basket — contain post-compromise — at the kernel and container layer.

File-integrity monitoring is necessary but not sufficient. Copy Fail is the second high-impact bug in three years (after Dirty Pipe) where the on-disk file is never modified. AIDE, Tripwire, and rpm -Va will see nothing. The page cache is the new battleground, and you need EDR telemetry — process tree, syscall context, parent-child chains — to catch what file hashes miss.

Container isolation is a budget, not a guarantee. Kernel page-cache sharing is a feature, not a bug, but it means container boundaries do not stop kernel-memory primitives. If you are not running a CNAPP or CWPP that watches kernel-level container behavior, you are flying half-blind. Our cloud security and CNAPP solutions cover exactly this layer.

Soft CTA

If you are reading this and your current MDR provider has not contacted you about CVE-2026-31431 with a specific patch list and detection coverage by close of business, that is the test StrongHold MCSS was built to pass.

FAQ

Q: Is CVE-2026-31431 being exploited in the wild?

A: As of May 1, 2026 there are no confirmed in-the-wild campaigns, but the public proof-of-concept is production-grade and CrowdStrike's CSA-260589 brief assesses exploitation as "trivial and almost certain." Plan your patch cadence as if weaponization has already occurred. Historical precedent — Dirty Pipe — saw working exploits the same day as disclosure.

Q: Which Linux distributions are affected by Copy Fail?

A: Every major distribution shipped since August 2017 with kernel 4.14 or later — Ubuntu (except 26.04 Resolute), RHEL 7 through 10.1 and derivatives (Rocky, Alma), SUSE and openSUSE, all supported Debian, Amazon Linux 2 and 2023, and CloudLinux 7h through 10. Patches are available from every vendor.

Q: Why is this worse on Kubernetes than on standalone servers?

A: Container runtimes share read-only base-image files at the kernel page cache layer. A successful exploit in one tenant's container can corrupt the in-memory copy of a shared library across every co-resident container on the same node — no traditional container escape required. Vulnios models the median Kubernetes node as having 6 to 14 sibling pods sharing at least one base layer.

Q: What is the immediate workaround if I cannot patch right now?

A: Blacklist the algif_aead kernel module. Run echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf and then sudo rmmod algif_aead. CERT-EU has confirmed there is no impact on dm-crypt, kTLS, IPsec, OpenSSL, GnuTLS, or SSH. Only applications using the AF_ALG afalg engine for AEAD are affected — rare outside dedicated VPN gateways.

Q: What does QMasters do for customers when an advisory like this lands?

A: Within 60 minutes of disclosure: pull the published IOCs into our DailyIOC feed for enforcement at every customer egress point, deploy CrowdStrike custom IOAs and QRadar custom rules to the StrongHold MCSS detection stack, run a retroactive 30-day hunt across customer telemetry, and push a customer-facing notification with patch status and detection coverage. No "review when convenient." A specific patch list for a specific customer.

Q: Will CrowdStrike Falcon block this exploit by default?

A: Yes — CrowdStrike has shipped Rapid Response Content 2026.04.30.0439 with new IOAs that detect Python script execution attempting to exploit CVE-2026-31431, and the action is Process Killed. Confirm your sensors have the updated content version, and layer the custom IOA in section 4 above for variants that rename the exploit script.

Talk to QMasters

If you are running Linux at scale — whether on bare metal, VMs, or Kubernetes — and you want a 60-minute response posture for the next CVE like this one, talk to a QMasters SOC analyst or call our incident response line. We will walk through your CrowdStrike, QRadar, and cloud telemetry coverage and tell you exactly what we would have done with Copy Fail in your environment.

References

| Source | URL |

| --- | --- |

| NVD entry | https://nvd.nist.gov/vuln/detail/CVE-2026-31431 |

| Official advisory site | https://copy.fail/ |

| Theori / Xint disclosure | https://xint.io/blog/copy-fail-linux-distributions |

| Primary PoC (Theori) | github.com/theori-io/copy-fail-CVE-2026-31431 |

| Kubernetes container-escape PoC | github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC |

| Safe (non-destructive) detector | github.com/rootsecdev/cve_2026_31431 |

| Detection rules (Insomnisec) | github.com/insomnisec/Detections-CVE-2026-31431 |

| CERT-EU Advisory 2026-005 | cert.europa.eu/publications/security-advisories/2026-005 |

| Vulnios Investigation No. 001 | vulnios.com/premium-library/copy-fail-cve-2026-31431 |

| CrowdStrike Trending Threats | supportportal.crowdstrike.com — Trending Threats Linux Copy Fail |

| CrowdStrike CSA-260589 | Falcon Console → Intelligence → Reports → CSA-260589 |

| Ubuntu tracker | ubuntu.com/security/CVE-2026-31431 |

| Debian tracker | security-tracker.debian.org/tracker/CVE-2026-31431 |

| RHEL Bugzilla | bugzilla.redhat.com/show_bug.cgi?id=2460538 |

| SUSE tracker | suse.com/security/cve/CVE-2026-31431 |

| Amazon Linux | explore.alas.aws.amazon.com/CVE-2026-31431.html |

| CloudLinux mitigation | blog.cloudlinux.com — copy-fail mitigation |

| OVHcloud Kubernetes mitigation | blog.ovhcloud.com — copy-fail K8s protection |

If this is relevant to your environment, browse QMasters, talk to us about our incident response playbook, or explore attack simulation.

---

Author · QMasters SOC Team — Threat Intelligence & Detection Engineering

Last updated · 2026-05-02

Reading time · 9 min

Classification · TLP:AMBER

Advisory version · 3.0