CVE-2026-98432: Kritische Schwachstelle im Linux Kernel TCP ermöglicht Remote-Code-Ausführung

Eine kritische Schwachstelle im IPv4 TCP-Netzwerkstapel des Linux-Kernels könnte einem nicht authentifizierten Remote-Angreifer ermöglichen, eine Speicherbeschädigung zu verursachen, anfällige Systeme zum Absturz zu bringen und potenziell beliebigen Code mit Root-Rechten auszuführen. Die Schwachstelle, die als CVE-2026-98432 verfolgt wird, hat einen CVSS 3.1-Score von 9.8 und existiert im Linux-Kernel seit Version 4.4.

Die Schwachstelle resultiert aus einer Race-Condition, die dazu führen kann, dass der Kernel auf IP-Optionsdaten zugreift, nachdem der zugrunde liegende Speicher bereits freigegeben wurde. Ein Angreifer, der in der Lage ist, einen exponierten IPv4 TCP-Dienst zu erreichen, kann versuchen, die Bedingung durch speziell abgestimmte Verbindungsanfragen, die IPv4-Optionen enthalten, auszulösen. Es sind keine Authentifizierung, lokalen Privilegien oder Nutzerinteraktionen erforderlich.

Das Interesse an Sicherheit stieg erheblich, nachdem Anthropic bekannt gab, dass ein internes Claude-Forschungsmodell einen funktionierenden Exploit entwickelt hatte, der Remote-Root-Befehlsausführung gegen einen Linux-Server mit einem Multipath TCP (MPTCP)-Listener erreichen konnte. Der Exploit leakt zuerst einen Kernel-Pointer, um KASLR zu umgehen, und verwendet dann die gleiche Use-After-Free-Bedingung, um Speicher zu korrumpieren und den Kernel-Kontrollfluss umzuleiten. Anthropic hat den Exploit-Code nicht veröffentlicht.

Wichtig ist, dass die zugrunde liegende Schwachstelle nicht auf MPTCP beschränkt ist. Red Hat bestätigt, dass Systeme mit normalem IPv4 TCP-Netzwerk selbst dann verwundbar bleiben, wenn MPTCP deaktiviert ist, einschließlich der Standardkonfigurationen von Red Hat Enterprise Linux.

Kontakt Vertrieb

Bis zum 4. November 2026 hat kein Linux-Anbieter, CERT oder andere geprüfte Quelle eine bestätigte Ausnutzung der Schwachstelle in realen Angriffen gemeldet. Öffentliches Forschungscode, der Teile der Schwachstelle demonstriert, existiert, aber ein öffentlich veröffentlichter Exploit, der die volle Remote-Root-Fähigkeit demonstriert, die von Anthropic gezeigt wurde, ist nicht dokumentiert.

Sicherheitsteams können die AI-Native Detection Intelligence Platform von SOC Prime nutzen, um ihre Verteidigung gegen die Ausnutzung aufkommender Schwachstellen zu stärken, Bedrohungsinformationen zu operationalisieren und die Bedrohungserkennung über SIEM-, EDR-, XDR- und Data-Lake-Umgebungen zu beschleunigen.

CVE-2026-98432 durch Überwachung ungewöhnlichen IPv4 TCP-Verkehrs mit IP-Optionen, wiederholte Verbindungsversuche zur Auslösung von Race-Conditions, Kernel-Abstürze oder Speicherbeschädigungsereignisse sowie verdächtige Aktivitäten, die auf eine erfolgreiche Post-Exploitation hinweisen könnten, erkennen.

Erkennungsinhalte sind möglicherweise nicht für jede CVE verfügbar. Überprüfen Sie die SOC Prime Platform auf aktuelle Abdeckung. Wenn relevante Erkennungen noch nicht verfügbar sind, überprüfen Sie erneut, da neue Bedrohungsinformationen und Erkennungsinhalte kontinuierlich hinzugefügt werden.

Analyse CVE-2026-98432

CVE-2026-98432 betrifft den Code zur Bearbeitung von IPv4 TCP-Verbindungen in Linux-Kernen, die die verwundbare Implementierung enthalten, die mit Linux 4.4 eingeführt wurde. Das Linux-Kernel-CVE-Team stuft das Problem als kritisch mit einem CVSS 3.1-Score von 9.8 und dem Vektor AV/AC/PR/UI/S/C/I/A ein.

