Defend Your Systems Against Copy Fail

Copy Fail is serious, but fixable. Patch it, check where local access could exist, and review logs calmly.

Overview

Copy Fail, tracked as CVE-2026-31431, is a serious Linux kernel local privilege escalation vulnerability publicly disclosed on 29 April 2026. It was found by Xint Code / Theori during AI-assisted analysis of the Linux kernel crypto/ subsystem, reported to the Linux kernel security team on 23 March 2026, and fixed upstream on 1 April 2026. Distribution vendors are now shipping official patches and mitigations.

The vulnerable code path was introduced in the Linux 4.14-era kernel code in 2017. Public reporting lists upstream fixes in 6.18.22, 6.19.12, and 7.0, but this is not enough to judge every real system. Linux distributions often backport security fixes, so the real source of truth is your running kernel plus your vendor advisory. Very old legacy kernels that do not contain the 2017 code path may not be affected, but legacy systems should still be checked properly.

Copy Fail affects the kernel crypto path around algif_aead, AF_ALG, authencesn, and splice(). On affected kernels, an unprivileged local user may be able to corrupt page-cache-backed data and turn that into root access, commonly by targeting a readable setuid-root binary.

This is local, but local does not mean harmless. In real environments, local code execution can come from a web shell, a compromised service account, a CI job, a container workload, a developer running untrusted code, or a shared user account.

We are not going to re-explain the exploit internals here. The original researchers already did that well:

Patch It Quick

The clean fix is to run a kernel that contains the Copy Fail patch. The vulnerable logic is inside the kernel, so restarting services or changing passwords does not fix the issue.

Check what you are running:

uname -r
cat /etc/os-release

Then follow your distribution advisory. Do not judge only by the version number, because distributions often backport security fixes.

Common update examples:

# Debian / Ubuntu
sudo apt update
sudo apt upgrade
sudo reboot

# RHEL / Fedora / Rocky / AlmaLinux
sudo dnf update kernel
sudo reboot

# SUSE / openSUSE
sudo zypper patch
sudo reboot

After reboot, verify the running kernel again:

uname -r

Important: Updating packages is not enough if the machine is still running the old kernel. Reboot or use a vendor-supported livepatching method.

Vendor references:

If you cannot patch immediately, block the affected algif_aead module as a temporary mitigation:

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

Verify whether it is still loaded:

grep -qE '^algif_aead ' /proc/modules && echo "algif_aead is loaded" || echo "algif_aead is not loaded"

Expected result:

algif_aead is not loaded

If it is still loaded, reboot and check again.

On Ubuntu, Canonical also released a kmod mitigation that prevents algif_aead from loading while kernel fixes are handled:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

The temporary mitigation is useful, but the kernel update is still the final fix. If you run custom kernels, check your kernel configuration and patch level instead of assuming the module-based mitigation covers everything.

Understand Where This Matters

Copy Fail requires local code execution. That sounds limited, but many real attacks already reach that point.

Common paths to worry about:

Web application compromise: attacker gets a www-data, nginx, apache, or application user shell, then escalates to root.
Shared Linux systems: one normal user account may become full machine compromise.
CI/CD runners: malicious or compromised build code runs as a low-privileged user, then escalates on the runner.
Containers and Kubernetes nodes: container code still shares the host kernel, so kernel bugs matter.
Developer workstations: running untrusted tools, scripts, dependencies, or PoCs can turn into root compromise.
Public-facing servers: a separate web bug plus Copy Fail can become complete host takeover.

This is why local privilege escalation is not "just local" anymore. Modern infrastructure constantly runs local code from many sources.

Check Logs and Monitoring

CISA has added CVE-2026-31431 to the Known Exploited Vulnerabilities catalog, so defenders should assume exploitation attempts may already be happening.

Do not panic. Look back calmly.

Start with authentication and privilege-change logs:

last -a
sudo journalctl --since "14 days ago" | grep -Ei "sudo|su|session opened|uid=0|root"

On Debian/Ubuntu systems:

sudo grep -Ei "sudo|su|session opened|uid=0|root" /var/log/auth.log* 2>/dev/null

On RHEL/SUSE-style systems:

sudo grep -Ei "sudo|su|session opened|uid=0|root" /var/log/secure* 2>/dev/null

Check for recent persistence changes:

sudo find /etc/cron* /var/spool/cron /etc/systemd/system -type f -mtime -14 -ls 2>/dev/null
sudo find /root /home -name authorized_keys -mtime -14 -ls 2>/dev/null
sudo awk -F: '$3 == 0 { print }' /etc/passwd

These commands are just examples, starting points, not proof of compromise by themselves. Adjust the commands to your specific needs.

If you already have EDR, SIEM, auditd, osquery, Wazuh, Falco, Sysmon for Linux, or any another monitoring tool configured, search for unusual activity from low-privileged users and service accounts around the disclosure window.

Interesting signals include:

service users spawning shells
unexpected root sessions
strange activity from CI runners
new SSH keys
new users
new cron jobs or systemd services
suspicious commands run by www-data, nginx, apache, build users, or container users

If logs or monitoring show strong signs of compromise, treat this as more than patch management. Look for persistence, credential access, lateral movement, and post-exploitation activity. In that situation, a proper Linux Security Audit is recommended. Bytebreakers provides Linux security audit services for teams that need help validating whether a system was only exposed or actually compromised.

Conclusion

Copy Fail is serious, but it is also fixable.

For defenders, the correct response is calm and direct:

Identify affected Linux systems.
Patch the kernel and reboot.
If patching is delayed, apply the official algif_aead mitigation.
Prioritize shared systems, CI runners, container hosts, Kubernetes nodes, and public-facing servers.
Review logs and monitoring for unusual recent privilege escalation or persistence activity.

If there is a strong reason to believe Copy Fail was exploited in your environment, do not stop at patching. Perform a proper Linux Security Audit or get qualified help.

The bigger lesson is also important. Copy Fail was found with AI-assisted vulnerability research, and this will not be the last time AI helps uncover old bugs in critical open-source code. We should expect more findings like this in the future.

That does not mean panic. It means Linux defenders need boring and reliable basics: updated kernels, fast patching paths, useful monitoring, strong security audits, and less blind trust in low-privileged local code.

Patch it, verify it, check your logs, and move on with a little more respect for local privilege boundaries.