1. Home
  2. Announcement
  3. CVE-2026-31431 “Copy Fail” Linux Kernel Vulnerability: What You Need to Know and How to Fix It
Searching...

CVE-2026-31431 “Copy Fail” Linux Kernel Vulnerability: What You Need to Know and How to Fix It

Contents

Summary

A high-impact Linux kernel local privilege escalation vulnerability, CVE-2026-31431, also known as “Copy Fail”, has been publicly disclosed.

This vulnerability affects the Linux kernel’s cryptographic interface, specifically the algif_aead / AF_ALG path. Under affected kernel versions, a local unprivileged user may be able to escalate privileges to root. The original researchers describe the issue as affecting mainstream Linux distributions using kernels built since 2017, with particular risk for multi-user servers, container platforms, CI/CD runners, and shared hosting environments.

The issue is tracked as CVE-2026-31431. Ubuntu rates it High with CVSS 7.8, while Red Hat rates the impact as Important.

EuroVPS strongly recommends that all affected Linux servers are reviewed and patched as soon as vendor-fixed kernels or mitigations are available.

What is CVE-2026-31431?

CVE-2026-31431 is a Linux kernel vulnerability in the crypto subsystem. The flaw is related to an incorrect in-place operation in algif_aead, where source and destination mappings differ. The upstream kernel fix is associated with mainline commit a664bf3d603d, which reverts the problematic 2017 optimization.

The vulnerability is dangerous because it may allow a local unprivileged user to gain root privileges. This is especially serious on systems where users, containers, or applications can execute code locally.

The vulnerability is not a remote network vulnerability by itself. However, if an attacker already has local shell access, compromised web application access, container execution, or another foothold, this vulnerability may allow escalation to full root privileges.

Affected Operating Systems and Vendor Fixes / Patches

The vulnerability may affect many Linux distributions with kernels built since 2017. Vendor status differs by distribution and kernel stream, so the correct action is to follow the official vendor advisory for your operating system.

1. AlmaLinux

AlmaLinux has released patched kernels for supported versions. The confirmed patched versions are:

OSPatched kernel version
AlmaLinux 8kernel-4.18.0-553.121.1.el8_10 or newer
AlmaLinux 9kernel-5.14.0-611.49.2.el9_7 or newer
AlmaLinux 10kernel-6.12.0-124.52.2.el10_1 or newer
AlmaLinux Kitten 10kernel-6.12.0-225.el10 or newer

Recommended update:

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

Verify after reboot:

uname -r
rpm -q kernel

2. Oracle Linux

Oracle Linux is also affected when running vulnerable Linux kernel builds. Oracle has released Unbreakable Enterprise Kernel (UEK) security updates for CVE-2026-31431 under official Oracle Linux errata.

Oracle Linux version / kernel streamFixed kernel / patch level
Oracle Linux 7 / 8 – UEK R6kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek or newer
Oracle Linux 8 / 9 – UEK R7kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek or newer
Oracle Linux 9 / 10 – UEK R8kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek or newer

Oracle lists the UEK updates as SECURITY, IMPORTANT, released on 2026-05-01, and includes CVE-2026-31431 in the kernel crypto fixes.

Recommended update:

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

For older Oracle Linux systems using yum:

yum clean all
yum update 'kernel*'
reboot

Oracle Linux verification

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Make sure the running kernel shown by uname -r is the patched kernel, not only installed.

3. CloudLinux

CloudLinux confirms that CL7 is not affected, while CL7h, CL8, CL9, and CL10 are affected. CL7h and CL8 are patched through CloudLinux kernels, while CL9 and CL10 use AlmaLinux kernel updates.

Confirmed CloudLinux target versions include:

OSPatched kernel version
CloudLinux 7Not affected
CloudLinux 7 Hybrid / CL7hkernel-4.18.0-553.121.1.lve.el7h.x86_64 or newer
CloudLinux 8kernel-4.18.0-553.121.1.lve.el8.x86_64 or newer
CloudLinux 9kernel-5.14.0-611.49.2.el9_7 or newer
CloudLinux 10kernel-6.12.0-124.52.2.el10_1 or newer

Recommended update for CloudLinux 8 / 9 / 10:

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

For older CloudLinux systems using yum:

yum update 'kernel*'
reboot

Verify:

uname -r
rpm -q kernel

For KernelCare systems:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux states that KernelCare live patches for many affected distributions, including AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu, and Debian streams, were released to the main feed as of May 2, 2026.

4. Ubuntu

Ubuntu has published both a CVE tracker and a dedicated blog post for this issue. Ubuntu states that the mitigation is distributed through the kmod package and that the vulnerability fix will be distributed through Linux kernel image packages.

