CVE-2026-98432, Linux-TCP-Lücke: Server schützen

Was ist CVE-2026-98432?

CVE-2026-98432 ist eine Sicherheitslücke im Linux-Kernel, dem Kern von Linux-Betriebssystemen. Ihr offizieller Titel lautet ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. Das CVE-Team des Linux-Kernels hat sie vergeben und den Eintrag am 15. Oktober 2026 veröffentlicht ^[1]. Der Eintrag nennt einen CVSS-3.1-Basiswert von 9.8, was als Critical eingestuft wird ^[1].

Bei dem Fehler handelt es sich um einen Use-after-free: Ein Programm verwendet einen Speicherbereich weiter, nachdem dieser freigegeben wurde, sodass dort bereits andere Daten liegen können. Hier steckt er im Code, der eingehende IPv4-TCP-Verbindungsanfragen verarbeitet ^[10]. Der CVSS-Vektor lautet AV:N/AC:L/PR:N/UI:N. Das bedeutet: Der Angriff funktioniert über das Netzwerk, ist wenig komplex und erfordert weder Berechtigungen noch eine Interaktion des Nutzers ^[1].

Der Fehler existiert seit Linux 4.4, wo er mit dem Commit 079096f103fa hinzukam ^[2]. Eine von Eric Dumazet geschriebene Korrektur wurde am 5. Oktober 2026 eingespielt und ist inzwischen im Mainline-Kernel enthalten ^[3]. Sie wurde in die gepflegten Stable-Zweige zurückportiert ^[2][4].

Welche Systeme sind betroffen?

Laut Red Hat betrifft die Lücke jedes System, auf dem ein verwundbarer Kernel mit aktiviertem IPv4-TCP-Netzwerk läuft. Am unmittelbarsten gefährdet sind Systeme, die eingehende TCP-Verbindungen annehmen ^[6]. AlmaLinux rät, jedes System, das IPv4-TCP-Verbindungen aus nicht vertrauenswürdigen Netzen annimmt, als exponiert zu behandeln ^[10]. IPv6 ist vom Hauptproblem nicht betroffen ^[2].

Wie funktioniert die Sicherheitslücke?

Eine TCP-Verbindung beginnt mit einem Handshake. Der Client sendet ein SYN-Paket, der Server antwortet mit einem SYN-ACK, und der Client bestätigt. Ein SYN kann IPv4-Optionen enthalten, also optionale Zusatzfelder im IP-Header. Record Route und Timestamp sind zwei Beispiele ^[1].

Laut der Beschreibung im Kernel übergibt die Funktion tcp_v4_syn_recv_sock() die gespeicherten Optionen an den neuen Child-Socket, ohne sie zu kopieren ^[2]. Gleichzeitig kann ein anderer CPU-Kern ein erneut gesendetes SYN für dieselbe Anfrage verarbeiten und ein SYN-ACK erzeugen, das diese Optionen liest ^[2]. Nichts verhindert, dass der Child-Socket freigegeben wird, während das SYN-ACK noch erzeugt wird. Seine Optionen werden mit einem einfachen kfree() freigegeben, sodass der Kernel in ip_options_build() bereits freigegebenen Speicher liest ^[2].

Eine zweite, ähnliche Race Condition besteht, wenn die Migration von Request-Sockets eingeschaltet ist, entweder über net.ipv4.tcp_migrate_req=1 oder über ein BPF-reuseport-Programm ^[2]. Die Korrektur lässt beide Freigabepfade auf eine RCU-Grace-Period warten, indem sie kfree_rcu() in inet_sock_destruct() und tcp_v4_reqsk_destructor() verwendet ^[2]. RCU (Read-Copy-Update) ist eine Kernel-Technik, die das Freigeben von Speicher verzögert, bis kein Leser ihn mehr verwenden kann.

Was könnte ein Angreifer damit anrichten?

Die Bewertungshinweise im CVE-Eintrag beschreiben drei Auswirkungen ^[1]:

