Intruvent EDGE: 732 Bytes to Root. A Nine-Year Linux Kernel Bug Just Went Public

CVE-2026-31431 turns nine years of Linux kernels into a one-command root shell

Apr 30, 2026

Welcome to Intruvent Edge, our bi-weekly technical deep dive into a current cyber threat. If you found us through Prevent This, our weekly community newsletter covering cybersecurity for everyone, you’re in the right place. Both live on the same Substack. Feel free to share either one. We’re glad you’re here!

The Vulnerability

Yesterday, security researchers at Theori published a complete privilege escalation exploit for CVE-2026-31431, a logic bug in the Linux kernel’s cryptographic subsystem that has existed since August 2017. The exploit is a 10-line Python script. It requires no compiled payloads, no version-specific offsets, and no race conditions. It works on every major Linux distribution released in the past nine years.

Every. Major. Linux. Distribution.

Linux runs approximately 96% of the world’s top one million web servers, the majority of cloud infrastructure, most containers and Kubernetes clusters, and billions of IoT and embedded devices. Conservative estimates place the affected device count in the billions. With a B.

This one is bad, and needs your attention.

The vulnerability, nicknamed “Copy Fail,” allows any unprivileged local user to gain a root shell in seconds. On a multi-tenant system, a shared Kubernetes cluster, or a CI/CD runner, that means any user with shell access can take complete control of the host.

A fully weaponized proof-of-concept is already public on GitHub. Exploitation at scale is now a matter of when, not if. If your home or work uses any affected systems, please read on. Please forward this to anybody who needs it.

How It Works

Caption suggestion: “CVE-2026-31431 exploitation flow: from AF_ALG socket to root shell in six steps.”

The bug lives in algif_aead.c, a component of the Linux kernel’s AF_ALG cryptographic socket interface. Specifically, it affects the authencesn algorithm, which handles authenticated encryption with sequence numbers for IPsec.

Three individually reasonable kernel changes created the vulnerability:

2011: The authencesn cryptographic wrapper was added for IPsec support
2015: AF_ALG gained AEAD (Authenticated Encryption with Associated Data) socket support, allowing userspace programs to invoke kernel crypto operations
2017 (kernel 4.14): An in-place optimization in commit 72548b093ee3 placed page cache pages directly into a writable scatterlist

That third change is the fatal one. When the kernel performs an AEAD decrypt operation, authencesn writes a 4-byte sequence number (seqno_lo) past the output buffer boundary via scatterwalk_map_and_copy(). Because the optimization placed page cache pages in the writable scatterlist, those 4 bytes land directly in the page cache.

The page cache is the kernel’s in-memory copy of file contents. Every executable you run, every library you load, comes from the page cache. If you can write arbitrary bytes into it, you can corrupt any readable file’s in-memory representation without touching the on-disk copy.

The exploit sequence:

Open an AF_ALG socket bound to authencesn(hmac(sha256),cbc(aes))
Use splice() to feed page cache pages of a setuid binary (such as /usr/bin/su) into the crypto pipeline
Construct sendmsg() with shellcode bytes positioned in the AAD at offsets 4 through 7
Issue recvmsg(), which triggers AEAD decrypt. The authencesn algorithm writes past the output boundary into the mapped page cache page
The HMAC verification fails and returns EBADMSG, but the write has already occurred and persists
Execute the corrupted setuid binary. The kernel loads it from page cache. Shellcode runs as root.

The entire sequence fits in 732 bytes of Python using only the os, socket, and zlibstandard library modules.

Why This Is Worse Than Dirty Pipe

Security professionals will immediately compare CVE-2026-31431 to Dirty Pipe (CVE-2022-0847) and Dirty COW (CVE-2016-5195), the two most notorious Linux kernel privilege escalation vulnerabilities of the past decade. Copy Fail is worse than both.

Dirty COW required winning a race condition. Exploitation was probabilistic and often crashed the target system. Copy Fail has no race condition. The exploit is deterministic and 100% reliable.

