Eine Lücke im Netzwerk-Code des Linux-Kernels erlaubt es Angreifern unter bestimmten Bedingungen, einen Server ohne Passwort und ohne Zutun eines Nutzers aus der Ferne zu übernehmen. Die Schwachstelle CVE-2026-98432 steckt seit Kernel 4.4 im Code – also in praktisch jedem Linux-Server der letzten zehn Jahre. Debian hat bereits Updates ausgeliefert, für Ubuntu und Red Hat Enterprise Linux gibt es Stand 30. Oktober noch keinen fertigen Patch. Wir erklären, was das für Ihre Server bedeutet und was Sie jetzt tun sollten.
Was ist passiert
Der Fehler liegt im Aufbau von IPv4-TCP-Verbindungen, also in dem Schritt, mit dem jede Verbindung zu einem Webserver, einer Datenbank oder einem Mailserver beginnt. Wenn mehrere Prozessorkerne gleichzeitig dieselbe Verbindungsanfrage bearbeiten, kann der Kernel einen Speicherbereich freigeben, der noch benutzt wird (eine sogenannte Use-after-free-Race-Condition). Mit gezielt getakteten Netzwerkpaketen lässt sich das ausnutzen.
Die Kernel-Entwickler haben den Fehler Anfang Oktober behoben, die CVE-Nummer wurde am 15. Oktober veröffentlicht. Für Aufsehen sorgte der Fall Ende Oktober: Das KI-Unternehmen Anthropic berichtete, dass sein Modell Claude in einer Laborumgebung einen funktionierenden Angriff entwickelt hat. Gegen einen Server mit aktivem Multipath-TCP (MPTCP) dauerte es rund 48 Minuten, einen Kernel-Zeiger auszulesen, und weitere fünf Minuten bis zur Ausführung von Befehlen mit Root-Rechten. Ein fehlgeschlagener Versuch bringt den Server nicht zum Absturz – ein Angreifer kann es also beliebig oft probieren.
Wie gefährlich ist die Lücke? Die Bewertungen gehen auseinander:
- Kernel-CVE-Team (und NVD): CVSS 9.8 – kritisch
- Red Hat und SUSE: 8.1 – hoch, weil Red Hat die Ausnutzung als schwierig einstuft
- Ubuntu: Priorität „High“
Aktive Angriffe sind bisher nicht bekannt, die Lücke steht nicht im CISA-Katalog ausgenutzter Schwachstellen. Dass eine KI den Exploit geschrieben hat, zeigt aber: Die Zeit zwischen Veröffentlichung und erstem Angriff wird kürzer.
Wer ist betroffen
Grundsätzlich jeder Linux-Rechner mit einem aus dem Netz erreichbaren IPv4-TCP-Dienst – Webserver, Datenbank, SSH, Mailserver, Container-Hosts und Virtualisierungs-Hosts. Der Stand der Updates (30. Oktober 2026):
- Debian 13 (trixie): behoben ab
linux 6.12.113-1(DSA-6568-1) - Debian 12 (bookworm): behoben ab
linux 6.1.190-1, beim 6.12-Kernel ab6.12.113-1~deb12u1 - Ubuntu 22.04, 24.04, 26.04 LTS und 26.10: Patch in Arbeit, noch nicht veröffentlicht; ältere Versionen (16.04–20.04) als verwundbar gelistet
- RHEL 8, 9 und 10: betroffen, Fix laut Red Hat noch nicht verfügbar
- Oracle Linux (UEK): behoben; Amazon Linux 2023 und SUSE teilweise behoben
- Proxmox VE: Achtung – Proxmox nutzt nicht den Debian-Kernel, sondern einen eigenen Kernel auf Ubuntu-Basis. Das Debian-Update allein schützt den Proxmox-Host daher nicht. Nach Angaben aus der Proxmox-Community enthält der Kernel ab
7.0.14-25-pve(Repository „no-subscription“ bzw. „test“) die Korrektur; eine offizielle Bestätigung von Proxmox stand bei Redaktionsschluss noch aus.
Gefixte Upstream-Kernel sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 und 7.2.10. Wichtig: Distributionen übernehmen Korrekturen in eigene Versionsnummern. Maßgeblich ist daher immer die Sicherheitsmeldung Ihres Anbieters.
Was Sie jetzt tun sollten
- Bestand erfassen: Auf jedem Server
uname -rundcat /etc/os-releaseausführen und notieren, welche Systeme aus dem Internet erreichbar sind (ss -lntpzeigt die offenen Dienste). - Debian-Systeme sofort aktualisieren:
apt update && apt full-upgrade, danach neu starten – ohne Neustart läuft der alte Kernel weiter. - Proxmox-Hosts prüfen: Läuft ein Kernel älter als
7.0.14-25-pve, das Update einplanen und VMs vorher migrieren oder ein Wartungsfenster festlegen. Nutzer mit Subscription sollten den Stand beim Proxmox-Support bestätigen lassen. - Ubuntu und RHEL beobachten: Die Sicherheitsseiten von Canonical und Red Hat täglich prüfen und das Update einspielen, sobald es erscheint. Automatische Sicherheitsupdates (z. B.
unattended-upgrades) helfen, aber der Neustart muss geplant werden. - Angriffsfläche verkleinern: Nur die Dienste ins Internet stellen, die wirklich nötig sind; Verwaltungszugänge wie SSH oder Datenbanken hinter VPN oder Firewall-Regeln legen.
- Übergangslösung prüfen: Wer MPTCP nicht braucht, kann es mit
sysctl -w net.mptcp.enabled=0abschalten. Der veröffentlichte Angriff zielte auf MPTCP – ob das allein vollständig schützt, ist aber nicht belegt. Red Hat hält bisher keinen Workaround für ausreichend. Das Kernel-Update bleibt der einzige verlässliche Schutz. - Vorlagen nicht vergessen: VM-Templates, Container-Basis-Images und Cloud-Vorlagen aktualisieren, damit keine neuen verwundbaren Systeme entstehen.
Wie Sadeem hilft
Wir betreiben Linux-Server, Container-Plattformen und Proxmox-Cluster für mittelständische Unternehmen – in Rechenzentren in Deutschland und der EU. Im Rahmen unseres Managed Hostings übernehmen wir Bestandsaufnahme, Kernel-Updates mit geplanten Neustarts, Live-Migration von VMs und Monitoring, damit Lücken wie diese ohne Ausfallzeit geschlossen werden. Sie sind unsicher, ob Ihre Server betroffen sind? Im kostenlosen Erstgespräch prüfen wir gemeinsam Ihren Stand.