Linux-TCP-Lücke: Welche Server jetzt Priorität haben

Für die Linux-Kernel-Schwachstelle CVE-2026-98432 beschreibt Anthropic einen funktionierenden Remote-Root-Exploit in einer Testumgebung. Die entscheidende Einschränkung steht in der Versuchsbeschreibung: Die demonstrierte Übernahme betrifft Linux-Server mit Multipath-TCP-Listenern. Das macht die Lücke für solche Systeme besonders dringlich. Es belegt aber keine beliebige Übernahme jedes ungepatchten Linux-Servers.

Die veröffentlichten CVE-Angaben bewerten die Schwachstelle mit 9,8 auf der CVSS-Skala. Betroffen sein soll die Einrichtung neuer IPv4-TCP-Verbindungen; der Fehler wird auf Code seit Linux 4.4 zurückgeführt. Für Betreiber zählt jetzt vor allem, welche Maschinen einen verwundbaren Kernel ausführen, welche Netzwerkdienste erreichbar sind und ob sie die Voraussetzungen des demonstrierten Angriffs erfüllen. Der Distributionsname allein beantwortet diese Fragen nicht.

Ein Fehler zwischen Verbindungsaufbau und Speicherfreigabe

Die technische Ursache wird als Race Condition beschrieben: Abläufe bei der Einrichtung einer TCP-Verbindung können sich zeitlich so überschneiden, dass anschließend auf bereits freigegebenen Speicher zugegriffen wird. Dieser Fehlertyp heißt Use-After-Free. Im Kernel ist er besonders kritisch, weil dort zentrale Betriebssystemfunktionen mit weitreichenden Rechten ausgeführt werden.

Ein solcher Speicherfehler führt allerdings nicht unter allen Bedingungen zum selben Ergebnis. Ein Absturz und die kontrollierte Ausführung fremden Codes sind unterschiedliche Folgen. Für Letztere muss ein Angreifer den fehlerhaften Zustand ausreichend zuverlässig herbeiführen und den weiteren Ablauf beeinflussen können. Aus der Fehlerklasse allein ergibt sich deshalb noch keine universell funktionierende Angriffsmethode.

Anthropic gab am 27. Oktober 2026 bekannt, dass sein Modell Claude einen Exploit entwickelt habe, der diese Hürde in einer Testumgebung überwindet. Nach der veröffentlichten Beschreibung konnte der Proof of Concept innerhalb von 48 Minuten einen Kernel-Pointer offenlegen und in weiteren fünf Minuten einen Befehl als Root ausführen. Dabei wurde auch KASLR umgangen, die zufällige Anordnung von Kernel-Adressen im Speicher.

Diese Zeitangaben beschreiben den vorgeführten Versuch. Sie sind weder eine garantierte Angriffsdauer für andere Systeme noch eine Frist, innerhalb derer jeder betroffene Server übernommen werden könnte. Relevant ist der Nachweis, dass der Fehler unter den beschriebenen Bedingungen über einen bloßen Absturz hinaus ausgenutzt werden kann.

Die MPTCP-Voraussetzung entscheidet über die Priorität

Multipath TCP, kurz MPTCP, ermöglicht es, eine TCP-Verbindung über mehrere Netzwerkpfade zu führen. Ein MPTCP-Listener ist ein lauschender Endpunkt für entsprechende Verbindungen. Genau solche Listener nennt Anthropic als Voraussetzung seiner demonstrierten Remote-Code-Ausführung.

Für die Bestandsaufnahme müssen Betreiber daher mehrere Ebenen auseinanderhalten: Unterstützt der Kernel MPTCP grundsätzlich? Wird die Funktion tatsächlich von einem Dienst verwendet? Und ist dessen Listener aus einem Netz erreichbar, aus dem ein Angriff erfolgen könnte? Eine vorhandene Kernel-Funktion ist noch kein Nachweis für einen exponierten Dienst.

