Eine kritische Lücke im TCP-IPv4-Code des Linux-Kernels, geführt als CVE-2026-98432, kann zur Remote-Code-Ausführung führen. Red Hat hat am 1. November die korrigierten Kernel für RHEL 8, 9 und 10 veröffentlicht. Canonical hat am 2. November die Korrekturen für Ubuntu 22.04, 24.04 und 26.04 LTS im Testkanal -proposed bereitgestellt, ohne Termin für die reguläre Auslieferung. Wer exponierte Server betreibt, muss sich entscheiden – warten oder jetzt installieren.
Ein paar Begriffe, bevor wir in die Fakten einsteigen. CVE ist die Kennung für eine bekannte Schwachstelle. CVSS ist die Skala von 0 bis 10, die ihre Schwere misst, hier 9.8. Use-after-free ist ein Fehler, bei dem das Programm bereits freigegebenen Speicher liest. -proposed ist der Ubuntu-Kanal, in dem Updates zur Prüfung liegen und sich nicht von selbst installieren. MPTCP ist Multipath TCP, eine Protokollvariante, die mehrere Netzwerkpfade nutzt.
Was steckt hinter der Lücke CVE-2026-98432?
Laut der Darstellung von The Hacker News übergibt der Kernel beim Aufbau einer TCP-IPv4-Verbindung die IP-Optionen der Anfrage an den neuen Socket, ohne sie zu kopieren. Sendet der Client die Anfrage erneut, während ein anderer Prozessor diese Optionen noch liest, kann der Kernel bereits freigegebenen Speicher lesen.
Angreifer schicken Anfragen mit den IPv4-Optionen Record Route oder Timestamp an einen beliebigen lauschenden TCP-Port. Ein Zugang ist nicht nötig. Der IPv6-Hauptpfad ist nicht betroffen. Der Fehler existiert seit Kernel 4.4, und die Korrektur im Upstream kam im Oktober.
Wie schwer wiegt die Lücke und gibt es einen Exploit?
Das CVE-Team des Kernels vergibt 9.8 von 10 Punkten. Red Hat ging zunächst von 5.9 (Moderate) aus und hob die Bewertung später auf 9.8 an und stufte die Lücke als Critical ein. Amazon Linux bewertet sie mit 8.1 als Important und spricht vor allem von Abstürzen mit möglicher Speicherbeschädigung.
Kein Anbieter, CERT oder Kernel-Team meldet Angriffe, und Ende Oktober stand die Lücke nicht im CISA-Katalog ausgenutzter Schwachstellen. Anthropic erklärt, ein internes Forschungsmodell habe einen Root-Exploit für Server mit MPTCP-Listener geschrieben, den Code aber nicht veröffentlicht. Auf GitHub gibt es nur Code, der die kritische Race Condition auslöst, ohne Codeausführung.
Welche Ubuntu-Versionen sind betroffen und wie installierst du den Patch?
Laut dem offiziellen Ubuntu-Blog hat Jammy (22.04) den Kernel 5.15.0-203.213 in -proposed, Noble (24.04) den 6.8.0-149.149 und Resolute (26.04) den 7.0.0-43.43. Stonking (26.10) ist mit 7.3.0-10.10 bereits korrigiert. Für Focal, Bionic und Xenial ist die Korrektur unterwegs, Trusty ist nicht betroffen.
Mit uname -r prüfst du den laufenden Kernel. Um den Fix vorzuziehen, aktivierst du -proposed mit add-apt-repository, installierst die angegebene Version mit apt install -t und startest neu. Canonical testet Updates vor der regulären Auslieferung auf über 2.000 Servern und zertifizierten Geräten. Für ältere Versionen brauchst du Ubuntu Pro mit ESM.
Wenn du Pakete von Hand verwaltest, hilft dir unser Leitfaden zu apt und dnf bei den Schritten.
Gibt es Abhilfen, und reicht es, MPTCP abzuschalten?
Nein, MPTCP allein abzuschalten reicht nicht. Der Fehler sitzt im TCP-IPv4-Pfad und nicht in MPTCP, und Canonical betont, dass für das Ubuntu Security Team Updates die einzig angemessene Gegenmaßnahme sind. Der Rat zum Protokoll entstand nur, weil der von Anthropic beschriebene Exploit es verwendet.
Red Hat hat am 30. Oktober eine nftables-Regel veröffentlicht, die TCP-IPv4-Pakete mit IP-Optionen verwirft. Sie blockiert den bekannten Auslöser, verhindert eine Ausnutzung aber nicht vollständig und kann Dienste stören, die diese Optionen nutzen. Sie wirkt nur auf dem Host, auf dem sie geladen ist, und Verkehr zwischen Containern auf derselben Maschine kann sie umgehen. Für die Netzwerkregeln hilft dir der Leitfaden zur Linux-Netzwerkkonfiguration weiter.
Grenzen, die du kennen solltest
Für die reguläre Veröffentlichung von Ubuntu gibt es keinen Termin. Die Cloud-, FIPS- und Real-time-Varianten sind noch in Arbeit, während der Canonical-Beitrag nur den generischen Kernel abdeckt. Der Exploit von Anthropic ist nicht öffentlich, und seine Wirksamkeit ist eine Aussage des Unternehmens, die kein Dritter überprüft hat. Das Bild zu realen Angriffen kann sich schnell ändern.
Was sich für alle ändert, die mit digitalen Systemen arbeiten
Wenn du Ubuntu-Server 22.04, 24.04 oder 26.04 betreibst, die aus dem Internet erreichbar sind, musst du jetzt entscheiden, ob du -proposed nutzt oder wartest. Auf RHEL 8, 9 und 10 genügt es, das Update zu installieren und neu zu starten. Der Neustart muss geplant werden, du brauchst also ein Wartungsfenster. Prüfe auch Container und virtuelle Maschinen, denn sie übernehmen den Kernel des Hosts. Wer einen verwalteten Hosting-Dienst nutzt, sollte beim Anbieter nach dem Stand des Patches fragen.
Unsere Einschätzung
Die Entscheidung von Canonical ist technisch vorsichtig, lässt aber gerade die Server, die den Patch am dringendsten brauchen, tagelang ungeschützt. Eine 9.8, die ohne Authentifizierung erreichbar ist, verdient einen schnelleren Weg, und das Risiko auf den Administrator mit -proposed zu verlagern ist nur vertretbar, wenn es klar erklärt wird. Der Blog tut das, aber die Verzögerung bei den älteren Versionen bleibt ein Problem. Anzuerkennen ist, dass der Rat, MPTCP abzuschalten, deutlich widerlegt wurde.
Häufig gestellte Fragen
Wird CVE-2026-98432 schon ausgenutzt?
Es gibt keine Angriffsmeldungen von Anbietern, CERTs oder dem Kernel-Team. Die Lücke stand Ende Oktober nicht im CISA-Katalog. Vorhanden sind aber ein von Anthropic beschriebener, nicht veröffentlichter Exploit und Testcode auf GitHub.
Wie prüfe ich, ob mein Ubuntu betroffen ist?
Führe uname -r aus und vergleiche die Version mit der Tabelle von Canonical. Die installierten Pakete siehst du mit dpkg -l 'linux-image*'. Nach dem Update ist außerdem ein Neustart nötig.
Kann ich den Patch aus -proposed installieren?
Ja, wenn du bereit bist, einen noch in der Prüfung befindlichen Kanal zu nutzen. Du aktivierst -proposed und installierst den Kernel ausdrücklich, weil er sich nicht automatisch aktualisiert. Danach startest du neu.
Löst das Abschalten von MPTCP das Problem?
Nein. Die Lücke liegt im TCP IPv4 und nicht in MPTCP, wie Canonical betont. Der Rat entstand nur aus dem Exploit, den Anthropic beschreibt.
Und für Ubuntu 20.04 oder älter?
Derzeit gibt es dafür keinen Fix. Focal, Bionic und Xenial warten noch und laufen über Ubuntu Pro mit ESM. Trusty ist nicht betroffen.
Worauf du in den nächsten Tagen bei den Ubuntu-Kerneln achten solltest
Entscheidend sind die reguläre Veröffentlichung durch Canonical und die mögliche Veröffentlichung des Exploits.
- Verfolge die CVE-Seite von Ubuntu, um das Datum für den Updates-Kanal und die Cloud-Varianten zu sehen.
- Prüfe, ob Angriffsmeldungen auftauchen oder die Lücke in den CISA-Katalog aufgenommen wird.
- Plane ein Neustart-Fenster für exponierte Server, damit du den Patch sofort einspielen kannst, sobald er verfügbar ist.




