Support 24/7
Shared hostingManaged WordPressReseller hostingOpenClaw hostingVPS hostingDedicated serversManaged serversAbout usHow we compareRegionsKnowledge baseSupportDomainsSSLBlogClient area
Security advisories
Knowledge base / Security advisories

Mitigating CVE-2026-31431 (Linux based systems)

CVE-2026-31431 “Copy Fail” is a local privilege escalation in the Linux kernel. How to tell whether you are affected, and how to close it.

Last updated: May 1, 2026

How to Mitigate CVE-2026-31431 (“Copy Fail”) on Linux Servers

  1. 1Check whether you are affecteduname -r, then grep the kernel changelog for CVE-2026-31431.
  2. 2Install a patched kernelPreferred whenever your distribution has one.
  3. 3Or apply the mitigationDisables the vulnerable algif_aead interface entirely. Fully effective.
  4. 4RebootNeither route takes effect until the server restarts.
  5. 5Verify after the rebootConfirm the boot parameter is active, or that the patched kernel is the running one.
A patched kernel is the preferred fix; the mitigation is for servers that do not have one yet. Either route needs a reboot, and both end in the same verification.

What is Copy Fail?

CVE-2026-31431, nicknamed “Copy Fail”, is a high-severity local privilege escalation vulnerability in the Linux kernel (CVSS 7.8). It affects virtually every mainstream Linux distribution shipped since 2017.

The flaw lives in the kernel’s algif_aead cryptographic interface. By chaining an AF_ALG socket call with splice(), an unprivileged local user can perform a controlled 4-byte write into the page cache of any readable file — including setuid-root binaries like /usr/bin/su. A working 732-byte Python exploit is publicly available and works reliably across distributions without timing or race conditions.

Am I affected?

If you run any Linux distribution with a kernel released between 2017 and the patch (April 2026), yes. This includes:

  • CentOS 7, CentOS Stream 8/9/10
  • RHEL 7/8/9/10, AlmaLinux, Rocky Linux, CloudLinux
  • Ubuntu 18.04, 20.04, 22.04, 24.04 (Ubuntu 26.04+ is not affected)
  • Debian 10, 11, 12

The vulnerability requires local code execution — it cannot be exploited remotely on its own. However, in shared hosting, multi-tenant, container, or CI environments, this is a critical risk because any user with shell access (including via a compromised website) can escalate to root.

Quick check: is my server affected?

Run this on any Linux server:

uname -r
grep -E 'authencesn|algif_aead' /proc/crypto

If the kernel changelog does not yet reference CVE-2026-31431, the server is vulnerable and needs either a patched kernel or the mitigation below.

How to fix

You have two options:

  1. Install a patched kernel from your distribution and reboot (preferred when available).
  2. Apply the mitigation below, which disables the vulnerable algif_aead interface entirely. This is fully effective and only requires a reboot.

The mitigation has no impact on dm-crypt/LUKS, kTLS, IPsec, OpenSSL, GnuTLS, NSS, or SSH. Only applications that explicitly use the AF_ALG userspace crypto API for AEAD operations (rare on standard servers) are affected.

Mitigation for RPM-based systems (CentOS / RHEL / AlmaLinux / Rocky Linux / CloudLinux)

Applies to: CentOS 7, CentOS Stream 8/9/10, RHEL 7/8/9/10, AlmaLinux 8/9/10, Rocky Linux 8/9/10, CloudLinux 7/8/9/10.

Step 1 — Add the kernel boot parameter

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

Step 2 — Verify the parameter is set

sudo grubby --info=DEFAULT | grep args

You should see initcall_blacklist=algif_aead_init in the output.

Step 3 — Reboot the server

sudo reboot

Step 4 — Verify mitigation is active after reboot

cat /proc/cmdline | grep initcall_blacklist
grep -E 'authencesn|algif_aead|af_alg' /proc/crypto
dmesg | grep -i 'blacklisting initcall'

Expected results:

  • The first command should show the parameter.
  • The second command should return no output (empty).
  • The third command should show blacklisting initcall algif_aead_init.

If all three checks pass, the mitigation is fully active.

Mitigation for Debian / Ubuntu-based systems

Applies to: Debian 10/11/12, Ubuntu 18.04, 20.04, 22.04, 24.04.

Step 1 — Create the modprobe blacklist

sudo tee /etc/modprobe.d/disable-algif-aead.conf > /dev/null <<'EOF'
install algif_aead /bin/false
blacklist algif_aead
EOF

Step 2 — Back up the GRUB config

sudo cp /etc/default/grub /etc/default/grub.backup-copyfail

Step 3 — Add the kernel boot parameter

sudo sed -i 's|^GRUB_CMDLINE_LINUX="\(.*\)"|GRUB_CMDLINE_LINUX="\1 initcall_blacklist=algif_aead_init"|' /etc/default/grub

Step 4 — Verify the parameter was added

grep GRUB_CMDLINE_LINUX /etc/default/grub

You should see initcall_blacklist=algif_aead_init in the output.

Step 5 — Regenerate the GRUB config

sudo update-grub

If update-grub is not available (minimal Debian), use instead:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Step 6 — Update initramfs

sudo update-initramfs -u

Step 7 — Reboot the server

sudo reboot

Step 8 — Verify mitigation is active after reboot

cat /proc/cmdline | grep initcall_blacklist
lsmod | grep algif_aead
grep -E 'authencesn|algif_aead|af_alg' /proc/crypto
dmesg | grep -i 'blacklisting initcall'

Expected results:

  • The first command should show the parameter.
  • The second and third commands should return no output (empty).
  • The fourth command should show blacklisting initcall algif_aead_init.

Removing the mitigation after installing a patched kernel

Once your distribution releases a kernel that includes the official fix for CVE-2026-31431, install it and remove the mitigation. There is no rush — the mitigation can stay in place indefinitely without harm.

For RPM-based systems

sudo dnf update kernel
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

(On CentOS 7, replace dnf with yum.)

For Debian/Ubuntu systems

sudo apt update && sudo apt upgrade
sudo rm /etc/modprobe.d/disable-algif-aead.conf
sudo sed -i 's| initcall_blacklist=algif_aead_init||' /etc/default/grub
sudo update-grub
sudo update-initramfs -u
sudo reboot

Verify the patched kernel is running

uname -r

Compare against your distribution’s official patched kernel version. For AlmaLinux 9, this is 5.14.0-611.49.2.el9_7 or higher; for AlmaLinux 8, 4.18.0-553.121.1.el8_10 or higher. Other distributions: check the official security advisory pages.

References

If you need assistance applying this mitigation to your server, please open a support ticket.