Die Schwachstelle ist eine Use-After-Free-Bedingung, die durch ein Rennen während der gleichzeitigen Verarbeitung von TCP-Verbindungen verursacht wird. Wenn eine IPv4 TCP-Verbindung hergestellt wird, überträgt tcp_v4_syn_recv_sock() IP-Optionen, die mit der ausstehenden Anfrage verbunden sind, auf den neu erstellten Socket, ohne eine separate Kopie zu erstellen.

Ein anderer CPU kann gleichzeitig ein erneut übermitteltes SYN bearbeiten, das mit demselben Anfrage-Socket verbunden ist. Während dieses Prozesses lesen die für die Generierung des SYN-ACK verantwortlichen Funktionen weiterhin die IP-Optionen, während sie durch einen RCU-Read-Side-Kritischen Abschnitt geschützt sind.

Das Kind-Socket kann jedoch zerstört werden, während diese Operation noch im Gange ist. Der Kernel gibt dann die zugehörige inet_opt-Struktur mit kfree() frei, was dazu führen kann, dass eine andere CPU potenziell auf Speicher zugreift, der bereits freigegeben wurde. Der resultierende veraltete Verweis erzeugt eine Use-After-Free-Bedingung in ip_options_build().

Ein ähnliches Rennen besteht während der Migration von Anforderungssockets, einschließlich Konfigurationen, die net.ipv4.tcp_migrate_req=1 oder BPF-basierte SK_REUSEPORT_SELECT_OR_MIGRATE verwenden. Der Upstream-Fix ersetzt die unsichere Speicherfreigabe durch ein RCU-Bewusstes Freigeben, das sicherstellt, dass die Leser den Zugriff auf das Objekt abgeschlossen haben, bevor dessen Speicher wieder beansprucht werden kann.

Das erste Problem betrifft speziell IPv4. Der Kernel-Beratungshinweis besagt, dass IPv6 nicht anfällig für dieses spezielle Rennen ist, weil tcp_v6_syn_recv_sock() die relevanten Optionen dupliziert, anstatt sie auf die gleiche Weise zu übertragen.

Remote-Ausnutzung erfordert speziell konstruierte Netzwerkverkehrsdaten und präzise Manipulation der Rennbedingung. Red Hat stellt fest, dass die wahrscheinlichen Ergebnisse einen Kernelabsturz, Speicherbeschädigung und potenziell eine Remote-Code-Ausführung umfassen können. Das Fehlen von Authentifizierung und Nutzerinteraktion erhöht das Risiko für Systeme, die TCP-Dienste in nicht vertrauten Netzwerken aussetzen, erheblich.

Anthropic zeigte, dass die Schwachstelle in einen vollständigen Remote-Root-Exploit umgewandelt werden kann. Ihr Forschungsmodell zielte auf einen Linux-Server, der Multipath TCP-Verbindungen akzeptiert, und verwendete zwei Stufen, um Befehlsausführung zu erreichen.

In der ersten Stufe löst der Exploit wiederholt das Rennen aus und manipuliert einen Längenwert, sodass der Kernel zusätzlichen angrenzenden Speicher in einer Netzwerkantwort zurückgibt. Schließlich enthält eine dieser Antworten einen Kernel-Pointer. Diese Offenlegung enthüllt Informationen über das Kernel-Speicherlayout und ermöglicht es dem Exploit, die Kernel-Adressraum Layout-Randomisierung (KASLR) zu besiegen.

In der zweiten Stufe nutzt der Exploit die gleiche Schwachstelle aus, um einen Pufferüberlauf zu verursachen und einen Callback-Zeiger zu überschreiben. Der Zeiger wird auf eine Nutzlast umgeleitet, die zuvor mithilfe legitimer Protokollfunktionalität im Kernel-Speicher platziert wurde. Wenn der Kernel den modifizierten Callback aufruft, werden bestehende Kernel-Funktionen miteinander verkettet, bis ein vom Angreifer ausgewählter Shell-Befehl als Root ausgeführt wird.

Ein besonders wichtiges Merkmal des Exploits ist, dass das Verlieren des Rennens nicht unbedingt den Server zum Absturz bringt. Stattdessen kann der Verbindungsversuch einfach fehlschlagen, was dem Angreifer erlaubt, es wiederholt zu versuchen. In Anthropic’s Testumgebung dauerte es etwa 48 Minuten, um einen nützlichen Kernel-Pointer zu erhalten, gefolgt von weiteren fünf Minuten, um die Root-Befehlsausführung zu erreichen.

