A nine-year-old logic bug in the Linux kernel was publicly disclosed on April 29, 2026. It allows any unprivileged local user get root access. The attacker only needs a simple script, and they won't leave a single trace on disk.
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. It's a standardised ID system
that gives every publicly known security flaw a unique reference number so researchers,
vendors, and defenders are all on the same page when it comes to discussing them. The format is
CVE-[year]-[number]. The number doesn't imply severity. For that, there's
the CVSS score, which runs from 0 to 10. CVE-2026-31431 scores 7.8, which puts it in the
High tier.
What is Copy Fail?
Copy Fail is a local privilege escalation (LPE) vulnerability. That means it technically doesn't let someone break in from the outside. It lets someone who already has a foothold (a shell, a CI runner, a compromised service account) go from a regular user to full root.
The bug lives in algif_aead, a kernel module in the cryptographic subsystem.
Through a specific sequence of socket operations, an attacker can write 4 controlled bytes
into the page cache of ANY readable file on the system. This includes a setuid root binary.
When that binary runs, the attacker gets root. It's really that simple.
The modification exists only in memory. Nothing ever touches disk. File integrity tools, antivirus, and standard forensics can't see anything. Reboot the machine and the evidence is completely gone.
Impact right now
As of today, a fully functional public exploit for the Linux kernel is still circulating and active exploitation has been confirmed by threat intelligence platforms and researchers. CISA added it to the Known Exploited Vulnerabilities catalog on April 30. Microsoft Defender has flagged preliminary testing activity that is likely to increase in the coming days. Theori researcher Taeyang Lee found it using The AI tool: Xint Code. They were also a finalist in DARPA's AI Cyber Challenge. Coordinated disclosure seems to be taking place.
The blast radius is large. This isn't a niche vulnerability affecting one random distro. It hits every major Linux distribution running any kernel built between 2017 and the patch release. That's essentially every production Linux machine on the planet for the past nine years that hasn't been patched in the last month (~millions). That's Ubuntu, Debian, RHEL, Amazon Linux, Fedora, Arch, SUSE, and more. It works in cloud VMs, bare metal, and shared-kernel container environments like Kubernetes clusters and CI/CD pipelines where untrusted code runs all the time.
Ubuntu: how to fix it
Canonical has shipped a mitigation via the kmod package that blacklists the
algif_aead module. The full kernel patch is rolling out separately.
The fastest path to protected:
Option 1: Full upgrade (recommended)
sudo apt update && sudo apt upgrade
sudo rebootOption 2:Target kmod only
sudo apt update && sudo apt install --only-upgrade kmod
sudo reboot
The reboot ensures the patched kernel is loaded and any previously loaded module is fully unloaded.
If you have unattended-upgrades enabled, the kmod fix
will apply automatically within 24 hours.
algif_aead removes hardware-accelerated AEAD cryptography.
Most applications fall back to userspace crypto automatically, but some may not.
Can't reboot? No-reboot workaround
Apply the kmod update first (Option 2 above), then run the following to
unload the module from the live kernel without restarting:
# Unload the module if it's running
sudo rmmod algif_aead 2>/dev/null || true
# Confirm it's gone
lsmod | grep algif_aead
# No output means you're good
# Confirm the blacklist is in place
cat /etc/modprobe.d/disable-algif.conf
# Should show: install algif_aead /bin/false
If lsmod returns nothing and the blacklist file exists, you are protected without a reboot.
algif_aead is compiled directly into
the kernel image (CONFIG_CRYPTO_USER_API_AEAD=y) rather than as a loadable module.
In that case rmmod won't work and the blacklist has no effect.
Check with: grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
If it returns =y, you need the full kernel update. There is no shortcut.
Other distros — generic mitigation
Works on any distro where the module is loadable (=m):
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || trueThen update your kernel via your distro's package manager when the patch is available.
Verify that you are protected
# Module should not be loaded
lsmod | grep algif_aead
# Module should fail to load
sudo modprobe algif_aead
# Expected: ERROR: could not insert 'algif_aead'
# Check if module is built-in (=y means you need a kernel patch)
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)Why forensics won't catch it after the fact
The exploit only modifies the kernel's page cache. The in-memory copy of files the kernel keeps for performance. It never writes to disk. File integrity monitoring tools compare against disk state, so they see nothing. A full disk image taken post-exploitation will show the original, unmodified files. Reboot and all evidence vanishes.
One potential post-exploitation signal: auth.log may show su entries with
a missing invoking username. This can occur legitimately but is unusual enough to investigate:
grep "su\[.*\]: (to root)" /var/log/auth.log | grep -v "(to root) [a-zA-Z]"Real-time detection is the only realistic option here. eBPF-based monitoring, Falco rules, or anything watching kernel behaviour rather than disk state. I've created my own eBPF-based tools that can detect this exploit in action. Search for Glasswally on my GitHub if you're interested in that and modify as you like.
Further reading
Ubuntu Security Blog. "Copy Fail" advisory
Red Hat Security Bulletin RHSB-2026-02
Copy Fail FAQ
NVD - CVE-2026-31431