Every Linux distro since 2017 is vulnerable

CVE-2026-31431 (CopyFail) is a 732-byte kernel LPE affecting all major distributions. Any unprivileged user becomes root. No race conditions, no offsets, no guessing—it just works.

The short version: A kernel bug in AF_ALG (the crypto API) lets any local user escalate to root. It’s been exploitable since 2017. Xint Code published the details on April 29, 2026. You need to act today.

Why This Kills Magento Sites

Magento is a common target. Weak admin passwords, vulnerable plugins, compromised extensions, core RCEs (Polyshell/SessionReaper/Cosmicsting) can be chained to give an attacker shell access as the unprivileged web user. CopyFail turns that into root.

On shared hosting: One tenant can root the entire server and access everyone’s data.

On cloud/Kubernetes: One container escape means the whole node is compromised. Page cache is shared across pods.

On CI runners: Self-hosted GitHub Actions or GitLab runners running untrusted PR code? That code becomes root immediately.

For Magento hosts, this chains with everything else. It’s the privilege escalation that makes web RCE actually catastrophic.

Emergency Fix (Today)

Disable the algif_aead module. This eliminates the attack surface completely.

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

Will it break anything? No. AF_ALG is a userspace door to kernel crypto. Almost nothing uses it. LUKS, SSH, OpenSSL, IPsec—they all either call kernel crypto directly or use userspace libraries. Disabling AF_ALG has zero impact on production workloads.

Deploy Across Infrastructure

If you’ve got multiple Magento hosts:

- hosts: magento_servers
  become: true
  tasks:
    - name: Disable algif_aead module
      copy:
        dest: /etc/modprobe.d/disable-algif.conf
        content: |
          install algif_aead /bin/false
        owner: root
        group: root
        mode: '0644'

    - name: Check if algif_aead is loaded
      shell: lsmod | grep -w algif_aead
      register: algif_loaded
      failed_when: false
      changed_when: false

    - name: Unload module if present
      command: rmmod algif_aead
      when: algif_loaded.rc == 0

Run it once. Takes 30 seconds per host.

Long-Term Fix (This Week)

Patch your kernels. The fix is mainline commit a664bf3d603d (reverts the 2017 optimization). All major distros have releases out:

  • Ubuntu, Debian, RHEL, CentOS, Fedora, SUSE, Amazon Linux 2, Arch—all have patched packages available
  • Test in staging first if you like, but this is a safe kernel upgrade

Once patched, you can theoretically re-enable algif_aead. Don’t bother. Leave it disabled.

What This Actually Impacts

If compromised, an attacker can:

  • Read all your Magento data (customers, orders, PII, payment info)
  • Modify your store (inject malware, redirect customers)
  • Access other tenants on shared hosting
  • Pivot to internal infrastructure

Timeline: Any of your users can do this. No network access needed. They just need shell access (which they get from a weak password, plugin vuln, RCE in Magento, etc.).

Reality check: If you’re on shared hosting and your provider hasn’t patched, you’re running on a compromised kernel right now. Switch providers or patch immediately.

Check Your Logs

Look for suspicious activity:

  • /var/log/auth.log or /var/log/secure for unexpected su attempts
  • Magento var/log/ for unusual access patterns
  • File integrity monitoring alerts for system binary changes

The exploit modifies page cache (in-memory), so changes don’t survive reboot. But logs will show activity.

Personal Sitrep

I maintain and operate a modest fleet of infrastructure ~60 nodes. By having a well maintained Ansible workspace, I was able to patch, validate, update the entire infrastructure fleet in a short time window.

Within the first 15 minutes of being aware of the exploit, all nodes was emergency patched (disabled algif_aead). Performed in waves to monitor impact / issues.

Within the first 120 minutes, all nodes had Kernel updated applied. Performed in a handful of waves, at a slower velocity, to reduce risk and avoid service disruption where possible.

For More Details

Full technical writeup: copy.fail Xint Code’s analysis: Xint Blog Issue tracker: GitHub

See the docs page for deployment validation steps.