Kritische Linux-TCP-Schwachstelle CVE-2026-98432 erfordert sofortiges Patching

Linux-Stable-Kernel erhielten Mitte Oktober 2026 einen kritischen Sicherheitsfix für CVE-2026-98432, eine Use-After-Free-Schwachstelle im IPv4-TCP-Handshake. Die Schwachstelle ermöglicht es einem entfernten, nicht authentifizierten Angreifer, beliebigen Code mit Root-Rechten auf betroffenen Servern auszuführen. Während die Upstream-Maintainer das Problem behoben haben, bleiben viele große Enterprise-Distributionen Ende Oktober verwundbar.

Was passiert ist

Die Linux-Kernel-Community vergab der CVE-2026-98432 einen CVSS-3.1-Score von 9,8, was sie als „Critical“ (kritisch) einstuft. Die Schwachstelle befindet sich im Codepfad, der eingehende IPv4-TCP-Verbindungen verarbeitet, speziell während des initialen Handshakes, bevor eine Authentifizierung auf Anwendungsebene stattfindet. Der Bug wurde von Xinyang Ge von Anthropic gemeldet und von Eric Dumazet behoben; der Patch wurde von Kuniyuki Iwashima überprüft.

Upstream-Stable-Kernel lieferten den Fix zwischen dem 11. und 15. Oktober 2026 aus. Betroffene Versionen umfassen Long-Term-Support-Zweige wie 5.10, 5.15, 6.1, 6.6 und 6.12 sowie neuere Mainline-Releases. Die Schwachstelle lässt sich bis zu Linux 4.4 zurückverfolgen, was bedeutet, dass nahezu jeder aktive Linux-Server potenziell exponiert ist, wenn er den spezifischen Patch nicht erhalten hat. Zweige, die vor Version 5.10 das End-of-Life erreicht haben, verfügen über keinen Upstream-Fix und sind vollständig auf distributionsspezifische Backports angewiesen.

Trotz der Verfügbarkeit von Upstream-Fixes ist der Deploymentsstatus über die großen Distributionen hinweg uneinheitlich. Stand 31. Oktober 2026 listet Ubuntus Security Tracker jede Release-Version als „Vulnerable“ (verwundbar), wobei Fixes für aktuelle Versionen noch in Arbeit sind. Auch Red Hat Enterprise Linux (RHEL) 8, 9 und 10 sind als betroffen gelistet, ohne verfügbaren Fix, obwohl Red Hat die Schweregrad-Einstufung auf Critical erhöht hat. AlmaLinux hat Kernel-Fixes in Testing, während Debian, SUSE, Oracle und Amazon Linux bereits Patches für ihre unterstützten Versionen veröffentlicht haben.

Wie es funktioniert

Die Schwachstelle resultiert aus einer Race Condition bei der Verwaltung des Speichers für TCP-Verbindungsoptionen durch den Kernel. Wenn ein Server eine TCP-Verbindung akzeptiert, erstellt er einen leichtgewichtigen „Request Socket“, um den halb-offenen Handshake zu verfolgen. Wenn der verbindende Client IPv4-Header-Optionen enthält, speichert der Kernel diese, um sie in nachfolgenden Antworten zu wiederholen. Der Bug tritt auf, weil der Kernel diese Optionszeiger an den neuen Full Socket übergibt, ohne die Daten zu kopieren, und anschließend den ursprünglichen Request-Socket-Speicher sofort freigibt.

Wenn ein anderer CPU-Kern diese Optionen noch liest, um eine Antwort zu erstellen, während der Speicher freigegeben wird, tritt eine Use-After-Free-Bedingung auf. Dies kann zur Offenlegung von Kernel-Heap-Speicher, zu Speicherkorruption oder zum Systemabsturz führen. Forscher von Anthropic demonstrierten, dass diese Race Condition ausgenutzt werden kann, um Remote Code Execution zu erreichen. Bemerkenswert ist, dass ihr Proof-of-Concept-Exploit Server mit Multipath-TCP-(MPTCP)-Listenern ins Visier nahm, die in Go-Programmen ab Version 1.24 standardmäßig aktiviert sind. Allerdings ist der zugrunde liegende Bug nicht exklusiv für MPTCP, und andere Konfigurationen können ebenfalls verwundbar sein.

