Claude findet Root-Lücke im Linux-Netzwerkstack

CVE-2026-98432 steckt seit Kernel 4.4 im IPv4-TCP-Code, Anthropic hat einen Root-Exploit gebaut. Warum Go-Dienste genauer hinschauen sollten.

5 Min. Lesezeit

Im IPv4-TCP-Code des Linux-Kernels steckt seit Version 4.4 von 2015 ein Fehler, über den sich Code aus der Ferne ausführen lässt. Gefunden hat ihn Claude, Anthropic beschreibt den Fall in einem Forschungsbeitrag vom 27.10.2026. Die Lücke hat die Nummer CVE-2026-98432, das CVE-Team des Kernels bewertet sie mit CVSS 9.8 von 10. Gefixt ist sie upstream bereits, viele Distributionen liefern die Updates aber erst jetzt aus.

Was die Lücke ist

Laut der CVE-Meldung des Kernels handelt es sich um eine Race Condition beim TCP-Verbindungsaufbau. Kommt ein wiederholtes SYN-Paket mit IP-Optionen im falschen Moment, kann der Kernel auf einer CPU Speicher lesen, den eine andere gerade freigegeben hat. Fachlich ist das ein Use-after-free in ip_options_build(). IPv6 ist von diesem Weg nicht betroffen.

Ein Login oder ein Klick ist nicht nötig, es reicht, Pakete an einen offenen TCP-Port zu schicken. Anthropic schreibt, Claude habe nach einem ersten Anstoß einen Exploit gebaut, mit dem ein Angreifer auf Linux-Servern mit einem Multipath-TCP-Listener (MPTCP) beliebige Befehle als root ausführen kann. Weil ein verlorenes Rennen nur den Handshake scheitern lässt und nicht das System abstürzen, kann ein Angreifer es beliebig oft versuchen. Im Proof of Concept dauerte es 48 Minuten bis zum Kernel-Pointer und weitere fünf bis zur Shell. Den Exploit-Code hat Anthropic nicht veröffentlicht.

Red Hat sieht die Lage etwas vorsichtiger. Zuverlässige Codeausführung brauche eine präzise Kontrolle über den Kernel-Speicher, wahrscheinlicher seien Abstürze. Ausnutzung in freier Wildbahn ist bisher nicht bekannt.

Warum Go-Dienste mehr Aufmerksamkeit brauchen

Der gezeigte Exploit braucht einen MPTCP-Listener, und den haben mehr Server, als man denkt. Das Go-Security-Team weist auf oss-security darauf hin, dass Go-Programme ab Go 1.24 unter Linux MPTCP für lauschende Sockets standardmäßig einschalten. Ein ganz normaler HTTP-Dienst in Go ist damit genau das Ziel aus Anthropics Beispiel.

Abschalten lässt sich das pro Programm mit GODEBUG=multipathtcp=0 oder systemweit mit sysctl -w net.mptcp.enabled=0. Das Go-Team hält das aber nur für eine Notlösung, denn der Fehler selbst ist laut Go-Team "not specific to MPTCP". Systeme ohne MPTCP könnten auf ähnliche Weise angreifbar sein.

Was ihr tun solltet

Der eigentliche Fix ist ein aktueller Kernel. Upstream ist die Lücke in 6.12.113, 6.18.56, 7.2.10 und 7.3-rc7 geschlossen, laut NVD inzwischen auch in den älteren Langzeitzweigen 5.10, 5.15, 6.1 und 6.6. Bei den Distributionen sieht es am 31.10. gemischt aus:

DistributionStand am 31.10.2026
Debianbookworm, trixie, forky und sid gefixt
Ubuntualle unterstützten Versionen noch verwundbar, Updates in Arbeit
Red Hat Enterprise Linux 8, 9, 10betroffen, noch kein Fix ausgewiesen
SUSEteilweise Pakete veröffentlicht
AlmaLinux 8, 9, 10gepatchte Kernel im Testing-Repository

Bis der Fix da ist, helfen zwei Dinge. AlmaLinux beschreibt in einem Blogbeitrag eine nftables-Regel, die IPv4-TCP-Pakete mit IP-Optionen verwirft. Für Setups mit CIPSO oder NetLabel eignet sie sich laut AlmaLinux nicht. Die Regel überlebt keinen Neustart. Und wer MPTCP nicht braucht, schaltet es ab, wie oben beschrieben. Der Hoster Linode rollt eigene Gegenmaßnahmen für den bekannten Angriffsweg aus, Kunden sollen trotzdem die Updates ihrer Distribution einspielen.

Für Container gilt: Sie teilen sich den Kernel des Hosts. Ein neues Image hilft hier nichts, der Host muss aktualisiert und neu gestartet werden, außer ihr nutzt Live-Patching.

Die größere Geschichte

Es ist nicht das erste Mal, dass Claude im Kernel fündig wird. Schon im April berichteten wir über Claude Mythos und tausende Zero-Days, im Juli darüber, dass KI Lücken schneller findet, als gepatcht wird. Neu an diesem Fall ist, dass ein Modell nicht nur einen Fehler meldet, sondern selbst eine funktionierende Kette bis zur root-Shell baut. Für Betriebsteams spricht das dafür, Kernel-Updates nicht mehr bis zum nächsten Wartungsfenster im Quartal zu sammeln.

Quellen8