Copy Fail (CVE-2026-31431): A 732-Byte Python Exploit Owns Your Linux Box And Walks Out Of Your Container. Patch By May 15.

Patrick Duggan
4 hours ago
7 min read

May 6, 2026 · DugganUSA LLC

CISA added CVE-2026-31431 to the Known Exploited Vulnerabilities catalog on May 1, 2026. The federal civilian executive branch patch deadline is May 15. The vulnerability is a Linux kernel local privilege escalation in the AF_ALG cryptographic subsystem that has been quietly present in shipped kernels since 2017, introduced through three separate commits in 2011, 2015, and 2017. Kaspersky named the bug Copy Fail. The working public exploit is 732 bytes of Python. There are also Go and Rust ports in open-source repositories. Our exploit harvester pulled fifteen variants in the last week.

If you operate Linux servers, container hosts, Kubernetes clusters, or any production workload running anything earlier than kernel 6.18.22 or 6.19.12 or 7.0, you have nine days from this post to be patched.

What Copy Fail Actually Does

The vulnerability lives in the kernel's AF_ALG socket family, which is the userspace interface to the kernel's cryptographic acceleration subsystem. AF_ALG is enabled by default on most Linux distributions and is exposed inside container namespaces by default if the algif_aead kernel module is loaded on the host (which it is on the vast majority of standard distributions).

The exploit chain, summarized: an unprivileged local user opens an AF_ALG socket, performs a sequence of operations through the algif_aead interface that triggers the underlying logic bug in the page cache handling code, and uses the resulting write primitive to modify the in-memory page cache of a privileged binary like /usr/bin/su without touching the binary on disk. The next time the modified binary is executed by any process, it runs the attacker's injected code with the binary's existing privileges. From an unprivileged shell to root in one syscall sequence.

The container-escape angle is what makes this one a four-alarm fire and not just a Linux LPE story. Containers do not have their own kernels. The kernel of the host is shared by every container running on the box. AF_ALG access is not namespaced and is granted inside containers by default. So a process inside an unprivileged container can use Copy Fail to escalate to root inside the container, then use the same primitive to modify host binaries via the shared page cache, and walk out of the container into the host with full root. Kaspersky's framing: "Copy Fail poses a risk of breaching container isolation and gaining control over the physical machine."

For Kubernetes shops, the implication is that any compromised pod on a node running an unpatched kernel can take over the node. From the node, the attacker has access to every other pod scheduled on that node, every secret mounted on the node, and the node's kubelet credentials, which depending on RBAC can pivot to the cluster control plane.

Why This One Hits Harder Than A Normal LPE

Three properties make Copy Fail unusually dangerous:

One, the exploit uses only legitimate syscalls. Every syscall in the chain is a normal thing a userspace cryptographic library might do. There is no shellcode, no ROP chain, no obvious red flag in the syscall trace. EDR products that look for anomalous behavior signatures have very little to grab onto. Microsoft Defender for Endpoint reported observing "preliminary testing activity" in the wild as of May 1, which is the language vendors use when telemetry is light and noise is high and they cannot yet characterize the activity precisely.

Two, the exploit is small. A 732-byte Python script is short enough to be inlined as a base64 blob in any phishing payload, any compromised dependency, any malicious container image. There is no large payload to defang. There is no signature to write. The signature is the behavior, and the behavior looks legitimate.

Three, the bug is old. The three commits that combined to produce the bug landed in 2011, 2015, and 2017. Every distribution that has been shipping kernels since 2017 is affected, which is essentially all of them. The patched versions (6.18.22, 6.19.12, and 7.0) are recent. Backports are landing for LTS distros but the rollout is not uniform across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Oracle Linux, container base images, embedded distributions, IoT firmware, and the long tail of unsupported but still production kernels. Every shop has at least one box on a kernel that will not get a backport.

The Hunt and the Mitigation Tonight

If you cannot patch in the next nine days, the immediate actions are smaller and uglier.

