Cart

    Sorry, we could not find any results for your search querry.

    Copy Fail (CVE-2026-31431): controlling and patching your Linux VPS

    Copy Fail (CVE-2026-31431) is a vulnerability in the Linux kernel that allows a local user to gain root privileges. The vulnerability was publicly disclosed on 29 April 2026 and affects many Linux distributions with kernels from 2017 or later.

    In this article, you will check whether your VPS is at risk, update the kernel and, if necessary, apply a temporary workaround if you cannot reboot immediately.

    • TransIP’s hypervisors have been patched. Your VPS runs your own Linux installation. Therefore, update the kernel inside your VPS using the steps in this article.
       
    • Copy Fail is not a vulnerability that can be exploited remotely without additional access. The impact is especially high when someone can already execute local code, for example via a shell account, a vulnerable web application, a CI/CD runner or a container with untrusted workloads.
     

     

    What does Copy Fail do?

     

    Copy Fail is located in the algif_aead component of the Linux kernel crypto API. By combining AF_ALG with splice(), a local user can write four controlled bytes to the page cache of a readable file. If that change affects, for example, a setuid binary such as /usr/bin/su, the user can gain root privileges.

    The vulnerability is particularly relevant because the exploit works reliably, does not require a race condition and can also have an impact in container environments. Containers share the host’s kernel.

    The upstream Linux kernel contains the patch in commit a664bf3d603d. Distributions such as Ubuntu provide the patch through their own kernel or security updates.


     

    Determine the priority

     

    Risk When does this apply? When should you patch?
    High CI/CD runners, build servers, multi-user shells, Kubernetes nodes with multiple tenants or other systems running untrusted code Today
    Medium A single-tenant production VPS with a publicly accessible web application or API that could allow local code execution if vulnerable Within 7 days
    Lower A VPS where only you have shell access and where you do not run untrusted code During your normal maintenance window

     

    Temporary workaround without a reboot

     

    Can’t you reboot immediately? Temporarily disable the vulnerable algif_aead kernel module. Only use this as a temporary measure; the proper solution remains installing and loading a patched kernel.

     

    Step 1

    Check whether the module is loaded:

    grep -qE '^algif_aead ' /proc/modules && echo "algif_aead is loaded" || echo "algif_aead is not loaded"

     

    Step 2

    Block the module from being loaded again and remove it from the running kernel:

    echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
    sudo rmmod algif_aead

    Do you receive the message Module algif_aead is in use? Then check which processes are using AF_ALG:

    sudo lsof | grep AF_ALG
    sudo ss -xa | grep alg

    First stop the processes using the module and then run sudo rmmod algif_aead again.


     

    Step 3

    Remove the workaround after you have installed a patched kernel and your VPS is successfully running on that kernel:

    sudo rm /etc/modprobe.d/disable-algif.conf

    Then reboot your VPS at a suitable maintenance moment.

    This workaround normally does not affect LUKS/dm-crypt, SSH, IPsec/XFRM, kTLS or standard OpenSSL/GnuTLS/NSS configurations. The possible impact is mainly on applications that explicitly use AF_ALG, such as OpenSSL with the afalg engine or specific embedded crypto offload applications.

     

     

    Check and update your Linux VPS

     

    Step 1

    Connect to your VPS via SSH or the VPS console.


     

    Step 2

    Check which kernel your VPS is currently using:

    uname -r

    Note the output. After the update, check again whether your VPS is running a newer kernel. Do not rely on the version number alone: distributions regularly backport security fixes to existing kernel series.


     

    Step 3

    Update your distribution. Choose the command that matches your operating system.

    Ubuntu, Debian, Zorin, Kali and other apt-based distributions:

    sudo apt -y update
    sudo apt -y upgrade

    AlmaLinux, Rocky Linux, RHEL, Oracle Linux, CloudLinux, Fedora and CentOS Stream:

    sudo dnf -y upgrade --refresh

    openSUSE Leap:

    sudo zypper refresh
    sudo zypper update -y

    openSUSE Tumbleweed:

    sudo zypper refresh
    sudo zypper dup -y

    Arch Linux:

    sudo pacman -Syu

    Fedora CoreOS:

    sudo rpm-ostree upgrade

    Are you using CentOS 7 or another end-of-life distribution? You may no longer receive a regular kernel update. Migrate to a supported distribution or temporarily use the workaround later in this article while you plan the migration.


     

    Step 4

    Reboot your VPS so the new kernel is loaded:

    sudo reboot

    Wait approximately 30 seconds and then reconnect via SSH or the VPS console.


     

    Step 5

    Check again which kernel is running:

    uname -r

    Then check whether your distribution mentions the fix in the installed packages. This check differs per distribution family.

    Debian and Ubuntu:

    zgrep -i "CVE-2026-31431" /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz

    RHEL family, such as AlmaLinux, Rocky Linux, RHEL and Oracle Linux:

    rpm -q --changelog kernel | grep -i "CVE-2026-31431"

    If you receive output, the installed kernel package contains a reference to the fix. If you receive no output, check your distribution’s security advisory for the exact fixed package. Distributions do not always mention CVEs in changelogs in the same way.


     

    Frequently asked questions

     

    Has my VPS already been hacked?

    Not automatically. Copy Fail requires local code execution. Does your VPS have shell accounts for multiple users, containers with untrusted workloads, a CI/CD runner or a publicly accessible application that could potentially allow code execution? Then check your logs and run a security audit. In all cases, patching remains necessary.

     
     

    How do I know whether it has been exploited?

    The exploit modifies the page cache and not the file on disk. As a result, direct forensic traces are limited. Look for unusual AF_ALG socket activity in audit logs, unexpected root shells, suspicious setuid binaries and abnormal processes around the time of possible exploitation. Tools such as auditd, osquery or an EDR solution can help with this.

     
     

    Does the workaround work with LUKS or dm-crypt?

    Yes. LUKS and dm-crypt use the in-kernel crypto API directly and not via AF_ALG. Disabling algif_aead therefore has no impact on disk encryption.

     
     

    Does TransIP still need to take action on my VPS?

    No. The host and virtualisation layer has been patched. Your VPS runs your own Linux installation; you update it yourself using the packages from your distribution.

     
     

    dnf shows no updates available. What now?

    First force a refresh:

    sudo dnf clean all
    sudo dnf -y upgrade --refresh

    If you still do not receive an update after that, check whether your distribution is still supported and whether your vendor mirror has already synchronised the update.

     
     

     

    More information

     


     

    In this article, you checked which kernel your VPS uses, updated the kernel and, if necessary, applied a temporary workaround. Contact our support team via your control panel if you are unsure whether your distribution still receives security updates.

    Need help?

    Receive personal support from our supporters

    Contact us