Skip to content
EuroVPSEuroVPS

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

EuroVPS FAQ

Updated 9 min read

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 multi-tenant 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 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 is additional hardening for servers with LiteSpeed's lscgid binary; the kernel update or mitigation above is still required.

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.

Option A: Upgrade to LiteSpeed Enterprise 6.3.5 Build 5 or newer Recommended

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

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.


Recommended EuroVPS action plan

EuroVPS recommends the following action plan:

  1. Beyond patch and reboot: apply seccomp policies to container workloads, retire end-of-life operating systems, and on LiteSpeed Enterprise upgrade to 6.3.5 Build 5 or remove the setuid bit from lscgid.

Need Assistance?

If you would like our engineers to check, patch, mitigate and verify your server, open a support ticket from the Client Area with the hostname or IP; share root access only through the ticket's secure credentials field, never in the ticket text.

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

From the EuroVPS FAQ, first published 3 May 2026.

More in announcements

Your next infrastructure partner

Still have
a question?

Tell us what you are trying to do. An engineer will read it and reply.

+357 222 32280
A EuroVPS engineer carrying a server node on the datacenter floor
A conversation with the people
who will look after your infrastructure.

Let’s start with your setup.

A little context helps us start the right conversation.

We’ll use your details to respond to your enquiry. Privacy policy