Umgekehrt darf aus einem fehlenden MPTCP-Listener keine pauschale Entwarnung für CVE-2026-98432 werden. Die Voraussetzung ist für den beschriebenen Exploit benannt. Daraus folgt nicht, dass sämtliche anderen Ausnutzungswege ausgeschlossen sind oder andere Konfigurationen von der zugrunde liegenden Schwachstelle unberührt bleiben.

Die höchste operative Priorität haben damit verwundbare Systeme, auf denen passende Listener tatsächlich erreichbar sind. Öffentlich erreichbare Dienste verdienen besondere Aufmerksamkeit. Interne Erreichbarkeit bleibt ebenfalls relevant: Eine Netzgrenze reduziert die Zahl möglicher Angreifer, beseitigt den Kernel-Fehler aber nicht.

Patchstand prüfen, nicht nur Versionsnummern vergleichen

Beim Stand vom 29. Oktober 2026 hatten Debian, Oracle Linux, SUSE und Amazon Linux laut damaligen Anbieterständen und Berichten bereits korrigierte Kernel bereitgestellt. Für Ubuntu und Red Hat Enterprise Linux waren zu diesem Zeitpunkt demnach noch keine korrigierten Kernel veröffentlicht. Diese Momentaufnahme ist keine Aussage darüber, welche Pakete inzwischen für jede einzelne Produktversion verfügbar sind. Maßgeblich sind die aktuellen Sicherheitshinweise und Paketstände des jeweiligen Anbieters.

Auch die Angabe „seit Linux 4.4“ ersetzt keine Prüfung des Distributionskernels. Anbieter übernehmen Sicherheitskorrekturen häufig in bestehende Kernel-Reihen. Eine ältere Versionsbasis kann deshalb einen Fix enthalten; eine vertraute Versionsnummer allein belegt weder Verwundbarkeit noch Schutz.

Zum Patchprozess gehört außerdem die Kontrolle des tatsächlich laufenden Kernels. Ein installiertes Update schützt nicht automatisch den noch laufenden alten Kernel. Betreiber müssen sicherstellen, dass der korrigierte Stand aktiv ist, üblicherweise durch einen geplanten Neustart. Wo eine geeignete Live-Patching-Abdeckung angeboten wird, muss deren Schutz für genau diese Schwachstelle ausdrücklich bestätigt sein.

Bei virtuellen Maschinen und Container-Umgebungen sollte die Zuständigkeit früh geklärt werden. Container teilen sich grundsätzlich den Kernel ihres Hosts. Ein aktualisiertes Container-Image ersetzt deshalb kein erforderliches Kernel-Update auf dem zugrunde liegenden System.

Bis zum Fix die erreichbare Angriffsfläche verkleinern

Fehlt ein bestätigter Fix, sollten Administratoren prüfen, ob benötigte MPTCP-Listener auf vertrauenswürdige Netze beschränkt werden können. Nicht benötigte exponierte Dienste lassen sich gegebenenfalls vorübergehend außer Betrieb nehmen. Solche Eingriffe brauchen eine Prüfung ihrer Betriebsfolgen: Wer eine tatsächlich genutzte Netzwerkfunktion abschaltet, kann damit auch legitime Verbindungen unterbrechen.

Diese Maßnahmen reduzieren die Erreichbarkeit des bekannten Angriffspfads. Sie sind kein belegter vollständiger Ersatz für den Kernel-Fix. Insbesondere wäre es zu weitgehend, allein aus einer geänderten MPTCP-Konfiguration auf die Beseitigung der gesamten TCP-Schwachstelle zu schließen.

Die belastbare Reihenfolge lautet daher: laufende Kernel und Anbieterhinweise abgleichen, erreichbare MPTCP-Listener ermitteln, besonders exponierte Systeme priorisieren und korrigierte Kernel kontrolliert aktivieren. Der CVSS-Wert begründet die Dringlichkeit. Welche Maschine zuerst behandelt werden muss, ergibt sich aus ihrer konkreten Erreichbarkeit und Konfiguration.