27. Oktober 2026Anthropic · SicherheitKuratiert

Root aus der Ferne über Multipath TCP: Die Kernel-Lücke CVE-2026-98432 und die Voreinstellung in Go

Zusammenfassung

Das Frontier Red Team von Anthropic beschreibt in einem Bericht über fünf mit Claude gefundene Angriffsketten eine Race Condition im TCP-Stack des Linux-Kernels, über die ein entfernter Angreifer ohne Zugangsdaten auf Servern mit Multipath-TCP-Listener Befehle als root ausführen kann (CVE-2026-98432). Der Fehler steckt im Aufbau von IPv4-Verbindungen und ist in allen gepflegten stabilen Kerneln korrigiert, Ubuntu und Red Hat lieferten Ende Oktober 2026 aber noch keine vollständigen Updates. Brisant wird die Lücke durch Go: Seit Version 1.24 öffnen Go-Programme unter Linux ihre Listener standardmäßig mit MPTCP, sodass viele Dienste die Voraussetzung erfüllen, ohne dass ihre Betreiber davon wissen.

Was im Kernel schiefgeht

Der Fehler liegt im Code, der neue IPv4-TCP-Verbindungen aufbaut. Laut LWN muss die Antwort auf ein wiederholt gesendetes SYN-Paket genau in dem Moment entstehen, in dem ein anderer Thread die Verbindung bereits fertig aufbaut. Der zweite Thread gibt dabei die Struktur mit den IP-Optionen der Verbindung frei, der erste greift danach noch darauf zu. Diese Fehlerklasse heißt Use-after-free.

Die Bewertung des Kernel-CVE-Teams setzt einen Angreifer voraus, der Verbindungsanfragen mit den IPv4-Optionen Record Route oder Timestamp schickt und sie wiederholt, bis das Timing passt. IPv6 ist laut Golem offenbar nicht betroffen, weil der Kernel die Optionen dort kopiert. Die Korrektur gibt die Struktur erst nach einer RCU-Wartefrist frei, also erst, wenn keine andere CPU sie mehr verwenden kann.

Golem zufolge reicht der Fehler bis Linux 4.4 zurück. Der Fix ging am 5. Oktober 2026 in den Hauptzweig, rund zehn Tage vor der Veröffentlichung der CVE; als Melder wird Xinyang Ge von Anthropic genannt.

Wie der Exploit arbeitet

Anthropic beschreibt zwei Stufen. Zuerst bringt die Race Condition den Kernel dazu, ein vom Angreifer gesetztes Längenfeld zu lesen und zusätzliche Bytes zurückzuschicken. Sobald in einer solchen Antwort ein Kernel-Zeiger steckt, kennt der Angreifer das Speicherlayout, und KASLR ist ausgehebelt.

In der zweiten Stufe löst derselbe Fehler einen Pufferüberlauf aus, der einen Callback-Zeiger überschreibt. Er zeigt dann auf Code, den der Angreifer vorher über eine gewöhnliche Protokollfunktion im Kernel-Speicher abgelegt hat. Ruft der Kernel den Callback auf, verkettet dieser vorhandene Kernel-Funktionen bis zu einem frei gewählten Shell-Befehl mit root-Rechten.

Entscheidend für die Praxis: Ein verlorener Wettlauf lässt nur den einzelnen Verbindungsaufbau scheitern, das System läuft weiter. Im Test von Anthropic dauerte das Auslesen eines Kernel-Zeigers 48 Minuten, die Befehlsausführung weitere fünf Minuten. Exploit-Code, Kernel-Version und Testkonfiguration hat Anthropic nicht veröffentlicht.

Warum Go die Angriffsfläche vergrößert

Eine Anwendung muss MPTCP unter Linux ausdrücklich beim Öffnen des Sockets anfordern. Genau das tut Go seit Version 1.24 für Listener automatisch: net.ListenConfig verwendet MPTCP standardmäßig, wo der Kernel es unterstützt. Viele Netzdienste sind in Go geschrieben, Reverse Proxies, Exporter, Container-Werkzeuge, und sie alle bringen damit einen MPTCP-Listener mit.

Das Go-Sicherheitsteam schrieb am 29. Oktober auf golang-announce, der Fehler sei nicht an MPTCP gebunden; Systeme ohne MPTCP-Listener könnten für ähnliche Angriffe ebenfalls anfällig sein. Wer MPTCP pro Programm abschaltet, mit GODEBUG=multipathtcp=0 zur Laufzeit oder godebug multipathtcp=0 in go.mod beim Bauen, hat deshalb nur einen brüchigen Schutz: Ein einziger vergessener Listener genügt. Die Voreinstellung in Go will das Team vorerst nicht ändern.

Wie weit die Distributionen sind

Korrigiert ist der Fehler in den stabilen Kerneln 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Debian hat ihn für trixie mit DSA-6568-1 und dem Kernelpaket 6.12.113-1 ausgeliefert; Oracle Linux, SUSE und Amazon Linux haben laut Golem zumindest für einige Kernel Pakete. Ubuntu führte am 29. Oktober die Versionen 16.04 bis 26.10 als verwundbar oder in Bearbeitung, Red Hat verschob die Korrektur für RHEL 8, 9 und 10 auf ein späteres Update.

