Linux-TCP-Lücke CVE-2026-98432 auf CVSS 9,8 hochgestuft

Red Hat hat den CVSS-Wert der Linux-Kernel-Schwachstelle CVE-2026-98432 am 2. November auf 9,8 angehoben; zuvor lagen die Bewertungen zwischen 5,9 und 8,1. Bereits am 1. November hatte das Unternehmen gepatchte Kernel für RHEL 8, 9 und 10 veröffentlicht. Bei Ubuntu steht der Status weiterhin auf „Fix in Arbeit“.

Die Lücke steckt im Verbindungsaufbau von IPv4-TCP und lässt sich vom Netzwerk aus auslösen, ohne Authentifizierung und ohne Zutun eines Nutzers. Betroffen sind alle Versionen ab Linux 4.4; die Ursache geht auf einen Commit aus dem Jahr 2015 zurück.

Eine Race Condition, die zwei Zeilen Code behebt

Trägt ein SYN-Paket IPv4-Optionen (etwa Record Route oder Timestamp), legt der Kernel sie am Request-Socket ab. Ist der Handshake abgeschlossen, wird der Zeiger auf diesen Speicher ohne Kopie direkt an den Child-Socket weitergereicht; beide teilen sich also denselben Bereich.

Baut nun eine andere CPU wegen eines erneut gesendeten SYN gerade ein SYN-ACK und wird der Child-Socket zufällig gleichzeitig zerstört, gibt kfree() den Options-Speicher sofort frei. Der Pfad, der das SYN-ACK zusammensetzt, liest dann bereits freigegebenen Speicher.

Der Fix stammt von Eric Dumazet (Commit e3f33b0a1d89). Er ersetzt kfree() durch kfree_rcu(), sodass erst nach Ablauf der RCU-Schonfrist freigegeben wird; es sind nur zwei Zeilen. Gemeldet wurde die Schwachstelle von Xinyang Ge von Anthropic. Der CVE-Eintrag erschien am 15. Oktober; die korrigierten Versionen der stabilen Zweige sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 und 7.2.10, im Mainline-Kernel 7.3.

Anthropics Darstellung kann nur Anthropic selbst belegen

Aufmerksamkeit erhielt die Lücke durch einen Beitrag des Anthropic Frontier Red Team vom 27. Oktober. Darin heißt es, ein unveröffentlichtes internes Modell habe ein Exploit-Programm geschrieben, mit dem ein nicht authentifizierter Angreifer aus der Ferne auf Servern mit aktivem MPTCP-Listener Befehle als root ausführen kann.

Der Exploit läuft in zwei Stufen: Zuerst wird die Race Condition genutzt, um Kernel-Speicher außerhalb der Grenzen auszulesen, Zeiger preiszugeben und KASLR zu umgehen; danach überschreibt ein Out-of-Bounds-Write einen Callback-Funktionszeiger. Anthropic nennt rund 48 Minuten für das Leaken des Zeigers und weitere etwa 5 Minuten bis zur Befehlsausführung.

Mehrere Punkte sollte man auseinanderhalten. Exploit-Code, getestete Kernel-Versionen und Konfiguration sind nicht veröffentlicht, eine Überprüfung durch Dritte gibt es bislang nicht. Weder der CVE-Eintrag noch der Fix-Commit erwähnen MPTCP, und der Beitrag erklärt nicht, warum es zwingend nötig sein soll. Die 53 Minuten stammen aus einer unbekannten Umgebung und lassen sich nicht ohne Weiteres auf produktive Server übertragen. Stand 2. November hat weder ein Hersteller noch ein CERT oder das Kernel-CVE-Team Angriffe in freier Wildbahn gemeldet; auch im Katalog bekannter ausgenutzter Schwachstellen der CISA ist die Lücke nicht verzeichnet.

In manchen chinesischsprachigen Meldungen heißt es, Anthropic habe „Exploit-Beispiele veröffentlicht“. Genauer: Veröffentlicht wurde eine Beschreibung des Exploit-Ablaufs, aber kein lauffähiger Code.

Auch bei der Bewertung gibt es weiter Dissens. Das Kernel-CVE-Team und Red Hat vergeben inzwischen 9,8, Oracle, SUSE und Amazon dagegen 8,1; der Unterschied liegt darin, ob die Angriffskomplexität als niedrig oder hoch eingestuft wird. Die NVD hat noch keinen eigenen Wert veröffentlicht.

Go macht die Voraussetzung zum Standard

Eine Mitteilung des Go-Sicherheitsteams vom 29. Oktober hat die Reichweite vergrößert. Seit Go 1.24 steht der Standardwert von multipathtcp auf 2, das heißt, MPTCP ist nur auf der Listener-Seite aktiviert. Ein Go-Programm, das einen Dienst mit net.Listen startet, erfüllt damit standardmäßig die Voraussetzung, die Anthropic vorgeführt hat.

Als Gegenmaßnahme empfiehlt das Go-Team, zur Laufzeit GODEBUG=multipathtcp=0 zu setzen oder im Hauptmodul in der go.mod die Zeile godebug multipathtcp=0 einzutragen. Zugleich bezeichnet es dieses programmweise Abschalten als „a fragile mitigation“ (eine brüchige Gegenmaßnahme). Eine Änderung des Standardwerts hält das Go-Team derzeit für verfrüht. Auf Kernel-Seite lässt sich net.mptcp.enabled auf 0 setzen; das entfernt lediglich die vorgeführte Voraussetzung, die Schwachstelle selbst bleibt bestehen.

Was Administratoren zuerst tun können

Der Status der Distributionen (teils am 29. Oktober, teils am 2. November geprüft) sieht in etwa so aus:

Unter den Nutzern von Cloud-Servern ist der Ubuntu-Anteil beträchtlich, daher ist diese Zeile der Tabelle diejenige, die man am genauesten im Blick behalten sollte. Die Distributionen beheben Lücken überwiegend per Backport; ob ein System sicher ist, muss deshalb anhand der Paketversionen im jeweiligen Sicherheitshinweis geprüft werden. Wer nur die Hauptversion in uname -r betrachtet, liegt leicht daneben. Nach der Installation eines neuen Kernels ist ein Neustart nötig; Live-Patching ist ein eigener Mechanismus und muss gesondert bestätigt werden.

Für Maschinen, die vorerst keinen Patch bekommen, empfiehlt sich zunächst eine Bestandsaufnahme: Welche Dienste lauschen auf MPTCP, insbesondere Binaries, die mit Go 1.24 oder neuer gebaut wurden? Danach lässt sich entscheiden, ob man sie wie oben beschrieben abschaltet. Die Hersteller haben nicht bestätigt, dass das Deaktivieren von MPTCP das gesamte Risiko beseitigt; der Schritt verschafft nur Zeit. Tauchen in Kernel-Absturzprotokollen Funktionen wie ip_options_build auf, sollte das ebenfalls untersucht werden.

Quellen: öffentliche Wiedergaben des Beitrags des Anthropic Frontier Red Team, Schwachstellenmeldung von Rescana, CocoLoop, Mitteilung des Go-Sicherheitsteams, Security-Tracker von Debian und Red Hat; Bewertungen und Fix-Status der Distributionen richten sich nach den Angaben der jeweiligen Hersteller, die Exploit-Details von Anthropic sind nicht unabhängig bestätigt.