The Short Version
A 732-byte Python script gives root on every mainstream Linux distribution released since 2017. No race conditions. No kernel offsets. No special privileges needed. Just an unprivileged local user account. The exploit works unmodified across all affected distributions and delivers both container escape and privilege escalation in a single payload.
The vulnerability is tracked as CVE-2026-31431. The disclosure site is copy.fail.
How It Works (Plain Language for CISOs)
The bug is a logic flaw in authencesn, a module in the Linux kernel crypto API. The exploit chains through AF_ALG (a socket interface for kernel cryptographic operations) and splice() (a zero-copy data transfer syscall) to achieve a 4-byte write into the page cache.
The root cause is a 2017 optimization in algif_aead that allowed page-cache pages to enter the writable destination scatterlist during in-place encryption operations. This is not a timing bug or a race condition. It is a straightforward logic flaw that has been sitting in the kernel for nine years.
- Vulnerable component
algif_aeadin-place optimization (Linux kernel crypto API)- Introduced
- 2017 kernel commit adding algif_aead optimization
- Exploit primitive
- 4-byte page-cache write via AF_ALG + splice()
- Prerequisite
- Any process that can open an AF_ALG socket (any unprivileged user)
- Exploit size
- 732 bytes of Python
- Fix
- Mainline kernel commit
a664bf3d603d
The exploitable condition is available to any process that can open an AF_ALG socket. On every mainstream Linux distribution, that means any unprivileged user.
What Is Affected
Every mainstream Linux distribution released since 2017. That includes:
- Multi-tenant systems: shared dev boxes, CI/CD runners, university servers, cloud VMs with multiple user accounts
- Kubernetes clusters: a compromised pod can escape to the host node
- Docker and Podman containers: this is a container escape, not just container root. The attacker breaks out to the host.
- Cloud environments: AWS EC2, GCP Compute Engine, Azure VMs running unpatched kernels
- CI/CD runners: GitHub Actions self-hosted runners, GitLab runners, Jenkins agents. These often execute untrusted code with local user access.
Single-user desktop systems are lower risk unless chained with a remote access vector. But if an attacker already has a low-privilege shell on your Linux box through any means, this gives them root instantly.
Who Found It
Security researcher Xint Code discovered the vulnerability through automated analysis of the Linux crypto/ subsystem. Responsible disclosure led to the assignment of CVE-2026-31431. The full disclosure is at copy.fail.
The Fix
The mainline kernel commit a664bf3d603d reverts the problematic 2017 algif_aead optimization. Check your distribution's security advisory for the patched kernel version.
Temporary Mitigation (No Reboot Required)
Disable the algif_aead module immediately on production systems:
echo "install algif_aead /bin/true" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo modprobe -r algif_aeadThis prevents the module from loading. The permanent fix is a kernel update from your distribution vendor.
What You Should Do Right Now
Seven steps. Do them in order.
- Check if the module is loaded. Run
lsmod | grep algif_aeadon every Linux system you manage. If it returns output, that system has the vulnerable module active. - Check your kernel version. Compare against your distribution's patched version list. Ubuntu, Debian, RHEL, SUSE and Arch all have security advisories for this CVE.
- Apply the modprobe mitigation immediately. On every production system where the module is loaded, run the disable commands above. This buys you time while you schedule kernel updates.
- Schedule kernel updates across your fleet. This is the permanent fix. Coordinate maintenance windows.
- Audit container orchestration. If you run multi-tenant Kubernetes, this is critical. A compromised pod can escape to the host. Review pod security policies, network policies and node isolation.
- Review local user access. Who has shell access to your Linux systems? Every local user account is a potential exploit vector for this vulnerability.
- Check CI/CD runners. Self-hosted runners that execute code from pull requests or merge requests are high-value targets. If an attacker can submit code that runs on your runner, they can root the host.
Why This Matters for Your Organization
If you run containers in production, this is a container escape. Your container isolation boundary is broken on unpatched kernels.
If you run shared CI/CD, anyone who can push code can root the runner. That includes external contributors submitting pull requests to public repositories.
If you run Kubernetes, a compromised pod escapes to the host node. From there, the attacker has access to every other pod on that node, the kubelet credentials and potentially the entire cluster.
Nine years undetected means your vulnerability scanners did not catch it either. This is the kind of bug that automated tools miss because it requires understanding kernel subsystem interactions, not just pattern matching against known signatures.
This is exactly why penetration testing includes kernel-level checks and why container security assessments need to go deeper than Dockerfile linting.
The Bigger Picture
copy.fail is a reminder that container isolation is only as strong as the kernel it runs on. Namespaces, cgroups and seccomp profiles are userspace boundaries enforced by kernel code. When the kernel has a logic flaw that predates your container platform, those boundaries fail silently.
Organizations that rely on container isolation as a security boundary without validating the underlying kernel should treat this as a wake-up call. If your security model assumes containers cannot reach the host, that assumption has been wrong for nine years on every unpatched system.