• Offenlegung von Informationen: Der freigegebene Speicher kann von anderen Daten wiederverwendet werden, und sein Inhalt kann in das SYN-ACK kopiert werden, das an den Angreifer zurückgeht ^[1].
• Speicherbeschädigung: Veraltete Längen und Offsets können Schreibzugriffe des Kernels über Grenzen hinaus lenken, mit möglicher Manipulation des Kontrollflusses ^[1].
• Abstürze: Ein wiederverwendeter Längenwert kann eine Kernel-Panic auslösen, und auch die fehlgeleiteten Schreibzugriffe können den Kernel zum Absturz bringen ^[1].

Red Hat ergänzt, dass eine zuverlässige Codeausführung über diesen zeitkritischen Fehler eine präzise Kontrolle über den Heap erfordert. Dennoch stuft das Unternehmen den Fehler als Critical ein, weil es keine netzwerkseitigen Voraussetzungen gibt und er schwere Instabilität verursachen kann ^[7].

Was hat Anthropic offengelegt, und welche Rolle spielt MPTCP?

Am 27. Oktober 2026 veröffentlichte das Frontier Red Team von Anthropic einen Bericht über Sicherheitslücken, die es mithilfe von Claude-Modellen gefunden hatte ^[4][11]. Zu CVE-2026-98432 heißt es dort, das Team habe einen Exploit gebaut, mit dem ein entfernter Angreifer beliebige Befehle als root auf Linux-Servern mit einem Multipath-TCP-Listener (MPTCP) ausführen kann, ohne Zugangsdaten oder Interaktion des Nutzers ^[4]. MPTCP ist eine Erweiterung von TCP, mit der eine Verbindung mehrere Netzwerkpfade gleichzeitig nutzen kann.

Anthropic beschreibt zwei Stufen. Zuerst leakt der Exploit einen Kernel-Pointer, um KASLR auszuhebeln, die Adressrandomisierung des Kernels. Dann überschreibt er einen Callback-Pointer, sodass der Kernel einen vom Angreifer gewählten Befehl als root ausführt ^[4]. Ein verlorenes Race lässt nur den Handshake scheitern und bringt das System nicht zum Absturz, sodass ein Angreifer es immer wieder versuchen kann ^[4]. In Anthropics Proof of Concept dauerte das Leaken eines Kernel-Pointers 48 Minuten, die Befehlsausführung weitere fünf Minuten ^[4].

Ist MPTCP erforderlich?

Nein, sagen die Hersteller, die die Lücke bewertet haben. Red Hat erklärt, dass MPTCP keine notwendige Voraussetzung für diese Lücke ist und Systeme mit deaktiviertem MPTCP weiterhin betroffen sind ^[6]. Das Go-Sicherheitsteam sagt, der vorgeführte Exploit benötige einen MPTCP-Listener, der zugrunde liegende Fehler sei aber nicht MPTCP-spezifisch ^[5]. Go ist hier relevant, weil Go-Programme seit Go 1.24 unter Linux MPTCP für lauschende Sockets standardmäßig aktivieren ^[5].

Laut Akamai hat Anthropic seinen Root-Exploit nicht veröffentlicht, und am 2. November 2026 erklärte Akamai, ihm sei kein öffentlicher, funktionierender Exploit bekannt ^[11].

Welche Kernel-Versionen und Distributionen sind behoben?

Das CVE-Team des Kernels nennt diese Upstream-Korrekturen: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und Mainline 7.3 ^[2]. Die meisten Nutzer verwenden jedoch einen von ihrer Distribution gebauten Kernel mit eigenen Versionsnummern. Prüfen Sie daher den Sicherheitshinweis Ihrer Distribution, statt Upstream-Nummern zu vergleichen.

Stand am 3. November 2026:

• Red Hat Enterprise Linux: Korrigierte Kernel für RHEL 8, 9 und 10 wurden am 1. November 2026 veröffentlicht. RHEL 6 und 7 werden als nicht betroffen geführt. Der Echtzeit-Kernel von RHEL 9 und die OpenShift-Node-Images werden weiterhin als betroffen geführt ^[7].
• Ubuntu: Ubuntu stuft das Problem als Critical ein. Sein Tracker führt 26.10, 26.04 LTS, 24.04 LTS und 22.04 LTS als verwundbar mit Korrekturen in Arbeit; 20.04, 18.04 und 16.04 werden ebenfalls als verwundbar geführt, 14.04 als nicht betroffen ^[8].
• Debian: Korrekturen gibt es für Debian 12 bookworm (linux 6.1.190-1 und linux-6.12 6.12.113-1~deb12u1) und Debian 13 trixie (linux 6.12.113-1) sowie für unstable ^[9].
• AlmaLinux: Korrigierte Kernel für AlmaLinux 8, 9 und 10 liegen in den Produktions-Repositories ^[10].
• Weitere: Laut Akamai hatten SUSE, Oracle Linux und Amazon Linux 2023 bis zum 30. Oktober 2026 für einige Releases korrigierte Kernel veröffentlicht ^[11].

