Als ich am Wochenende meine Linux-Maschinen durchgegangen bin, ist mir aufgefallen, dass mein ältester Root-Server seit Monaten keinen Kernel-Reboot mehr gesehen hat – und genau das ist bei CVE-2026-31431 das Problem. Die Lücke, die unter dem Codenamen „Copy Fail” läuft, steckt seit 2017 im Linux-Kernel und betrifft praktisch jeden Linux-Server, der in der Zeit nicht durchgepatcht und neu gestartet wurde. Sie erlaubt einem lokalen Nutzer, sich root-Rechte zu verschaffen.
Betroffen ist damit so ziemlich alles, was bei dir auf Linux läuft: der gemietete vServer, der Webserver, die VPS in der Cloud, genauso wie der Proxmox-Host, das NAS oder der Selfhosting-Server im Heimnetz. Wer einen Linux-Host mit mehreren Diensten oder Containern betreibt, hat hier ein echtes Sicherheits-Problem. Den Check unten habe ich auf meinem eigenen Wust aus Debian-, Proxmox- und einem altersschwachen CentOS-Host laufen lassen – er funktioniert überall gleich.
Was ist CVE-2026-31431 („Copy Fail”)?
CVE-2026-31431 ist eine Local Privilege Escalation (LPE) im Linux-Kernel: ein lokaler Benutzer ohne besondere Rechte kann sich zu root hochstufen. Ursache ist eine fehlerhafte In-Place-Optimierung, die 2017 im Crypto-Modul algif_aead (das die Kernel-Crypto-API über die AF_ALG-Socket-Schnittstelle bereitstellt) eingeführt wurde. Über die Kombination aus einem AF_ALG-Socket und dem splice()-Syscall lässt sich ein kontrollierter 4-Byte-Schreibzugriff in den Page-Cache eines beliebigen lesbaren Files auslösen – damit lässt sich eine gecachte setuid-Binary wie /usr/bin/su im Speicher manipulieren, ohne die Datei auf der Platte anzufassen.
Der Schweregrad liegt bei CVSS 7.8 (HIGH), Vektor CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, eingeordnet als CWE-669 (Incorrect Resource Transfer Between Spheres). Anders als die meisten Kernel-Bugs braucht der Exploit keine Race-Condition. Er triggert deterministisch – du brauchst keine tausend Versuche, einer reicht. Die Lücke wurde am 22.04.2026 im NVD veröffentlicht, am 29.04. gab es Public Disclosure samt öffentlichem Proof-of-Concept, und seit dem 01.05.2026 steht sie im CISA Known-Exploited-Vulnerabilities-Katalog. Technische Details findest du auf der offiziellen Seite copy.fail.
Bist du betroffen?
Kurz gesagt: Wenn du einen Linux-Kernel zwischen 4.14 und 6.19.11 fährst, lautet die Antwort wahrscheinlich Ja. Den einen entscheidenden Befehl gibst du so ein:
uname -rLiegt die ausgegebene Version unterhalb der gepatchten Version deiner Distribution (siehe Tabelle im nächsten Abschnitt), bist du verwundbar. Die betroffenen Upstream-Kernel im Überblick:
| Kernel-Linie | Verwundbar bis (exklusive) |
|---|---|
| 4.14 – 5.10 | < 5.10.254 |
| 5.15 LTS | < 5.15.204 |
| 6.1 LTS | < 6.1.170 |
| 6.6 LTS | < 6.6.137 |
| 6.12 LTS | < 6.12.85 |
| 6.18 | < 6.18.22 |
| 6.19 | < 6.19.12 |
Die algif_aead-Komponente wird bei Bedarf automatisch nachgeladen, weshalb du dich nicht in Sicherheit wiegen solltest, nur weil das Modul gerade nicht aktiv ist. Trotzdem zwei nützliche Zusatz-Checks – ob das Modul aktuell geladen ist und ob die verwundbare Krypto-API überhaupt einkompiliert wurde:
grep -qE '^algif_aead ' /proc/modules && echo "geladen" || echo "nicht geladen"
grep CONFIG_CRYPTO_USER_API_AEAD "/boot/config-$(uname -r)"Welche Kernel-Pakete installiert sind, zeigt dir je nach Distribution:
# Debian / Ubuntu / Proxmox
dpkg -l 'linux-image*' 'pve-kernel-*' | grep ^ii
# RHEL / AlmaLinux / Rocky
rpm -q kernel kernel-coreMein Admin-Tipp: Vergiss deine Container nicht. Docker- und LXC-Container teilen sich den Kernel des Hosts – ein verwundbarer Host bedeutet, dass ein Angreifer aus einem kompromittierten Container heraus den ganzen Node übernehmen kann (Container-Breakout). Auf einem vollgepackten Webserver oder einem Proxmox-Host mit mehreren Gästen ist das der wunde Punkt, weil dort oft Dienste laufen, die direkt aus dem Internet erreichbar sind.
Fix: Kernel patchen
Der saubere Weg ist immer der Kernel-Patch. Der Upstream-Fix (Commit a664bf3d603d) macht die fehlerhafte 2017er-Optimierung rückgängig und ist in alle Stable-Branches zurückportiert. Wichtig: Ein neuer Kernel wird erst nach einem Reboot aktiv – apt upgrade allein reicht nicht.
Debian / Ubuntu:
sudo apt update && sudo apt full-upgrade
sudo rebootProxmox VE:
apt update && apt full-upgrade
rebootRHEL / AlmaLinux / Rocky:
sudo dnf update kernel
sudo rebootDie gepatchten Versionen je Distribution – wenn uname -r nach dem Reboot diese Version (oder höher) zeigt, bist du raus:
| Distribution | Gepatchte Version |
|---|---|
| Ubuntu 24.04 (Noble) | 6.8.0-117.117 (HWE: 6.17.0-29.29~24.04.1) |
| Ubuntu 22.04 (Jammy) | 5.15.0-179.189 |
| Ubuntu 20.04 (Focal) | 5.4.0-230.250 |
| Debian 12 (Bookworm) | 6.1.170-3 |
| Debian 11 (Bullseye) | 5.10.251-5 / 6.1.172-1 |
| Proxmox VE | pve-kernel 6.17.13-6-pve / 6.14.11-7-pve |
| AlmaLinux 9 | kernel-5.14.0-611.49.2.el9_7 |
Auf Ubuntu mit aktivierten unattended-upgrades (Standard ab 16.04 LTS) wird der Patch in der Regel innerhalb von 24 Stunden automatisch eingespielt – den Reboot musst du aber trotzdem selbst anstoßen. Details und alle HWE-Varianten stehen im Ubuntu-Advisory, für Enterprise-Distributionen im Red Hat RHSB-2026-002.
Workaround ohne Reboot
Wenn du einen Produktiv-Host nicht sofort neu starten kannst (laufende VMs, Wartungsfenster erst später), gibt es eine Mitigation: das verwundbare Modul deaktivieren und entladen.
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null
grep -qE '^algif_aead ' /proc/modules && echo "noch geladen" || echo "entladen"Die erste Zeile verhindert, dass das Modul künftig nachgeladen wird, die zweite entlädt es sofort. Ehrlich gesagt ist das nur ein Notbehelf für die Stunden bis zum nächsten Reboot: Es funktioniert nur, wenn auf dem System keine eigene Software die AF_ALG-Krypto-API über algif_aead braucht (selten, aber z. B. manche Krypto-Tools tun das). Und es schützt nur diesen einen Angriffsvektor. Der richtige Fix bleibt der gepatchte Kernel plus Reboot – plane den zeitnah ein, statt dich dauerhaft auf die Mitigation zu verlassen.
Wer den Host ohnehin per VPN administriert, kann den Reboot entspannt aus der Ferne fahren – wie du WireGuard dafür sauber aufsetzt, steht in der WireGuard-VPN-Anleitung.
Und wenn du gerade ohnehin am Kernel-Patchen bist: Wenige Wochen nach Copy Fail kamen mit Dirty Frag (CVE-2026-43284/43500) und ssh-keysign-pwn (CVE-2026-46333) zwei weitere Kernel-Lücken – jeweils mit eigener Mitigation, die du im selben Wartungsfenster gleich miterledigen solltest.
Fazit
CVE-2026-31431 ist keine theoretische Lücke: Der Proof-of-Concept ist öffentlich, sie steht im CISA-KEV-Katalog, und der deterministische Exploit macht sie für Angreifer attraktiv. Wenn deine Kiste seit Monaten keinen Kernel-Reboot gesehen hat, ist sie mit hoher Wahrscheinlichkeit angreifbar. Bei mir war der Reboot des alten Root-Servers nach fünf Minuten durch – die eigentliche Arbeit war herauszufinden, dass er überhaupt noch lief. Schieb es nicht auf: Eine LPE ist die ideale zweite Stufe nach jedem kleineren Einbruch, und genau deshalb ist sie für deine Sicherheit so kritisch.
Häufige Fragen
Was, wenn ich einen selbst gebauten Kernel ohne Distro-Pakete fahre? ▾
Dann hilft dir keine Versionstabelle – du musst selbst sicherstellen, dass der Fix-Commit a664bf3d603d (Revert der 2017er-In-Place-Optimierung) in deinem Source-Tree ist. Entweder du ziehst den aktuellen Stable-Branch deiner Kernel-Linie und baust neu, oder du cherry-pickst den Commit gezielt. Bis dahin greift als Brücke der Modul-Block aus dem Workaround-Abschnitt, der unabhängig vom Kernel-Build funktioniert.
Ich bin nicht betroffen, wenn algif_aead nicht geladen ist – stimmt das? ▾
Nein, das ist ein Trugschluss. Der Kernel lädt das Modul bei Bedarf automatisch nach, sobald ein Prozess einen AF_ALG-Socket öffnet. Entscheidend ist die Kernel-Version, nicht der aktuelle Lade-Zustand des Moduls. Nur das explizite Blockieren via modprobe.d (siehe Workaround) verhindert das Nachladen.
Schützen mich gVisor oder Kata Containers vor der Lücke? ▾
Teilweise – und das ist der Grund, warum sie existieren. Klassische Docker-/LXC-Container teilen sich den Host-Kernel und sind daher voll exponiert. gVisor (eigener User-Space-Kernel) und Kata Containers (echte Mikro-VM pro Container) schieben dagegen eine zusätzliche Kernel-Schicht dazwischen, die den direkten AF_ALG-Angriff auf den Host abschirmt. Sie ersetzen aber nicht das Patchen: Der Host-Kernel bleibt verwundbar, und nicht jeder Workload läuft sauber unter gVisor.
Braucht der Angreifer physischen oder lokalen Zugang? ▾
Es ist eine Local Privilege Escalation, also braucht der Angreifer bereits Code-Ausführung als irgendein lokaler Nutzer. Das klingt nach einer hohen Hürde, ist aber niedrig: Jeder kompromittierte Webdienst, jede unsichere App oder ein gekaperter Container reicht als Ausgangspunkt, um die Lücke zur root-Übernahme zu nutzen.
Kann ich den Reboot mit Live-Patching umgehen? ▾
Teilweise. Dienste wie Ubuntu Livepatch, Red Hat kpatch oder KernelCare können viele Kernel-Lücken zur Laufzeit patchen – ob CVE-2026-31431 abgedeckt ist, hängt vom Anbieter ab und steht in dessen Advisory. Verlass dich nicht blind darauf: Prüfe mit canonical-livepatch status (Ubuntu) bzw. kpatch list, ob der Fix wirklich „applied” ist. Ist er es nicht, bleibt der normale Patch plus Reboot der einzige verlässliche Weg.
Sollte ich meine VM-Templates und Snapshots auch patchen? ▾
Ja, das wird gern vergessen. Goldene Images, VM-Templates und Container-Base-Images tragen den verwundbaren Kernel weiter, sobald du daraus neue Maschinen ausrollst. Aktualisiere die Templates einmal sauber, sonst klonst du dir die Lücke immer wieder neu ins Setup – ein klassischer Fehler, der CVEs lange nach dem eigentlichen Patch-Tag am Leben hält.