Step one: figure out where you are exposed. From any Linux host, run uname -r. If the kernel version printed is earlier than 6.18.22 in the 6.x line, or earlier than 6.19.12 in the 6.x line, or any 5.x or 4.x kernel, that host is vulnerable. (Some distributions backport the fix to older kernel versions; check your distribution's security advisory for the specific patched build number rather than the upstream version.)

Step two: check whether algif_aead is loaded. Run lsmod | grep algif_aead. If the module shows up in the output, the AF_ALG attack surface is live on that host. If it does not, the immediate exploitation path is blocked, but the module can be loaded on demand by any user that triggers a kernel cryptographic API that needs it (so this is a soft mitigation, not a fix).

Step three: blacklist the module on hosts where it is not actively needed. Drop a file at /etc/modprobe.d/blocklist-algif_aead.conf containing the single line: blacklist algif_aead. Then run modprobe -r algif_aead to unload the module from the running kernel. This breaks userspace cryptographic libraries that depend on AF_ALG (some openssl configurations, some libgcrypt configurations, some IPsec stacks). Test before deploying broadly.

Step four: enable auditd logging on AF_ALG socket creation by unprivileged users. The audit rule is: auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -F auid>=1000 -k afalg_use. The argument a0=38 is the AF_ALG socket family number; auid>=1000 limits the rule to genuine users (excluding system services). The key afalg_use makes the events queryable in your audit log aggregation. Any process belonging to a non-system user that opens an AF_ALG socket is suspect on a host that does not legitimately use kernel crypto from userspace.

Step five: for container fleets, audit your base images. Most standard base images (Debian slim, Alpine, Ubuntu minimal, distroless variants) inherit the host kernel and are therefore vulnerable through the host. The container itself cannot patch the kernel; only the host can. If you are running on managed Kubernetes (EKS, GKE, AKS), check the node image AMI / VHD versions against your provider's patch advisory and force a rolling node replacement onto patched node images if you are not on the latest version yet.

Step six: for the paranoid and the production-hardened, consider whether you actually need AF_ALG at all. Many workloads do not. If the workload is a web application, a database, an API server, or essentially anything that does not implement custom cryptography in C against the kernel crypto API, you can blacklist algif_aead and most of the algif_* family with no functional impact. The attack surface goes away entirely.

Detection For The Boxes You Cannot Patch In Time

The auditd rule above is the cheapest detection that catches active exploitation. The Falco and Tetragon eBPF rule equivalents are similarly short: alert on socket() calls with AF_ALG and uid >= 1000, plus alert on writes to the page cache addresses of any /usr/bin/su, /usr/bin/sudo, /usr/bin/passwd, or other suid binary from a non-root process.

For sysmon-for-Linux deployments, the equivalent event is process creation with the syscall trace showing socket(38, ...). The signal-to-noise on this depends entirely on whether your fleet legitimately uses AF_ALG. On most fleets, it does not, and the false-positive rate is low.

For SOC teams already using YARA rules on memory dumps, the published 732-byte Python PoC plus the larger Go and Rust variants are searchable as static strings; the harvester repos in our IOC index have the canonical filenames if you need a starting point for rule creation. The fifteen public exploit variants we have indexed share enough structure that a single rule covering the AF_ALG socket setup and the page cache write loop will catch most of them.

For network detection, the bad news is there is none. Copy Fail is local-only and operates entirely inside the kernel. Network telemetry will not see it. The detection has to be on the host.

The Supply Chain Angle

We pulled fifteen public exploit variants from GitHub in the last week alone. Some are PoCs from researchers. Some are weaponized droppers. Some are masquerading as patches (one repo named SunL0w/PATCH-CVE-2026-31431-Ubuntu_Debian is in our index; we have not verified whether it is a legitimate patch or an exploit pretending to be one — assume the latter until proven otherwise and do not run patch scripts from random GitHub repos against production kernels).

This is the Pattern 38 supply-chain risk that we have written about repeatedly: a high-profile CVE with a working PoC produces a flood of GitHub repos claiming to be exploits, scanners, patches, or "cleaners," and a non-trivial fraction of them are second-stage payloads. If you are looking for tooling to test or remediate Copy Fail, get it from CISA's published advisory, your distribution vendor, Kaspersky, Wiz, or the upstream kernel.org commits. Not from a freshly-created GitHub repo with a clever name.

Summary For The Person Reading This At 11pm

If your kernel is earlier than 6.18.22 or 6.19.12 or 7.0, you are vulnerable. The federal patch deadline is May 15. Public exploits are live in three languages. Container escape is the default behavior, not a special case. Patch tonight if you can. Blacklist algif_aead on every host where you cannot. Turn on the auditd rule everywhere. Replace any nodes in your container fleet that are running unpatched kernels.

The IOCs (PoC repo names, kernel version signatures, AF_ALG audit rules) are in our STIX feed at analytics.dugganusa.com/api/v1/stix-feed under the indicator type. Free public tier is twenty-five queries per day; that is enough to pull the Copy Fail set without paying us.

If you find Copy Fail behavior in your fleet and want a cross-check, we are at [email protected].

Receipts

CISA KEV addition for CVE-2026-31431 (May 1, 2026): cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog
Kaspersky threat analysis ("Copy Fail" naming and container-escape framing)
Wiz security research ("modifying [the page cache] effectively alters binaries at execution time without touching disk")
Microsoft Defender Security Research (preliminary testing activity observation)
Patched kernel versions: 6.18.22, 6.19.12, 7.0
Public PoC harvested by our exploit-harvester: fifteen GitHub variants indexed including MohamedKarrab/Copy-Fail-CVE-2026-31431, Sndav/CVE-2026-31431-Advanced-Exploit, iss4cf0ng/CVE-2026-31431-Linux-Copy-Fail
Federal civilian patch deadline: May 15, 2026
Our STIX feed: analytics.dugganusa.com/api/v1/stix-feed