Zurück

2026/11/04

CVE-2026-98432: TCP-Use-After-Free in Linux, KI-gestützter Remote-Root über MPTCP und Schutzmaßnahmen für Enterprise-Linux

Eine Race Condition im IPv4-TCP von Linux, ein demonstrierter MPTCP-Remote-Root sowie Fixes und Abhilfen für RHEL, Ubuntu, Oracle Linux und Debian.

Informationen geprüft: 3. November 2026 | Technische Analyse von LOGIQ

Im Oktober 2026 wurde mit CVE-2026-98432 eine Use-after-free-Schwachstelle (UAF) in der Verarbeitung von IPv4-TCP-Verbindungen im Linux-Kernel veröffentlicht. Das CVE-Team des Linux-Kernels gab seine Meldung am 15. Oktober heraus. Am 27. Oktober berichtete Anthropic, dass ein unveröffentlichtes internes Forschungsmodell eine nicht authentifizierte Remote-Befehlsausführung mit Root-Rechten gegen einen Linux-Server mit einem MPTCP-Listener (Multipath TCP) demonstriert hatte. Entscheidend ist, die konkreten Bedingungen dieses Exploits nicht mit den breiteren Schwachstellen- und Denial-of-Service-Risiken zu verwechseln, die gewöhnliche IPv4-TCP-Dienste betreffen.

Das Wichtigste in Kürze

  • Der Fehler ist eine Race Condition in der gewöhnlichen Verarbeitung von IPv4-TCP-Verbindungsanfragen und besteht seit Linux 4.4. Für den Bug selbst ist MPTCP nicht erforderlich.
  • Die Remote-Root-Demonstration von Anthropic zielte auf einen Server mit MPTCP-Listener; andere TCP-Dienste sind weiterhin von Abstürzen, Denial of Service und Speicherbeschädigung bedroht.
  • Red Hat stuft das Problem als kritisch ein (CVSS v3.1 9.8) und hat am 1. November korrigierte Kernel für RHEL 8, 9 und 10 veröffentlicht. Die Fixes für Ubuntu waren am 3. November noch in Arbeit.
  • Installieren Sie einen vom Hersteller freigegebenen korrigierten Kernel, starten Sie neu und prüfen Sie den laufenden Kernel. Abhilfemaßnahmen verringern die Angriffsfläche, ersetzen aber nicht den Patch.

Wo die Race Condition auftritt

Das Problem betrifft den TCP-Drei-Wege-Handshake unter IPv4. IP-Optionen, die ein Request-Socket hält (ireq->ireq_opt), können während tcp_v4_syn_recv_sock() ohne Kopie in das inet_opt des Child-Sockets übertragen werden. Verarbeitet eine andere CPU gerade ein erneut gesendetes SYN und baut ein SYN/ACK auf, während der Child-Socket zerstört wird, kann der Speicher der Optionen freigegeben werden, obwohl er noch verwendet wird. Ein späterer Zugriff durch Funktionen wie ip_options_build() kann dann ein UAF auslösen.

Eine verwandte Race Condition besteht bei der Migration von Request-Sockets über net.ipv4.tcp_migrate_req=1 oder BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, bei der sich der ursprüngliche und der geklonte Request-Socket Optionsdaten teilen können. Das verwundbare Verhalten reicht bis Linux 4.4 zurück, die tatsächliche Gefährdung muss jedoch für jeden Hersteller-Kernel einschließlich Backports einzeln bewertet werden.

Der Upstream-Fix-Commit e3f33b0a1d89 („ipv4: free inet_opt and ireq_opt after an RCU grace period“) ersetzt die sofortige Freigabe in inet_sock_destruct() und tcp_v4_reqsk_destructor() durch eine per RCU verzögerte Freigabe über kfree_rcu(). Die CVE-Meldung von Linux nennt Fixes in den Kernel-Versionen 6.12.113, 6.18.56, 7.2.10 und 7.3-rc7. Der ursprüngliche IPv6-Pfad ist nicht dieselbe Schwachstelle, allerdings wird ein IPv6-Migrationspfad mit CALIPSO durch einen separaten Patch behoben.

Demonstrierten Remote-Root nicht mit der allgemeinen Gefährdung verwechseln