Was ist mit Android-Smartphones?

Android nutzt den Linux-Kernel, doch das am 2. November 2026 veröffentlichte Android Security Bulletin führt CVE-2026-98432 nicht auf ^[13]. Smartphone-Besitzer sollten Sicherheitsupdates installieren, sobald ihr Hersteller sie bereitstellt.

Wie prüfen Sie, ob ein Server verwundbar ist?

1. Ermitteln Sie den laufenden Kernel. Führen Sie uname -r aus. Eine Korrektur zählt erst, wenn die Maschine in den neuen Kernel neu gestartet wurde. AlmaLinux empfiehlt, neu zu starten und die Version mit uname -r zu bestätigen ^[10].
2. Gleichen Sie mit dem Tracker Ihres Anbieters ab. Suchen Sie CVE-2026-98432 auf der Sicherheitsseite Ihrer Distribution. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] und AlmaLinux ^[10] nennen jeweils die Paketversionen, die die Korrektur enthalten.
3. Prüfen Sie MPTCP. sysctl net.mptcp.enabled zeigt, ob MPTCP eingeschaltet ist. sudo ss -lnMp listet MPTCP-Listener und die zugehörigen Prozesse auf ^[10]. Akamai empfiehlt außerdem, net.ipv4.tcp_migrate_req zu prüfen ^[11].
4. Suchen Sie nach Go-Diensten. Mit Go 1.24 oder neuer gebaute Programme öffnen unter Linux standardmäßig MPTCP-Listener ^[5]. Jeder Go-Dienst, den Sie betreiben, kann daher den Pfad offenlegen, den Anthropic ausgenutzt hat.
5. Prüfen Sie darauf aufbauende Produkte. Red Hat warnt, dass jedes auf dem RHEL-Kernel basierende Produkt, darunter OpenShift, OpenStack und Red Hat Virtualization, ebenfalls betroffen sein kann ^[6].

Wie beheben oder entschärfen Sie CVE-2026-98432?

Die eigentliche Lösung ist ein gepatchter Kernel. Red Hat bezeichnet das Einspielen von Kernel-Updates als einzige vollständige Lösung ^[6], und das Go-Sicherheitsteam sagt, die beste Abhilfe sei ein Upgrade auf einen gepatchten Kernel ^[5]. Installieren Sie das Kernel-Update Ihrer Distribution, starten Sie neu und bestätigen Sie die laufende Version.

Was können Sie tun, bevor ein Patch verfügbar ist?

• Verwerfen Sie TCP-Pakete mit IPv4-Optionen. Red Hat veröffentlicht eine nftables-Regel, die auch der Tracker von Ubuntu als von Nutzern beigesteuerten Workaround aufführt: Sie verwirft eingehende IPv4-TCP-Pakete, deren IP-Header länger als die grundlegenden 20 Bytes ist, also Pakete mit Optionen (ip hdrlength > 5) ^[6][8]. Normale TCP-Optionen wie Timestamps und Window Scaling stehen im TCP-Header und sind nicht betroffen ^[8]. Beide Hersteller sagen, dass die Regel das Risiko senkt, eine Ausnutzung aber nicht vollständig verhindern kann ^[6][8].
• Kennen Sie die Grenzen der Regel. AlmaLinux weist darauf hin, dass seine Variante einen Neustart nicht überdauert, dass Verkehr zwischen Containern auf demselben Host sie umgehen kann, dass sie auf Routing-Hosts auch weitergeleitete Pakete verwirft und dass sie Netze stört, die auf CIPSO/NetLabel-Labels angewiesen sind ^[10]. Ubuntu merkt an, dass die Regel bei Containern mit eigenem Netzwerk separat angewendet werden muss ^[8].
• Deaktivieren Sie MPTCP, wenn Sie es nicht brauchen. Mit net.mptcp.enabled=0 wird MPTCP systemweit abgeschaltet ^[10]. Akamai empfiehlt zusätzlich, net.ipv4.tcp_migrate_req=0 zu setzen ^[11]. Akamai warnt, dass das Deaktivieren von MPTCP allein eine Ausnutzung nicht verhindert, sondern nur die Wahrscheinlichkeit senkt, das Race auszulösen ^[11]. Go-Programme können sich auch mit GODEBUG=multipathtcp=0 abmelden, doch das Go-Team bezeichnet solche Opt-outs pro Programm als fragil ^[5].
• Filtern Sie am Netzwerkrand. Für OpenShift weist Red Hat darauf hin, dass Regeln auf einem Node den Verkehr zwischen Pods nicht filtern, während eine Filterung an der Netzwerkgrenze vor dem Cluster diese Einschränkung vermeidet ^[6].

