MPTCP-Lücke in Linux: Root aus der Ferne, Patches fehlen noch

Anthropic hat die Linux-Lücke CVE-2026-98432 laut BleepingComputer vom 30. Oktober 2026 mit einem unveröffentlichten Claude-Modell in etwa 53 Minuten zum Root-Zugriff, also zu vollen Administratorrechten, aus der Ferne ausgebaut. Der Angriff braucht keine Zugangsdaten, aber einen MPTCP-Listener, also einen Dienst, der Verbindungen über Multipath TCP annimmt. Bestätigte Angriffe in freier Wildbahn gibt es laut BleepingComputer bislang nicht.

Wie ein Wettlauf im Linux-Kernel Speicher zum Einfallstor macht

CVE-2026-98432 ist laut BleepingComputer ein Use-after-free im IPv4-TCP-Code des Kernels, also ein Zugriff auf Speicher, der bereits freigegeben wurde. Betroffen sind laut dem Bericht Kernel ab Version 4.4, darunter die von Ubuntu, Red Hat Enterprise Linux (RHEL) und Rocky Linux. Red Hat ordnet die Schwäche auf seiner CVE-Seite als CWE-825 ein, als Zugriff auf einen abgelaufenen Zeiger. Veröffentlicht wurde die CVE laut Ubuntu und CIQ am 15. Oktober 2026, der Bericht über den Exploit folgte am 30. Oktober.

Die Ursache ist laut Kernel-Advisory ein Wettlauf zwischen zwei Prozessorkernen, im Fachjargon eine Race Condition. Der Kernel reicht die IP-Optionen einer Verbindungsanfrage an den Kindsocket weiter, den neuen Endpunkt der Verbindung, ohne sie zu kopieren. Ein anderer Prozessorkern kann zeitgleich eine erneut gesendete Anfrage (SYN) bearbeiten und eine Antwort bauen. Laut Ubuntu-Eintrag vom 30. Oktober 2026 verhindert nichts, dass der Kindsocket in diesem Moment freigegeben wird. Der Kernel liest dann in Speicher, der ihm nicht mehr gehört.

Laut dem von BleepingComputer zitierten Advisory lesen zwei Funktionen die Optionen nur unter einer Lesesperre (rcu_read_lock). Zwei weitere Funktionen lesen anschließend die Länge der Optionen gleich zweimal. Der Timer für die Antwort ist laut Ubuntu-Eintrag unproblematisch, weil er eine Referenz auf seinen Anfragesocket hält.

Eingeführt hat den Fehler laut CIQ der Commit 079096f103fa in Kernel 4.4, eine Code-Änderung an der Zuständigkeit für IP-Optionen zwischen Anfrage- und Kindsockets. Seither verarbeitet der Kernel Anfragesockets laut Ubuntu ohne Sperre des Listeners. Ein ähnlicher Fehler steckt laut Ubuntu-Eintrag in der Migration von Anfragesockets, wenn net.ipv4.tcp_migrate_req aktiv ist oder ein BPF_SK_REUSEPORT_SELECT_OR_MIGRATE-Programm läuft.

Die Korrektur ersetzt laut CIQ in zwei Funktionen kfree durch kfree_rcu. Damit wartet die Freigabe, bis laufende Lesezugriffe beendet sind. Backports, also Rückportierungen auf ältere Kernel-Serien, gibt es laut CIQ für 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 und 7.2.10.

Was ein MPTCP-Listener mit dem Root-Exploit zu tun hat

Multipath TCP (MPTCP) lässt eine einzelne Verbindung mehrere Netzwege gleichzeitig nutzen, etwa WLAN und Mobilfunk, erklärt BleepingComputer. Anthropic beschreibt laut BleepingComputer einen Exploit, der KASLR umgeht und Befehle als Root auf einem Linux-Server mit MPTCP-Listener ausführt. KASLR ist die zufällige Anordnung des Kernel-Speichers, die Angriffe erschweren soll. Ein Dienstausfall ist bei dieser Lücke demnach nicht das einzige Szenario.

Der CIQ-Artikel vom 30. Oktober 2026 schlüsselt die Laufzeit nach Anthropics Beitrag auf. Anthropics Proof of Concept, also ein Machbarkeitsnachweis, brauchte 48 Minuten für das Leaken eines Kernel-Zeigers, also das Verraten einer Speicheradresse. Bis zur Befehlsausführung kamen etwa fünf Minuten hinzu. Verliert der Angreifer den Wettlauf, scheitert laut CIQ nur der Verbindungsaufbau. Der Versuch lässt sich wiederholen.

Brisant ist, wie leicht ein MPTCP-Listener ungewollt entsteht. Ab Go 1.24 aktiviert die Programmiersprache MPTCP laut BleepingComputer standardmäßig für TCP-Listener unter Linux, sofern der Kernel das Feature unterstützt. Manche Go-Dienste öffnen deshalb MPTCP-Listener, ohne dass Administrierende davon wissen. Der Schalter net.mptcp.enabled entscheidet laut CIQ, ob Listener MPTCP aushandeln. Auf den getesteten Kernels steht er standardmäßig auf 0, also aus.

