On 29 April 2026, security researchers at Theori (Xint Code) publicly disclosed CVE-2026-31431, known as \u201cCopy Fail.\u201d It is a local privilege escalation flaw in the Linux kernel\u2019s AF_ALG cryptographic interface. Any unprivileged local user, including a compromised web application running as a low-privilege user such as www-data, apache, or a cPanel customer account, can escalate to root within seconds. The vulnerability has existed in mainstream Linux kernels since 2017 and a working public exploit is already in circulation.<\/p>\n
If you are unsure which distribution you are running, the following command will tell you:<\/p>\n
cat \/etc\/os-release<\/code><\/pre>\nStep 1: Confirm whether your kernel is vulnerable<\/h2>\n
Run this command as root:<\/p>\n
grep CRYPTO_USER_API_AEAD \/boot\/config-$(uname -r)<\/code><\/pre>\n\n- No output, or the file does not exist: your kernel is not affected. No further action required.<\/li>\n
- Output ending in “=m” – typical for Ubuntu and Debian: affected, follow Path B below.<\/li>\n
- Output ending in “=y” – typical for AlmaLinux, Rocky, RHEL, CloudLinux: affected, follow Path A below.<\/li>\n<\/ul>\n
Step 2a: Path A – AlmaLinux \/ Rocky \/ RHEL \/ CloudLinux<\/h2>\n
On these distributions the vulnerable code is compiled directly into the kernel, so the standard module-blacklist approach will silently fail and leave your server vulnerable. Use the following kernel boot parameter instead, which prevents the vulnerable subsystem from initialising at boot:<\/p>\n
grubby --update-kernel=ALL --args=\"initcall_blacklist=algif_aead_init\"\r\nreboot<\/code><\/pre>\nA reboot is required for the change to take effect.<\/p>\n
Step 2b: Path B – Ubuntu \/ Debian<\/h2>\n
On these distributions the vulnerable code is a loadable module and can be disabled with:<\/p>\n
echo \"install algif_aead \/bin\/false\" > \/etc\/modprobe.d\/disable-algif.conf\r\nrmmod algif_aead 2>\/dev\/null || true<\/code><\/pre>\nA reboot is not strictly required but is recommended to ensure the configuration is loaded cleanly on next boot.<\/p>\n
Step 3: Verify the mitigation has taken effect<\/h2>\n
As a non-root user, run the following test. It attempts to bind an AF_ALG AEAD socket, the operation an attacker would perform, and reports whether the kernel still permits it:<\/p>\n
perl -e '\r\nuse Socket;\r\nsocket(S, 38, 5, 0) or die \"socket: $!\";\r\nmy $addr = pack(\"S a14 L L a64\", 38, \"aead\", 0, 0, \"authenc(hmac(sha256),cbc(aes))\");\r\nbind(S, $addr) or die \"bind: $!\";\r\nprint \"bind ok\\n\";\r\n'<\/code><\/pre>\n\n- Output
bind ok<\/code> If you get this output, your server is still vulnerable. For Path A, re-check Step 2 and ensure you have rebooted.\u00a0 For Path B, run rmmod<\/code>.<\/li>\n- Output
bind: No such file or directory<\/code> If you get this output, the mitigation is working.<\/li>\n<\/ul>\nStep 4: Apply the official kernel patch when available<\/h2>\n
The mitigation above disables the AF_ALG authenticated-encryption interface. This is safe for the overwhelming majority of workloads, it is not used by SSH, OpenSSL, dm-crypt\/LUKS, IPsec, or kTLS,\u00a0but it should be considered a temporary measure. When your distribution publishes a kernel update incorporating upstream commit a664bf3d603d<\/code>\u00a0please apply it and reboot:<\/p>\n