Recommended update:

sudo apt update
sudo apt upgrade
sudo reboot

To apply only the mitigation package where applicable:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Verification:

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

To check whether the affected module is currently loaded:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu also documents a manual mitigation using a modprobe.d rule and unloading algif_aead, but this approach is not suitable for all distributions, especially RHEL-family systems where the functionality may be built into the kernel.

5. Debian

Debian’s security tracker lists fixed versions for several Debian releases:

Debian releaseFixed version
Bullseye security5.10.251-3
Bookworm security6.1.170-1
Trixie security6.12.85-1
Forky6.19.14-1
Sid7.0.3-1

Recommended update:

sudo apt update
sudo apt upgrade
sudo reboot

Verify:

uname -r
dpkg -l 'linux-image*' | grep ^ii

6. Red Hat Enterprise Linux

Red Hat has published a security bulletin and CVE page for CVE-2026-31431. Red Hat describes it as a Linux kernel cryptographic interface issue where a local user may gain root privileges. Red Hat rates the issue as Important and states that fixes are being released through the relevant Red Hat channels.

Recommended action:

sudo dnf update 'kernel*'
sudo reboot

Verify:

uname -r
rpm -q kernel
rpm -q kernel-core

For systems using Red Hat subscriptions, also check the official Red Hat CVE page and advisories for the exact fixed package for your RHEL version and kernel stream.

7. SUSE

SUSE rates CVE-2026-31431 as important and tracks status by product and package. Some SUSE 15 SP7 packages are marked released, while several SUSE 16 and SUSE Linux Micro streams were still listed as affected or in progress on the SUSE CVE page at the time reviewed.

Recommended action:

sudo zypper refresh
sudo zypper update
sudo reboot

Verify:

uname -r
rpm -q kernel-default

Check the SUSE CVE page for the exact package status for your product, service pack, and kernel flavor.

Temporary mitigation if you cannot update immediately

For OracleLinux / AlmaLinux / CloudLinux / RHEL-family systems

For RHEL-family systems, the safer temporary mitigation is to blacklist the algif_aead_init initcall through the kernel command line and reboot:

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

Verify after reboot:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

or:

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux specifically warns that the common modprobe.d mitigation may not work on CloudLinux, AlmaLinux, or other RHEL-family systems because algif_aead may be built into the kernel. In that case, rmmod and modprobe.d rules can give a false sense of protection.

After installing a patched kernel, you can remove the temporary mitigation:

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

For Ubuntu / Debian systems

Ubuntu documents the following mitigation where applicable:

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

Verify:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

A reboot may be required if the module cannot be unloaded safely.

Container and Kubernetes hardening

For containerized environments, patching the host kernel remains the primary fix. However, additional containment is strongly recommended.

CERT-EU recommends blocking AF_ALG socket creation through seccomp policies for containerized workloads and CI/CD pipelines. Docker documents seccomp as a Linux kernel feature used to restrict container actions, and Docker’s default seccomp profile uses an allowlist model.

Docker seccomp check:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Expected:

CONFIG_SECCOMP=y

Run containers with the default seccomp profile unless there is a specific reason not to:

docker run --security-opt seccomp=default.json ...

For Kubernetes, use RuntimeDefault or a custom seccomp profile where appropriate. Kubernetes supports applying seccomp profiles to Pods and containers, and the Kubernetes documentation provides guidance for loading and applying profiles.

Example Kubernetes security context:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Additional Step for LiteSpeed Enterprise Servers

For servers running LiteSpeed Enterprise, especially hosting environments using CloudLinux / CageFS, EuroVPS recommends applying the following additional LiteSpeed hardening step.

This does not replace the kernel update or kernel mitigation. The main fix for CVE-2026-31431 remains updating to a patched kernel or applying the vendor-approved mitigation. This LiteSpeed step is an additional hardening measure for environments where LiteSpeed’s lscgid binary is present.

LiteSpeed 6.3.5 is listed by LiteSpeed as a security, tuning, and bugfix release, including CloudLinux CageFS-related changes. LiteSpeed’s own documentation also shows that lscgid historically uses the setuid permission in normal LiteSpeed/PHP operation.

Step 2 – Harden the lscgid Binary

First check whether LiteSpeed is installed:

/usr/local/lsws/bin/lshttpd -v

Then choose one of the following options.

This is the preferred option. The LiteSpeed upgrade handles the required lscgid permission hardening automatically:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

After the upgrade, restart LiteSpeed if required:

/usr/local/lsws/bin/lswsctrl restart