Die Bewertungen gehen weit auseinander: Das Kernel-CVE-Team vergab 9,8 von 10 Punkten, Oracle und SUSE 8,1, Amazon 7,0. Red Hat nannte auf seiner CVE-Seite zuerst 5,9 („Moderate“) und stufte am 29. Oktober auf 8,1 („Important“) hoch. Der Unterschied liegt vor allem darin, wie schwer man den Wettlauf gewinnt. Angriffe sind bisher nicht bekannt, im KEV-Katalog der CISA stand die Lücke am 28. Oktober nicht.

Ideen

Ein Wettlauf beim Verbindungsaufbau gibt Speicher frei, den ein anderer Thread noch liest.
Ein verlorener Wettlauf kostet den Angreifer nur einen Verbindungsversuch, keinen Absturz.
Ein Speicherleck über zu viele Antwortbytes hebelt KASLR aus der Ferne aus.
MPTCP pro Programm abschalten schützt nur, solange kein Listener vergessen wird.
Ein installierter Kernel schützt erst nach dem Neustart.
Distributionen bewerten dieselbe Lücke zwischen 5,9 und 9,8 Punkten.

Einsichten

Eine Voreinstellung in einer Laufzeitumgebung verschiebt die Angriffsfläche ganzer Serverlandschaften, ohne dass ein Betreiber etwas konfiguriert. Wer wissen will, was ein System anbietet, muss die tatsächlich offenen Sockets ansehen, nicht die Konfigurationsdateien.
Race Conditions galten im Netzwerkcode oft als schwer ausnutzbar. Wenn jeder Fehlversuch folgenlos bleibt, wird aus „schwer“ nur „dauert eine Stunde“; Bewertungen, die auf hoher Angriffskomplexität beruhen, unterschätzen das.
Weder CVE-Eintrag noch Patch erwähnen MPTCP. Wer Sicherheitsmeldungen nur nach betroffenen Funktionen filtert, hätte die Lücke für die eigenen Go-Dienste übersehen.

Zitate

„An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed.“ (Anthropic; sinngemäß: Ein verlorener Wettlauf lässt nur den Verbindungsaufbau scheitern, ohne das System abstürzen zu lassen, deshalb kann ein entschlossener Angreifer es beliebig oft versuchen.)
„The best fix for this vulnerability is to upgrade to a patched kernel version.“ (Go-Sicherheitsteam auf golang-announce am 29. Oktober 2026; sinngemäß: Die beste Abhilfe ist ein korrigierter Kernel.)

Fakten

CVE-2026-98432 ist ein Use-after-free beim Aufbau von IPv4-TCP-Verbindungen; das Kernel-CVE-Team bewertet ihn mit 9,8.
Korrigiert in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3; Debian trixie ab 6.12.113-1 (DSA-6568-1).
Im Test von Anthropic: 48 Minuten bis zum Kernel-Zeiger, weitere fünf Minuten bis zum root-Befehl.
Go 1.24 und neuer verwendet für Listener unter Linux standardmäßig MPTCP; abschaltbar mit GODEBUG=multipathtcp=0.
Am 28. Oktober 2026 stand die Lücke nicht im KEV-Katalog der CISA; Angriffe sind nicht bekannt.

Referenzen

Kritik

Anthropic nennt einen MPTCP-Listener als Voraussetzung, erklärt aber nicht, warum der Exploit ihn braucht, und verschweigt Kernel-Version und Konfiguration. Ob Server ohne MPTCP gefährdet sind, können Betreiber damit nicht selbst abschätzen; das Go-Sicherheitsteam hält es ausdrücklich für möglich.

Bemerkungen

Der Bericht ist auch Werbung für Anthropics Modelle und das Cyber Verification Program. Die technischen Angaben zur Lücke bestätigen Kernel-Commit, CVE-Eintrag und die Hinweise der Distributionen unabhängig davon.
Red Hat hält derzeit keine Abhilfe außer dem Patch für ausreichend. Ob das Abschalten von MPTCP oder das Filtern von IP-Optionen das Risiko senkt, ist laut Golem offen.

Empfehlungen

Kernelstand prüfen: uname -r mit den korrigierten Versionen vergleichen; unter Debian trixie mindestens 6.12.113-1 installieren und neu starten, denn bis zum Neustart läuft der alte Kernel weiter.
Offene MPTCP-Listener samt Prozess anzeigen: ss -Mlnp. Jeder Treffer ist ein Dienst, der die im Bericht beschriebene Voraussetzung erfüllt.
Wo der Patch noch fehlt, verhindert sysctl net.mptcp.enabled=0 systemweit neue MPTCP-Sockets. Das ist ein Notbehelf, kein Ersatz für den Kernel: Ob es den Angriff sicher verhindert, ist nicht belegt.
Eigene Go-Dienste, die kein MPTCP brauchen, mit godebug multipathtcp=0 in go.mod bauen oder per net.ListenConfig.SetMultipathTCP(false) festlegen.

Bericht lesen

Im Webarchiv suchen