Der Fix ist minimal und besteht aus einer vierzeiligen Änderung, die Standard-Speicherfreigabe-Aufrufe durch kfree_rcu() ersetzt. Diese Funktion stellt sicher, dass Speicher erst freigegeben wird, nachdem alle Leser den Zugriff beendet haben, was die Race Condition verhindert. Der Patch behebt auch ähnliche Probleme in den Migration-Pfaden für Request Sockets.

Wichtige Details

• CVE-Identifier: CVE-2026-98432, eingestuft als 9,8 Critical vom Linux-Kernel-CNA.
• Art der Schwachstelle: Use-after-free bei der Behandlung von IPv4-TCP-Handshake-Optionen.
• Betroffene Systeme: Linux-Kernel ab 4.4, die IPv4-TCP-Verbindungen akzeptieren.
• Exploit-Status: Ein funktionierender Remote-Root-Exploit existiert für Server mit MPTCP-Listenern, entwickelt von Anthropic.
• Distributionen-Status: Behoben in Debian, SUSE, Oracle und Amazon Linux; ausstehend für Ubuntu und RHEL per 31. Oktober 2026.
• Mitigation: Netzwerkseitige Filterung von IPv4-Paketen mit Optionen kann die Exposition reduzieren, bis Patches angewendet werden.

Warum es wichtig ist

Für Infrastruktur-Ingenieure und Platform-Teams stellt diese Schwachstelle ein Hochrisiko-Szenario dar, da sie keine Authentifizierung erfordert und auf der Network-Stack-Ebene operiert. Da der Exploit ausgeführt wird, bevor Anwendungscode läuft, können traditionelle Web Application Firewalls oder Service-Level-Authentifizierungsmechanismen dies nicht verhindern. Die Tatsache, dass große Distributionen wie Ubuntu und RHEL noch keine Fixes veröffentlicht haben, lässt einen erheblichen Teil der Enterprise-Infrastruktur während dieses Zeitfensters exponiert.

Die Beteiligung von MPTCP erhöht die Komplexität der Risikobewertung. Da Go 1.24 MPTCP standardmäßig aktiviert, könnten viele moderne Microservices und Cloud-native Anwendungen ihre Hosts unwissentlich der am leichtesten ausnutzbaren Konfiguration aussetzen. Teams, die Go-basierte Dienste auf Linux betreiben, müssen ihren Kernel-Status überprüfen und erwägen, MPTCP zu deaktivieren, wenn sie nicht sofort patchen können. Die Verzögerung bei den distributionsspezifischen Fixes bedeutet, dass proaktive Mitigationsstrategien, wie Netzwerkfilterung, für die Aufrechterhaltung der Sicherheitslage unerlässlich sind.

Was Sie tun können

• Überprüfen Sie Ihre laufende Kernel-Version mit uname -r und vergleichen Sie sie mit dem Security Advisory Ihrer Distribution, um festzustellen, ob ein Fix verfügbar ist.
• Starten Sie Ihre Server neu, wenn ein fixierter Kernel installiert ist, um den Patch zu aktivieren, da Kernel-Updates erst nach einem Neustart wirksam werden.
• Implementieren Sie nftables- oder iptables-Regeln, um eingehende IPv4-TCP-Pakete mit IP-Optionen zu verwerfen, wenn Systeme noch nicht gepatcht werden können. Dies blockiert den Angriffsvektor.
• Deaktivieren Sie Multipath TCP, indem Sie net.mptcp.enabled = 0 in sysctl setzen, wenn Ihre Anwendungen dies nicht explizit erfordern, um die Angriffsfläche zu reduzieren.
• Überwachen Sie den Security Tracker Ihrer Distribution auf Updates, insbesondere wenn Sie Ubuntu oder RHEL betreiben, da Fixes bald erwartet werden.
• Prüfen Sie, ob lauschende Dienste MPTCP verwenden, indem Sie ss -Mlnp ausführen, und starten Sie diese Dienste nach dem Deaktivieren von MPTCP neu, um sicherzustellen, dass die Änderung wirksam wird.