Option B – Quick Fix if you are not ready to upgrade

If you cannot upgrade LiteSpeed immediately, manually remove the setuid permission from the lscgid binary now:

chmod u-s /usr/local/lsws/bin/lscgid.*

Then restart LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart

You only need to apply Option A or Option B, not both.

Verification checklist

Run the following checks after applying updates or mitigations.

1. Identify OS and kernel

cat /etc/os-release
uname -r

2. Check installed kernel packages

RPM-based systems:

rpm -q kernel
rpm -q kernel-core

Debian/Ubuntu systems:

dpkg -l 'linux-image*' | grep ^ii

3. Confirm the running kernel is the patched kernel

After reboot:

uname -r

Compare the running kernel version with the official vendor-patched version for your OS.

4. Confirm mitigation is active, if used

For RHEL-family systems using grubby mitigation:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

For Ubuntu/Debian module mitigation:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. KernelCare verification

kcarectl --update
kcarectl --info | grep CVE-2026-31431

The CVE should appear as patched in KernelCare output where a live patch is available.

Important operational notes

Do not run public exploit proof-of-concept code on production servers. The public disclosure page itself warns that the PoC should only be used on systems you own or are authorized to test, and not on production systems.

A successful kernel update normally requires a reboot unless you are using a valid live patching solution such as KernelCare.

For shared hosting, multi-user, Kubernetes, Docker, CI/CD, and build environments, this should be treated as high priority because any local unprivileged execution path may become root-level access.

EuroVPS recommends the following action plan:

  1. Identify all Linux servers running affected kernel versions.
  2. Apply vendor kernel updates immediately where available.
  3. Reboot servers to activate the patched kernel.
  4. Where a kernel update is not immediately possible, apply the vendor-approved temporary mitigation.
  5. For CloudLinux/KernelCare systems, apply and verify KernelCare live patches where available.
  6. Harden Docker and Kubernetes workloads with seccomp policies.
  7. Verify the running kernel version after reboot.
  8. Avoid using unsupported or end-of-life operating systems, as timely security fixes may not be available
  9. For LiteSpeed Enterprise servers, upgrade to LiteSpeed 6.3.5 Build 5 or newer, or temporarily remove the setuid bit from /usr/local/lsws/bin/lscgid.* until the upgrade can be completed.

Need Assistance?

If you would like EuroVPS engineers to apply the required kernel patches, temporary mitigations, and post-update verification on your server, please open a support ticket from your EuroVPS Client Area.

Our team can assist with:

  • Checking whether your server is affected
  • Applying the vendor-recommended kernel update
  • Applying temporary mitigation where a patched kernel is not yet available
  • Rebooting the server into the patched kernel
  • Verifying the running kernel version after reboot
  • Confirming whether the mitigation or patch is active

Please open a support ticket from the Client Area and include your server hostname or IP address with root login details so our engineers can review it.

Official vendor and reference links:

[1] Copy Fail official disclosure – https://copy.fail/
[2] Ubuntu CVE tracker – CVE-2026-31431 – https://ubuntu.com/security/CVE-2026-31431
[3] Ubuntu blog – Copy Fail vulnerability fixes available – https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
[4] AlmaLinux advisory – CVE-2026-31431 Copy Fail – https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/
[5] CloudLinux blog – CVE-2026-31431 Copy Fail kernel update – https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update
[6] CloudLinux incident / status page – https://cloudlinux.statuspage.io/incidents/642sgcmntkkk
[7] Red Hat CVE page – CVE-2026-31431 – https://access.redhat.com/security/cve/CVE-2026-31431
[8] Red Hat security bulletin – https://access.redhat.com/security/vulnerabilities/RHSB-2026-02
[9] SUSE CVE page – CVE-2026-31431 – https://www.suse.com/security/cve/CVE-2026-31431
[10] Debian security tracker – CVE-2026-31431 – https://security-tracker.debian.org/tracker/CVE-2026-31431
[11] Docker seccomp documentation – https://docs.docker.com/engine/security/seccomp/
[12] Kubernetes seccomp documentation – https://kubernetes.io/docs/tutorials/security/seccomp/
[13]Oracle Linux 7 / 8 – UEK R6 – https://linux.oracle.com/errata/ELSA-2026-50255.html
[14]Oracle Linux 8 / 9 – UEK R7 – https://linux.oracle.com/errata/ELSA-2026-50253.html
[15]Oracle Linux 9 / 10 – UEK R8 – https://linux.oracle.com/errata/ELSA-2026-50254.html

Updated on May 7, 2026
Was this article helpful?
Yes No

Related Articles