Dirty Pipe required knowledge of specific kernel version offsets and was limited to kernels 5.8 through 5.16 (roughly an 18-month window). Copy Fail requires no offsets and works across a nine-year window of kernel versions, from 4.14 through current mainline.

Both left forensic evidence that file integrity monitoring tools could detect. Copy Fail corrupts only the in-memory page cache. The page is never marked dirty for writeback, so the on-disk file remains pristine. Inotify sees nothing. AIDE sees nothing. OSSEC sees nothing. Tripwire sees nothing.

One additional dimension makes this especially dangerous in modern infrastructure: the page cache is shared across the entire host, including all containers running on that host. A process inside a Kubernetes pod can corrupt the page cache entry of a setuid binary on the host filesystem. Copy Fail functions as a container escape primitive that bypasses namespace isolation entirely.

What’s Affected

Every Linux distribution shipping a kernel from version 4.14 (August 2017) onward is vulnerable unless patched. Confirmed affected systems include:

Ubuntu 24.04 LTS (kernel 6.17.0-1007-aws)
Amazon Linux 2023 (kernel 6.18.8-9.213.amzn2023)
RHEL 10.1 (kernel 6.12.0-124.45.1.el10_1)
SUSE 16 (kernel 6.12.0-160000.9-default)
Rocky Linux 9.7 (confirmed independently by Solar Designer)
Debian, Arch Linux, Fedora, Oracle Linux
Embedded Linux distributions used in IoT, networking equipment, and industrial systems

Not affected: RHEL 6 and 7 (kernel versions predate the vulnerable commit), and Ubuntu 26.04 (Resolute) which ships a patched kernel.

Linux runs approximately 96% of the world’s top one million web servers, the majority of cloud infrastructure, most containers and Kubernetes clusters, and billions of IoT and embedded devices. Conservative estimates place the affected device count in the billions.

Detection Is Hard

Traditional security tooling is largely blind to this attack. The corruption happens entirely in kernel memory, with no disk writes, no file modifications, and no network traffic.

Will NOT detect exploitation:

File integrity monitoring (AIDE, OSSEC, Tripwire, Samhain)
Inotify-based watchers
Hash-based allowlisting tools
Standard auditd file access rules

CAN detect exploitation:

eBPF-based monitoring that tracks AF_ALG socket creation and splice() calls targeting setuid binaries
Falco/Sysdig rules detecting SOCK_SEQPACKET AF_ALG socket creation from unexpected processes
Auditd rules configured to audit socket() calls with AF_ALG family (family 38)
Behavioral detection looking for EBADMSG return codes from AEAD operations followed by execution of setuid binaries

A community detection toolkit is already available on GitHub, including Falco rules, auditd configurations, and an eBPF monitor.

The key behavioral sequence to detect:

AF_ALG socket creation by a non-root, non-crypto process
splice() calls feeding a setuid binary into that socket
recvmsg() returning EBADMSG
execve() of the same setuid binary shortly after

Any security operations team monitoring Linux hosts should deploy at minimum the auditd rule for AF_ALG socket creation today.

Patch and Mitigation

The Fix

The upstream kernel team committed the fix on April 1, 2026 (commit a664bf3d603d). The patch reverts algif_aead.c to out-of-place AEAD operation, permanently separating the TX scatterlist from the RX scatterlist so that page cache pages can never be placed in a writable context.

Patched kernel versions: 7.0+, 6.19.12+, 6.18.22+.

As of today, Debian, Ubuntu, and SUSE have issued patched packages. Red Hat initially deferred the patch but has since reversed course.

Interim Mitigation (If You Cannot Patch Immediately)

The simplest and most effective mitigation is to disable the algif_aead kernel module:

# Prevent the module from loading
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

# Unload if currently loaded
sudo rmmod algif_aead 2>/dev/null

This does NOT affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. Most systems never load this module at all. The only software that uses AF_ALG AEAD sockets is libkcapi and a small number of specialized cryptographic testing tools.

For containerized environments: Block AF_ALG socket creation via seccomp profiles on all pods, CI/CD runners, and container workloads. The exploit requires opening an AF_ALG socket as its first step; blocking that syscall prevents exploitation entirely.