Wie eng die Lücke an MPTCP hängt, wird unterschiedlich dargestellt. Laut Go-Team, zitiert von CIQ, braucht der gezeigte Exploit einen MPTCP-Listener, während der Fehler selbst nicht an das Feature gebunden ist. Die Lücke betrifft laut BleepingComputer auch gewöhnliche TCP-Verbindungen. Codeausführung ohne MPTCP-Listener wurde laut BleepingComputer bislang nicht öffentlich gezeigt. Go-Issue 82717 nennt es laut CIQ unbekannt, ob die Lücke eng mit MPTCP zusammenhängt. Die CVE-Einträge von kernel.org und cve.org erwähnen MPTCP laut CIQ gar nicht. Die Lücke kennt MPTCP nicht, der Exploit schon.

Zwischen 5,9 und 9,8 liegen die Schweregrade der Lücke

Die Schweregrade für CVE-2026-98432 reichen laut BleepingComputer, Red Hat und CIQ von 5,9 bis 9,8. Bewertet wird nach CVSS, einer Skala für Schwachstellen mit dem Höchstwert 10. Das CVE-Team des Linux-Kernels vergibt laut BleepingComputer 9,8 von 10. Nach CIQ gilt das bei niedriger Angriffskomplexität. Das Upstream-Advisory rechnet laut CIQ mit 8,1 (important) bei hoher Komplexität. NVD, die US-Schwachstellendatenbank, zeigt laut CIQ nur die 9,8 des Kernel-Teams. Beide Werte liegen laut CIQ oberhalb der Schwelle von 7, ab der die CIQ-FAQ den Fokus auf Behebung legt.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2 pro 1k 16:9PromptClose view of a network switch in an open rack with several ethernet cables of different colors plugged into separate ports and routed along cable trays. Behind the switch, a row of cooling fans and metal rack rails catch a pale bluish light. Photorealistic style image. Mood: Calm but watchful, technical and precise. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

BleepingComputer schreibt, Red Hat stufe die Lücke als möglichen Dienstausfall (Denial of Service) mit 5,9 ein, weil die Ausnutzung komplex sei. Die Red-Hat-Seite zur CVE nennt dagegen eine Basisbewertung von 9,8 und die Einstufung Critical für RHEL. Dort heißt es, ein Angreifer ohne Anmeldung könne Kernel-Speicher beschädigen oder das System zum Absturz bringen. In Standardkonfigurationen nehmen TCP-Dienste laut Red Hat Verbindungen ohne spezielle Anpassung an, die Pfade zur Verbindungsbearbeitung liegen damit offen im Netz. Zuverlässige Codeausführung verlange präzise Kontrolle über den Heap, den dynamischen Arbeitsspeicher. Die fehlenden Voraussetzungen im Netz heben die Wirkung laut Red Hat trotzdem über Important. Beide Darstellungen widersprechen sich.

Auch die Folgen beschreiben die Einträge unterschiedlich. Laut CIQ nennt die Upstream-Beschreibung einen Systemabsturz mit Dienstausfall oder mögliche Speicherbeschädigung. Das Szenario im Kernel-Eintrag listet laut CIQ zusätzlich Informationsabfluss und Schreibzugriffe außerhalb der Speichergrenzen. Ubuntu führt die Lücke laut Sicherheitsseite vom 30. Oktober 2026 mit Priorität High und CVSS 9,8.

Der KEV-Katalog der US-Behörde CISA listet tatsächlich ausgenutzte Schwachstellen. Laut CIQ enthielt er in der Version 2026.10.29 am 30. Oktober 2026 keinen Eintrag zu CVE-2026-98432. Was ein Eintrag auslöst, zeigt die Brotli-Lücke Node2Shell: Die CISA verlangt laut BleepingComputer vom 28. Oktober 2026 von US-Bundesbehörden Patches bis zum 10. November. Komplexität ist ein schwaches Argument, wenn der Exploit unter bestimmten Bedingungen in etwa 53 Minuten zum Root-Zugriff führt.

Gepatcht ist erst ein Teil der Distributionen

Gepatcht sind laut BleepingComputer vom 30. Oktober 2026 bislang nur ausgewählte Linux-Distributionen. Der Stand je Distribution:

