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. In diesem Artikel zeige ich dir, wie du in unter einer Minute prüfst, ob dein System betroffen ist, und wie du es sauber patchst – inklusive Workaround, falls du gerade nicht neu starten kannst.
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 viele Kernel-Bugs hängt der Exploit nicht an einer Race-Condition – er ist deterministisch, also zuverlässig auslösbar. 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.
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. Wer irgendeinen Linux-Server betreibt – ob gemieteten vServer, Webserver, Proxmox-Host oder NAS – der seit Längerem keinen Kernel-Reboot gesehen hat, sollte heute prüfen (uname -r) und patchen – das sind 15 Minuten Aufwand für dauerhafte Sicherheit. 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
Reicht ein Update ohne Reboot aus? ▾
Nein. apt upgrade bzw. dnf update installiert das neue Kernel-Paket, aber dein System läuft weiter auf dem alten, verwundbaren Kernel im Speicher. Erst nach einem Reboot ist der Patch aktiv. Prüfe mit uname -r, ob die gepatchte Version tatsächlich läuft.
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.
Betrifft die Sicherheitslücke auch meine Docker- oder LXC-Container? ▾
Ja. Container teilen sich den Kernel des Hosts. Ist der Host-Kernel verwundbar, kann ein Angreifer aus einem Container ausbrechen und root auf dem Host erlangen. Du patchst den Host-Kernel, nicht den Container – die Container selbst haben keinen eigenen Kernel.
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.