Hilft init_on_free=1?

In einem Beitrag auf oss-security wurde die Boot-Option init_on_free=1 als zusätzliche Notlösung vorgeschlagen. Ein Mitglied des Kernel-Teams bei CIQ antwortete, dass sie diese CVE nicht nennenswert entschärft und in Sicherheitshinweisen kein Gewicht haben sollte ^[12]. Betrachten Sie sie als allgemeine Härtung, nicht als Gegenmaßnahme gegen diesen Fehler.

Wird CVE-2026-98432 bereits ausgenutzt?

Mit Stand 3. November 2026 taucht CVE-2026-98432 nicht im Known Exploited Vulnerabilities Catalog der CISA auf, der Liste der US-Regierung mit Lücken, deren Ausnutzung in der Praxis bestätigt ist ^[14]. Akamai erklärte am 2. November 2026, ihm sei kein öffentlicher, funktionierender Exploit bekannt ^[11]. Das ist kein Beweis, dass niemand den Fehler ausnutzt. Es ist belegt, dass ein zuverlässiger Exploit existiert ^[4], und die technischen Details sind in der Kernel-Korrektur öffentlich ^[3].

Auch die Einschätzung des Schweregrads hat sich mit der Zeit verschoben. Die CVE wurde erstmals am 15. Oktober 2026 veröffentlicht ^[1]. Breitere Aufmerksamkeit folgte auf Anthropics Bericht vom 27. Oktober ^[4][11]. Sicherheitsbulletins der Hersteller mit vorläufigen Gegenmaßnahmen folgten zwischen dem 29. Oktober und dem 2. November ^[5][6][10]. Administratoren, die nur den ursprünglichen Eintrag überflogen haben, könnten die späteren Empfehlungen verpasst haben.

Wie geht es weiter?

Red Hat bezeichnet seine Untersuchung als noch laufend und kündigt an, das Bulletin zu aktualisieren, sobald neue Informationen vorliegen ^[6]. Es ist zu erwarten, dass die übrigen Pakete, etwa der Echtzeit-Kernel von RHEL 9 und die OpenShift-Images ^[7] sowie die noch in Arbeit befindlichen Ubuntu-Kernel ^[8], in den kommenden Tagen oder Wochen Korrekturen erhalten. Prüfen Sie die Tracker der Hersteller statt Nachrichtenzusammenfassungen, denn diese Seiten haben sich in den ersten Wochen mehrfach geändert.

Die Kernel-Korrektur lässt zudem ein verwandtes Problem offen. Laut der Kernel-Beschreibung hat tcp_v6_reqsk_destructor() bei IPv6 dasselbe Migrationsproblem mit Optionen, die nur von CALIPSO gesetzt werden; dies soll in einem separaten Patch behandelt werden ^[2]. Nach Anthropics Richtlinie zur koordinierten Offenlegung gelten 90 Tage für das Patchen plus weitere 45 Tage, bevor Details über den öffentlichen Sicherheitshinweis hinaus erörtert werden ^[4]. Weitere technische Details könnten daher später erscheinen.

Dies sind allgemeine technische Informationen und kein Ersatz für den Sicherheitshinweis Ihres Herstellers oder den Incident-Response-Prozess Ihrer Organisation.