Diese Demonstration sollte nicht so interpretiert werden, dass MPTCP für die Ausnutzung erforderlich ist. Anthropic demonstrierte einen erfolgreichen Exploit-Pfad, der einen MPTCP-Listener einbezog, aber der anfällige Code befindet sich in der normalen IPv4 TCP-Verarbeitung. Red Hat warnt ausdrücklich, dass das Deaktivieren von MPTCP die Schwachstelle nicht vollständig behebt und dass die Standard-RHEL-Installationen weiterhin betroffen sind, obwohl MPTCP standardmäßig deaktiviert ist.

Die CVE-2026-98432 PoC-Situation sollte auch von der Existenz eines vollständigen waffenfähigen Exploits unterschieden werden. Anthropic entwickelte intern einen funktionierenden Remote-Root-Proof-of-Concept, hat ihn jedoch nicht veröffentlicht. Öffentlicher Code, der von Sicherheitsforschern gemeldet wurde, kann Aspekte des zugrunde liegenden Rennens und der Speicherveröffentlichung demonstrieren oder erkennen, aber die überprüften Quellen dokumentieren keinen öffentlich veröffentlichten Code, der die vollständige Remote-Code-Ausführungskette von Anthropic reproduziert.

Die Schwachstelle wurde vom Anthropic-Forscher Xinyang Ge gemeldet. Der Upstream-Linux-Fix wurde am 5. Oktober 2026 angewendet, während der Linux-Kernel-CVE-Eintrag am 15. Oktober veröffentlicht wurde. Anthropic beschrieb seine vollständigen Exploitationsforschung öffentlich am 27. Oktober.

Das Linux-Kernel-Projekt identifiziert die folgenden Upstream-Fixed-Versionen:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

Das Kernel-Team empfiehlt, auf den neuesten stabilen Kernel zu aktualisieren, anstatt einzelne Commits auszuwählen.

Verteilungsspezifische Exposition und Behebung unterscheiden sich, da Linux-Anbieter ihre eigenen Kerne pflegen und Sicherheitskorrekturen backporten. Red Hat bewertet das Problem derzeit als kritisch mit 9.8 und hat Korrekturen für mehrere RHEL 8, 9 und 10 Streams veröffentlicht. OpenShift und gestapelte Produkte, die auf betroffenen RHEL-Kernen basieren, erfordern ebenfalls Aufmerksamkeit.

Ubuntu bewertet die Schwachstelle ebenfalls als kritisch mit 9.8. Ubuntu 26.10 hat einen korrigierten generischen Kernel erhalten, während Korrekturen für Ubuntu 22.04 LTS, 24.04 LTS und 26.04 LTS im -Proposed-Testing-Pocket ab Anfang November verfügbar waren, mit weiteren unterstützten Veröffentlichungen, die auf Korrekturen warten. Administratoren sollten Canonical’s CVE-Seite verwenden, anstatt sich ausschließlich auf die Upstream-Kernel-Versionsnummern zu verlassen.

Für die CVE-2026-98432-Erkennung sollten Sicherheitsteams Netzwerk- und Host-Telemetrie kombinieren. Potenzielle Netzwerksignale auf Jagd-Ebene umfassen ungewöhnliche eingehende IPv4 TCP-Pakete mit IP-Optionen, insbesondere wiederholte Verbindungsversuche mit Record Route oder Timestamp-Optionen und abnormale Muster der SYN-Übertragung. Das Vorhandensein eines solchen Verkehrs allein bestätigt keine Ausnutzung, bietet jedoch einen nützlichen Jagdpivot, wenn es mit anfälligen Systemen korreliert wird.

Host-Level-Überwachung sollte Linux-Kernel-Abstürze, Kernel-Warnungen, Speicherbeschädigungsindikatoren, unerwartete Dienstneustarts und anomale Aktivitäten unmittelbar nach verdächtigem Netzwerkverkehr umfassen. Da eine erfolgreiche Ausnutzung theoretisch die Root-Code-Ausführung ermöglichen könnte, sollten Verteidiger auch auf unerwartete privilegierte Prozesse, neu erstellte Dateien, Konfigurationsänderungen, Persistenzmechanismen und unerklärte ausgehende Verbindungen achten.

Derzeit gibt es keine angreiferspezifischen CVE-2026-98432 IOCs, wie bestätigte bösartige IP-Adressen, Domänen oder Malware-Hashes, da die geprüften Quellen keine realen Ausnutzungen melden. Verteidiger sollten daher Verhaltensbasierte Erkennung und Exposure Assessments priorisieren, anstatt sich auf statische Indikatoren zu verlassen.

