CVE-2026-31431 (Copy Fail): Mitigation and Upcoming Patches for CloudLinux

Status (as of 2026-04-30)

Patched kernels and KernelCare livepatches for all affected CloudLinux versions are being prepared and rolled out within the next 6 to 24 hours (timing varies by product). Apply the mitigation below in the meantime — it can be reverted in seconds once the patch is in place. Follow updates on the CloudLinux Status Page.

What it is

A Linux kernel local privilege escalation in the algif_aead module (AF_ALG). Any unprivileged local user can gain root via a 732-byte Python exploit. All Linux kernels since 2017 are affected.

Details: copy.fail · Xint write-up · NVD

Affected CloudLinux versions

Version	Affected	Will be patched via
CL7	No	—
CL7h, CL8	Yes	CloudLinux kernel
CL9, CL10	Yes	AlmaLinux kernel

KernelCare livepatch will also be available as an alternative on all affected versions — see Upcoming patches below.

Apply this mitigation now

Until a patched kernel or KernelCare livepatch is installed, blacklist the algif_aead initcall via grubby to prevent the AEAD AF_ALG interface from being registered at boot. This closes the attack surface without replacing the kernel. Requires a reboot.

Apply the restriction via grubby and reboot:

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

After reboot, confirm the parameter is on the active kernel command line — it should contain initcall_blacklist=algif_aead_init:

sudo grubby --info=ALL | grep initcall_blacklist

To revert after a patched kernel is installed:

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

Compatibility: dm-crypt / LUKS, kTLS, IPsec, SSH, and default OpenSSL / GnuTLS builds do not depend on AF_ALG and are unaffected. Only applications that explicitly use AF_ALG for AEAD ciphers (rare on web hosting — e.g., OpenSSL with the afalg engine enabled, or hardware crypto offload via AF_ALG) will be impacted.

Additional protection for Imunify360 users

Imunify360 already detects the published indicators of compromise for CVE-2026-31431 and uses extended heuristics to identify and mitigate new indicators more quickly. This is an additional layer of defense — it does not replace the kernel update, but customers running Imunify360 are covered against currently observed exploitation attempts in the meantime.

Warning: The recommended mitigation from the original sources does not work

The modprobe-based workaround circulating on oss-security — adding the line install algif_aead /bin/false to a file under /etc/modprobe.d/ and running rmmod algif_aead — does not work on CloudLinux, AlmaLinux, or any other RHEL-family distribution.

The algif_aead module is built into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), so modprobe.d rules cannot block its loading and rmmod cannot remove it. The commands run without errors but leave the system unchanged — applying them gives a false sense of protection.

You can confirm the module is built-in on any system:

modinfo algif_aead | grep filename
# (builtin)

Verify the mitigation is active

sudo grubby --info=ALL | grep initcall_blacklist

If the output contains initcall_blacklist=algif_aead_init for the active kernel boot entry, the mitigation is in place.

Upcoming patches

A follow-up advisory with the exact patched kernel versions and update instructions will be published once the kernels and KernelCare livepatches reach release state. Until then:

KernelCare livepatch (all affected versions)

Update: May 1, 12am CET.

AlmaLinux 9.6 ESU/FIPS fix (almalinux9 kernel-5.14.0-570.62.1.el9_6.tuxcare.1 through .els3) is available in test feed as K20260430_07

Update: April 30, 6pm CET.

KernelCare engineering has identified the fix set (3 upstream commits, not just the algif_aead revert), validated it against the published exploit on AlmaLinux 9.6-FIPS and UEK7, and is rolling it out across all supported distros ahead of vendor erratas. First release (alma9.6-esu/FIPS) is in review today — others are in active build/test. No customer action required — the live patch will be delivered automatically.

The KernelCare-ELS team is preparing the livepatch for this CVE. Once published, KernelCare-subscribed systems will receive the fix through the standard kcarectl --update flow — applied without a reboot.

Not using KernelCare yet? You can get started in just a few minutes. Find more information here.

CloudLinux kernel (CL7h, CL8)

The CloudLinux kernel for CL7h and CL8 is being rebuilt on top of the AlmaLinux 8 fix kernel-4.18.0-553.121.1.el8_10 (with CL's .lve suffix). It will land in the CloudLinux beta channel (cloudlinux-updates-testing) first, then move to the stable channel after community verification.

Track release status: CloudLinux Status Page — incident 642sgcmntkkk.

AlmaLinux kernel (CL9, CL10)

CL9 and CL10 use the AlmaLinux kernel directly. The patched kernel is already in the AlmaLinux testing repository:

CL9: kernel-5.14.0-611.49.2.el9_7 or later
CL10: kernel-6.12.0-124.52.2.el10_1 or later

AlmaLinux is preparing to promote it to production repositories shortly. If you cannot wait for the production promotion, the testing kernel can be installed by enabling the AlmaLinux testing repository directly.

From the AlmaLinux testing repository

The almalinux-release-testing package is not in CloudLinux repositories — install it from a direct URL, update the kernel, then disable the testing repo.

For CL10:

# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# 2. Update the kernel
dnf update kernel

# 3. Reboot
reboot

# 4. Verify — expected kernel-6.12.0-124.52.2.el10_1 or later
uname -r

# 5. Disable the testing repo
dnf config-manager --disable almalinux-testing

For CL9 — same flow, replace the URL in step 1:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm

References