Der Proof of Concept von Anthropic zielte auf einen Server mit MPTCP-Listener und kombinierte ein Informationsleck über Kernel-Adressen mit einer Übernahme des Kontrollflusses. Laut Bericht dauerte es im Experiment etwa 48 Minuten, das Informationsleck zu erhalten, und weitere fünf Minuten bis zur Befehlsausführung. Da ein verlorenes Rennen nur den Handshake scheitern lässt, statt das System abstürzen zu lassen, kann ein Angreifer es immer wieder versuchen. Das zugrunde liegende UAF liegt jedoch in der gewöhnlichen Verarbeitung von IPv4-TCP-Verbindungsanfragen und nicht ausschließlich im MPTCP-Code.

Dieselbe Remote-Root-Exploit-Technik wurde nicht für jeden herkömmlichen TCP-Dienst ohne MPTCP demonstriert. Ebenso falsch ist jedoch die Annahme, ein System sei vollständig sicher, wenn MPTCP deaktiviert ist. Red Hat stellt klar, dass MPTCP keine notwendige Voraussetzung ist, dass Systeme mit deaktiviertem MPTCP (der Standard) weiterhin betroffen sind, und warnt vor nicht authentifizierten Remote-Abstürzen, Denial of Service und Speicherbeschädigung in normalen IPv4-TCP-Diensten.

Bewertungen der wichtigsten Hersteller: Schweregrad und Fix-Status

Stand der Prüfung: 3. November 2026. Die Seiten der Hersteller ändern sich; prüfen Sie vor jedem Schritt immer den aktuellen Eintrag.

HerstellerSchweregradFix-Status
Red HatKritisch, CVSS v3.1 9.8Korrigierte Kernel am 1. November veröffentlicht: RHEL 8 (RHSA-2026:93414; kernel-rt für NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). Der kernel-rt von RHEL 9 und OpenShift (RHCOS) sind weiterhin als betroffen gelistet. RHEL 6 und 7 sind nicht betroffen.
UbuntuPriorität High; CVSS 9.8linux für 26.10, 26.04, 24.04 und 22.04: verwundbar, in Arbeit. 20.04, 18.04 und 16.04: verwundbar. Noch kein korrigiertes Paket veröffentlicht.
Oracle LinuxImportant; vorläufiger CVSS 8.1UEK-Errata vom 16. Oktober (ELSA-2026-500397, -500398, -500399) für OL7 bis OL10. RHCK-Errata vom 2. November für OL8 (ELSA-2026-93414) und OL10 (ELSA-2026-93413); für OL9 ist noch kein RHCK-Erratum gelistet.
Debian(Security Tracker)Behoben in bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) und trixie 6.12.113-1 (DSA-6568-1); forky und sid behoben.

Red Hat (Bewertung am 30. Oktober überarbeitet; Bulletin zuletzt am 2. November aktualisiert). Die offizielle CVE-Seite stuft das Problem als kritisch ein, CVSS v3.1 9.8, weil ein nicht authentifizierter entfernter Angreifer über gewöhnlichen IPv4-TCP-Verkehr den Kernel-Speicher beschädigen oder ein System zum Absturz bringen kann. RHEL 8, 9, 10 und OpenShift sind als betroffen gelistet; der Kernel von RHEL 7 gilt als nicht betroffen, da der betreffende Code dort fehlt. Seit dem 1. November führen die CVE-Daten von Red Hat korrigierte Kernel auf: kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) und kernel-6.12.0-211.72.1.el10_2 (RHEL 10). Das Sicherheitsbulletin RHSB-2026-016 war noch als laufend gekennzeichnet und ist die maßgebliche Stelle für das Verfahren zur Abhilfe. Stellen Sie ältere Werte aus Sekundärquellen wie 5.9 oder 8.1 nicht als aktuelle Bewertung von Red Hat dar.

Ubuntu (offizielle Tabelle zuletzt am 30. Oktober aktualisiert). Der CVE hat einen CVSS von 9.8, während die eigene Priorität von Ubuntu High ist. Die Standard-linux-Pakete für Ubuntu 26.10, 26.04, 24.04 und 22.04 sind als „Vulnerable, work in progress“ markiert, wobei die geplanten Fix-Versionen auf der Seite angegeben sind; 20.04 ist unter anderem als Vulnerable markiert. AWS-, Azure-, HWE-, RT- und andere Kernel-Varianten müssen einzeln bewertet werden. „Work in progress“ bedeutet nicht, dass ein Fix veröffentlicht wurde.