CVE-2026-98432 Minderung

Die definitive Behebung besteht darin, einen vom Anbieter bereitgestellten Kernel mit dem Sicherheitsfix zu installieren. Das Linux-Kernel-CVE-Team empfiehlt, auf den neuesten unterstützten stabilen Kernel zu wechseln, während Linux-Verteilungsnutzer speziell von ihrem Anbieter bereitgestellte Pakete installieren sollten, da Fixes häufig ohne Änderung der Upstream-Kernel-Version zurückportiert werden.

Administratoren sollten Linux-Server im Internet-Zugriff und andere Systeme, die eingehende IPv4 TCP-Verbindungen akzeptieren, priorisieren. Die Angriffsfläche ist breit, da die Schwachstelle im Kernel-Netzwerkstapel und nicht in einer einzelnen Anwendung oder einem Serverprodukt existiert.

Organisationen sollten die folgenden Schritte unternehmen:

1. Inventarisieren Sie Linux-Server und identifizieren Sie den laufenden Kernel mit Tools wie uname -r.
2. Überprüfen Sie den Sicherheitsberatungshinweis der relevanten Linux-Distribution, anstatt die Exposition ausschließlich aus der Upstream-Versionsnummer zu bestimmen.
3. Installieren Sie den vom Anbieter bereitgestellten festen Kernel, sobald er verfügbar ist.
4. Starten Sie die betroffenen Systeme nach der Installation des aktualisierten Kernels neu, um sicherzustellen, dass der gepatchte Kernel läuft.
5. Priorisieren Sie Server im Internet-Zugriff und Infrastruktur, die eingehenden IPv4 TCP-Verkehr akzeptieren.
6. Überprüfen Sie extern exponierte TCP-Dienste und beschränken Sie unnötige Netzwerkzugänglichkeit.
7. Überwachen Sie weiterhin Anbieterhinweise, da die Verfügbarkeit von Fixes zwischen den Linux-Distributionen, Kernel-Varianten, Cloud-Kernen und Support-Kanälen variiert.

Red Hat und Ubuntu haben auch einen Zwischenansatz mit Paketfilterung dokumentiert, der eingehende IPv4 TCP-Pakete mit IP-Optionen abweist. Die empfohlene nftables-Bedingung prüft auf eine IPv4-Headerlänge größer als fünf und weist übereinstimmende TCP-Pakete ab, bevor sie den anfälligen Socket-Verarbeitungspfad erreichen.

Diese Maßnahme kann das Risiko verringern, da der bekannte Exploitationspfad IPv4-Optionen erfordert. Beide Anbieter warnen jedoch, dass Paketfilterung kein vollständiger Ersatz für die Installation des korrigierten Kernels ist. Sie kann auch mit Workloads interferieren, die legitimerweise von IPv4-Optionen abhängen und sollten daher vor der Produktionseinstellung getestet werden.

Das alleinige Deaktivieren von MPTCP sollte nicht als ausreichender Schutz betrachtet werden. Obwohl Anthropic’s funktionierender Exploit einen MPTCP-Listener anvisierte, liegt die zugrunde liegende Schwachstelle in der normalen IPv4 TCP-Verarbeitung. Red Hat stellt fest, dass RHEL in seiner Standardkonfiguration weiterhin anfällig bleibt, obwohl MPTCP deaktiviert ist.

Für Umgebungen mit Go-Anwendungen kann die Deaktivierung des automatischen MPTCP-Verhaltens die Exposition gegenüber dem von Anthropic gezeigten spezifischen Exploit verringern, aber dies bleibt eine unvollständige Risikominderung. Systeme ohne MPTCP-Listener sollten nicht automatisch als sicher angesehen werden, da andere Exploitationstechniken auf das gleiche zugrunde liegende Rennen abzielen können.

Da keine echte Kompromittierungskampagne bestätigt wurde, sollte sich die Vorfallsreaktionsleitlinie derzeit auf die Identifizierung potenziell anfälliger Systeme und verdächtiges Exploitationsverhalten konzentrieren, anstatt nach einer bekannten Angreiferinfrastruktur zu suchen. Organisationen, die ungewöhnlichen TCP-Verkehr gefolgt von Kernel-Instabilität oder unerwarteter priviligierter Ausführung beobachten, sollten die Aktivität als potenziell bösartig behandeln und Netzwerk- und Host-Telemetriedaten für die Untersuchung bewahren.