Cyber Heads Up: “Copy Fail” (CVE-2026-31431), a High-Severity Linux Kernel Privilege Escalation Vulnerability

Posted: | Assura Team
Posted in: Resources » Cyber Heads-up

Overview:

A high-severity privilege escalation vulnerability has been disclosed in the Linux kernel, tracked as CVE-2026-31431 and nicknamed Copy Fail. The flaw was discovered by Taeyang Lee of Theori and carries a CVSS score of 7.8 (High). A working 732-byte Python proof-of-concept exploit is publicly available, and active exploitation in the wild has been reported. Any unpatched Linux host running a kernel built since late 2017 is potentially at risk.

Affected distributions include Ubuntu 20.04/22.04/24.04, Debian 11/12, RHEL/CentOS/Rocky/AlmaLinux 8 and 9, Amazon Linux 2/2023, and most other mainstream distributions that have not applied the April/May 2026 kernel updates.

What It Is:

Copy Fail exploits a logic error in the algif_aead kernel module, which is part of the AF_ALG (kernel crypto API) socket interface. By combining an AF_ALG socket with a splice() system call, an unprivileged local attacker can write four bytes to an arbitrary page in the kernel page cache. From that four-byte write, a full root shell is achievable in seconds.

The vulnerable code path was introduced in commit 72548b093ee3 (merged late 2017) and has been present in every mainline kernel since. The exploit requires no special capabilities in the default configuration of most distributions. A standard unprivileged user account with shell access is sufficient to trigger it.

Why It’s Dangerous:

  • Any web application, database service, or background job running as a non-root user on a vulnerable Linux host can be turned into a root-level foothold if the application is compromised.
  • Shared-hosting environments and multi-tenant systems are at elevated risk. One tenant compromising their own account can escalate to the hypervisor or host OS, depending on isolation controls.
  • Container environments are partially affected. Docker and Podman containers inherit the host kernel. A container with a compromised process can use this exploit to escape if the container’s seccomp profile does not block AF_ALG socket creation. The default Docker seccomp profile does not block this syscall path. Kubernetes clusters are similarly exposed unless a custom seccomp or AppArmor/SELinux policy is in place.
  • The public PoC is 732 bytes of Python. The barrier to exploitation is low. Organizations should plan for opportunistic use by low-sophistication attackers alongside targeted use.

Assura’s Recommendations:

  • Patch immediately. Apply the kernel update for your distribution. Vendor advisories are listed in the References section below. A reboot is required to load the patched kernel.
  • If patching is not immediately possible, disable the vulnerable module. The steps differ by distribution family:
    • Debian / Ubuntu: 
      # Blacklist the module and unload it from the running kernel
echo "blacklist algif_aead" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true
# Verify it is no longer loaded
lsmod | grep algif_aead
    • RHEL / CentOS / Rocky / AlmaLinux: 
      # On RHEL-family kernels, rmmod may silently fail due to module dependencies.
# Use grubby to pass a kernel argument that prevents the module from initialising at boot.
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
# A reboot is required for this change to take effect.
sudo reboot

      After the workaround reboot, confirm with lsmod | grep algif_aead. No output means the module is not loaded.

  • Harden container seccomp profiles. If you run Docker or Kubernetes workloads on Linux hosts, audit your seccomp profiles to confirm that AF_ALG socket creation is blocked. A custom seccomp profile that denies this syscall prevents the exploit within containers, even on an unpatched host.
  • Inventory exposed Linux hosts. Prioritize internet-facing servers, CI/CD build agents, shared development systems, and any host where multiple users or applications share an account. Systems where no interactive shell or untrusted code execution is possible are lower priority but should still be patched in the normal cycle.
  • Consider live patching. If your environment cannot tolerate a reboot, evaluate kernel live patching services: kpatch (RHEL), Canonical Livepatch (Ubuntu), or KernelCare (multi-distro). Patches for Copy Fail have been released or are in progress for all major live-patch vendors.

Indicators of Compromise and Detection Signals:

Because this vulnerability requires local access and code execution, detection focuses on behavioral signals rather than network traffic.

  • Unprivileged process opens an AF_ALG socket (PF_ALG family 38) followed by a splice() call to a target file descriptor. This combination has no legitimate production use for normal application workloads.
  • Unexpected privilege escalation: a process with UID > 0 spawning a child process with UID 0, particularly if the parent is a web server, application daemon, or container entrypoint.
  • New SUID or SGID binaries appearing outside standard package-managed paths (e.g., /tmp, /var/tmp, /dev/shm).
  • Kernel module load events for algif_aead on systems where the module should be blacklisted.
  • Reads or modifications to /etc/passwd, /etc/sudoers, or SSH authorized_keys files from a process that did not hold root privileges at parent creation time.

Public PoC hash (for threat intel matching):
SHA-256: a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890 (original Theori PoC; variants will differ)

AuditD detection rule:

# Detect AF_ALG socket creation by non-root users
-a always,exit -F arch=b64 -S socket -F a0=38 -F uid!=0 -k algif_aead_exploit

Post-exploitation hunting: Look for processes running as root whose /proc/[pid]/loginuid differs from 0, new executable files in /tmp or /dev/shm created in the last 7 days, new cron jobs or SSH keys added in the same window, and any EDR or auditd restart events that may indicate logging was disabled.

What Assura’s SOC is Doing for Our Clients:

  • Issued advisories to all managed service customers.
  • Added CVE-2026-31431 to active threat intelligence monitoring.

In addition to actively searching for indicators of exploitation of this vulnerability, our SIEM/XDR platform conducts an active retrospective threat hunt across all available log data, and will alert our team if it detects past exploitation.

If you’re an Assura client, feel to reach out to our team if you have further questions or need guidance.

References

Back to Resources