Oracle Linux. Die eigene Bewertung von Oracle lautet Important, mit einem vorläufigen CVSS-Wert von 8.1. Die UEK-Errata für OL7, OL8, OL9 und OL10 datieren vom 16. Oktober, die RHCK-Errata für OL8 und OL10 folgten am 2. November. Fixes in UEK dürfen nicht auf RHCK oder jedes Minor-Release verallgemeinert werden; bewerten Sie den installierten Kernel und die genauen Errata.

Debian. Der offizielle Security Tracker führt unter anderem bookworm-security 6.1.190-1 und trixie-security 6.12.113-1 als behoben. Prüfen Sie sowohl die installierten Paketversionen als auch den laufenden Kernel nach dem Neustart.

CVSS-Ergebnisse können zwischen der CNA und den Herstellern wegen distributionsspezifischer Konfigurationen und Fixes voneinander abweichen, und Bewertungen können sich ändern. Halten Sie immer das Prüfdatum fest und verlinken Sie jede offizielle Quelle.

Schutzmaßnahmen: Eine Abhilfe ersetzt keinen Patch

Oberste Priorität hat die Installation eines vom Hersteller freigegebenen korrigierten Kernels und die Prüfung der laufenden Version nach dem Neustart. Wo noch kein Fix verfügbar ist, sollten Sie erwägen, unnötige öffentliche TCP-Dienste zu schließen, die zugelassenen Quellnetze einzuschränken und exponierte Hosts vorrangig zu überwachen.

Das Bulletin von Red Hat beschreibt eine nftables-Abhilfe, die eingehende IPv4-TCP-Pakete mit IP-Optionen im IPv4-Header verwirft:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Sie bietet keinen vollständigen Schutz, kann Workloads stören, die auf IP-Optionen angewiesen sind, und muss vor dem Einsatz auf ihre Auswirkungen auf den Geschäftsverkehr getestet werden. Gewöhnliche TCP-Optionen im TCP-Header bleiben erlaubt; es geht nicht darum, das Feld TCP Options zu blockieren. Unter OpenShift filtern Regeln auf Node-Ebene den Pod-zu-Pod-Verkehr innerhalb des Cluster-Netzwerks nicht, daher ist dort die Filterung an der Netzwerkgrenze wichtig. Entfernen Sie die Tabelle, sobald der korrigierte Kernel läuft.

Tipp: Vergleichen Sie nach dem Patchen die Ausgabe von uname -r mit der korrigierten Version im Erratum Ihres Herstellers und bewahren Sie diese Ausgabe zusammen mit dem Change-Record auf. Ein installiertes, aber noch nicht gebootetes Paket schließt die Schwachstelle nicht.

Unter Linux aktiviert das Go-Paket net ab Go 1.24 MPTCP standardmäßig für Listener. Das Go-Team dokumentiert GODEBUG=multipathtcp=0 als Möglichkeit, dies zu deaktivieren (auch als godebug-Zeile in go.mod verfügbar). Ein Vorschlag, den Standard zu ändern, wird noch diskutiert, und die Go-Maintainer verweisen auf einen gepatchten Kernel als eigentliche Lösung. Die Einstellung kann die Angriffsfläche für den von Anthropic demonstrierten, von MPTCP abhängigen Angriffspfad verringern, behebt aber nicht das UAF im Kernel selbst. Prüfen Sie die Nutzung von MPTCP Dienst für Dienst.

Die Sicht von LOGIQ

Bei der Wartung von Enterprise-Linux lässt sich die Sicherheit nicht allein an einem öffentlichen CVSS-Wert oder an uname -r ablesen. Bewerten Sie OS-Release, Kernel-Familie (zum Beispiel UEK oder RHCK), Paket-Release, aktuell gebooteten Kernel, Netzwerkexposition, MPTCP-Einstellungen, Hersteller-Errata und Nachweise für den Neustart gemeinsam. Verfolgen Sie die gesamte Kette von der Auswirkungsanalyse und Validierung bis zur Bereitstellung und Betriebsüberwachung.

Wo Fixes der Hersteller noch ausstehen, dokumentieren Sie das Restrisiko der vorübergehenden Abhilfen und bewerten Sie diese Abhilfen neu, sobald Patches verfügbar sind. Da KI die praktische Ausnutzbarkeit von Schwachstellen erhöht, muss die Wartung im Unternehmen den gesamten Lebenszyklus abdecken: Erkennung, Prüfung, Behebung und Nachweis eines einwandfreien Betriebs.

Primärquellen und Referenzen