• Debian: Laut Debian-Tracker, zitiert von BleepingComputer, behebt das Kernel-Paket 6.1.190-1 die Lücke für Debian 12 (Bookworm), 6.12.113-1 für Debian 13 (Trixie). Auch Debian testing und unstable haben gepatchte Pakete.
• Oracle Linux, Amazon Linux und SUSE: Laut BleepingComputer gibt es Fixes für einige betroffene Kernel-Versionen.
• Ubuntu: Laut Canonicals Sicherheitstracker bleiben 22.04 LTS, 24.04 LTS, 26.04 LTS und 26.10 verwundbar, die Fixes sind am 30. Oktober 2026 in Arbeit. Die Ubuntu-Seite führt auch 20.04 LTS, 18.04 LTS und 16.04 LTS als verwundbar.
• RHEL: Red Hat listet RHEL 8, 9 und 10 als betroffen, die Fixes sind laut BleepingComputer für künftige Updates geplant. RHEL 7 ist nicht betroffen, weil sein Kernel den verwundbaren Code nicht enthält.
• Rocky Linux: Laut CIQ sind Rocky Linux 8, 9 und 10 betroffen, und am 30. Oktober 2026 war für keine der geprüften CIQ-Varianten ein gepatchter Kernel veröffentlicht.
• macOS: Laut BleepingComputer nicht betroffen, weil es Apples XNU-Kernel statt des Linux-Kernels nutzt.

Auch Cloud-Kernel wie linux-aws, linux-azure und linux-kvm sowie die FIPS-Kernel führt die Ubuntu-Seite als verwundbar. Scanner, die nur Paketversionen vergleichen, melden laut der Red-Hat-FAQ gepatchte Pakete mitunter als verwundbar, weil Red Hat Fixes zurückportiert statt Versionen zu erhöhen. Dass Distributionen unter Zeitdruck Eil-Patches ausliefern, zeigte schon der Fall Copy Fail. Bei Ubuntu steht derzeit „work in progress“, auf Deutsch: noch nicht.

Bis zum Patch: Zugriff begrenzen, Optionspakete blocken

Bis ein gepatchter Kernel erscheint, empfiehlt der Rocky-Linux-Dienstleister CIQ in seinem Artikel vom 30. Oktober 2026 eine Regel für nftables, den Paketfilter des Kernels. Sie verwirft laut CIQ jedes IPv4-TCP-Paket, dessen Header länger als 20 Bytes ist. Nur solche Pakete tragen IP-Optionen. Das verwundbare Objekt entsteht laut CIQ nur, wenn ein SYN-Paket oder die Bestätigung im Syncookie-Verfahren IP-Optionen trägt. Wo Patches fehlen, kann laut BleepingComputer auch helfen, den Zugriff auf vertrauenswürdige Netze oder IP-Adressen zu beschränken.

Getestet hat CIQ die Befehle auf seinen Varianten RLC Pro LTS 9.6, RLC Pro LTS 8.10 und RLC Pro 10 sowie auf Rocky Linux 9.6, 8.10 und 10.2, jeweils mit laufender firewalld. Vor dem Einsatz nennt CIQ vier Einschränkungen:

• MPTCP abzuschalten genügt nicht: Mit net.mptcp.enabled=0 beantwortete laut CIQ ein gewöhnlicher TCP-Listener auf allen getesteten Kernels ein SYN mit Record-Route-Option und gab die Option im SYN-ACK zurück.
• Die Regel blockt auch legitimen Verkehr mit IP-Optionen, deshalb rät CIQ zum Test auf einem Host außerhalb der Produktion.
• Nicht getestet sind laut CIQ IPv6, fragmentierte Pakete, andere Zustellwege, Container und weitergeleiteter Verkehr, außerdem wurde die CPU-Last nicht gemessen.
• Stoppt nftables.service, entfernt das laut CIQ die Tabelle samt Regel; ein Neustart der CIQ-Unit stellt sie wieder her.

Prüfen Sie zuerst, was auf Ihren Servern läuft. Mit uname -r lesen Sie die Kernel-Version aus, mit sysctl net.mptcp.enabled den MPTCP-Schalter, beides nennt CIQ. Mit ss -Mltn zeigt ein MPTCP-Listener laut CIQ eine eigene mptcp-Zeile, auf RLC Pro LTS 8.10 fehlte sie im Test, dort hilft nur der sysctl-Check. Den Changelog-Test mit rpm -q –changelog wertet CIQ nicht als Beweis, hinzu kommt der Abgleich mit dem Herstellerhinweis. Go-Dienste ab Version 1.24 stehen dabei ganz oben. Für RHEL verweist die Red-Hat-Seite auf das Security Bulletin RHSB-2026-016, das ein Mitigationsverfahren beschreibt.

Die Regel lässt sich laut CIQ dauerhaft laden, über eine nftables-Datei und eine systemd-Unit, die beim Start vor dem Netzwerk lädt. Dass nach einem Kernel-Update eine forensische Prüfung folgen kann, zeigt der Beitrag zu Fragnesia.

Als Standardweg rät CIQ, Systeme über das normale Repository aktuell zu halten. Wollen Sie die Betroffenheit einer ganzen Flotte klären, empfiehlt der Artikel einen Support-Fall. Eine Frist sagt CIQ nicht zu, die CIQ-FAQ schließt SLAs für CVE-Behebungen aus.

Offen bleibt der Termin für gepatchte Kernel bei CIQ: Der Artikel vom 30. Oktober 2026 nennt keinen und soll aktualisiert werden, sobald validierte Builds erscheinen. Erscheint ein Kernel für Ihre Variante, installieren Sie ihn mit sudo dnf update kernel*, starten neu und entfernen die Zwischenregel.