{
  "names": ["socket"],
  "action": "SCMP_ACT_ERRNO",
  "args": [
    {
      "index": 0,
      "value": 38,
      "op": "SCMP_CMP_EQ"
    }
  ]
}

This blocks socket(AF_ALG, ...) calls. AF_ALG is protocol family 38.

Timeline

DateEventAugust 2017Vulnerable commit introduced in kernel 4.14March 23, 2026Theori reports vulnerability to Linux kernel security teamMarch 24, 2026Kernel team acknowledges the reportMarch 25, 2026Patches proposed and reviewedApril 1, 2026Fix committed to mainlineApril 22, 2026CVE-2026-31431 assignedApril 23, 2026NVD publishes CVE detailsApril 29, 2026Full public disclosure with proof-of-conceptApril 30, 2026CERT-EU publishes Security Advisory 2026-005

The 37-day window between the fix commit and public disclosure gave major distributions time to prepare patches. Whether your organization has applied them is another question.

Who Found It

Taeyang Lee of Theori, a South Korean security research firm, discovered the vulnerability. The Xint Code Research Team subsequently used AI-assisted analysis to scale the initial finding into a complete exploitation chain in approximately one hour, demonstrating how quickly modern tooling can weaponize a vulnerability once the root cause is understood.

Alexander Peslyak (Solar Designer), founder of the Openwall Project and one of the most respected voices in Linux security, independently confirmed exploitation on Rocky Linux 9.7.

What You Should Do Today

1. Check if you’re affected. Any system running a kernel from 4.14 onward that has not applied the latest security updates is vulnerable. Run uname -r and check against your distribution’s security advisory.

2. Apply patches if available. Debian, Ubuntu, and SUSE have issued fixes. If patched packages are available, apply them immediately. A public PoC exists and exploitation is trivial.

3. Deploy the module mitigation on unpatched systems. If you cannot patch within 24 hours, disable algif_aead with the modprobe rule above. This closes the attack vector at negligible operational cost.

4. Harden container workloads. Add AF_ALG socket blocking to your seccomp profiles. If you operate Kubernetes clusters, update your PodSecurityPolicies or OPA/Gatekeeper constraints to block protocol family 38.

5. Deploy detection. At minimum, add an auditd rule for AF_ALG socket creation. For higher-fidelity detection, deploy the eBPF monitor from the community toolkit.

6. Audit multi-tenant systems first. Shared hosting environments, CI/CD runners, Kubernetes clusters, and any system where untrusted users have shell access are the highest-priority targets. The vulnerability requires only local access.

7. Do not rely on file integrity monitoring. If your security strategy for Linux hosts depends primarily on hash-based FIM tools, this vulnerability bypasses that layer entirely. Update your detection architecture.

The Bigger Picture

Copy Fail is a reminder that kernel attack surface accumulates invisibly over time. The three code changes that created this vulnerability were each reasonable in isolation. The dangerous interaction between them went undetected for nine years, hidden behind a kernel subsystem that most security researchers never examine because “it’s just crypto plumbing.”

The exploit’s simplicity is the real story. A 10-line Python script with no dependencies achieving deterministic root on nine years of kernels is the kind of vulnerability that shifts the risk calculus for any organization running multi-tenant Linux infrastructure. Patch today.

Thanks for reading Intruvent Edge! This post is public so feel free to share it.

Sources

Free Linux Security Assessment

Copy Fail is the latest in a growing list of Linux kernel privilege escalations (Dirty COW, Dirty Pipe, StackRot, and now Copy Fail) that bypass traditional detection. If your organization relies on Linux for production workloads, we can help you assess your exposure.

Shoot us an email at: contact@intruvent.com to book a 30 minute assessment discussion.

We also offer:

Linux kernel vulnerability exposure assessments
Container security and Kubernetes hardening reviews
Detection engineering for kernel-level threats
Managed threat hunting across your Linux infrastructure

Discussion about this post

Ready for more?