Ich verwalte seit Jahren Debian-Server im produktiven Einsatz. Jedes Mal, wenn eine neue CVE zum Kernel erscheint, halte ich an und lese mir die Details durch. Dann entscheide ich, ob ich sofort aktualisiere oder warte. Dieses Mal ist die Geschichte verzwickter als sonst: Es gibt eine Schwachstelle im Linux-Kernel im TCP-IPv4-Code, einen zwischen den Herstellern umstrittenen CVSS-Score, und sogar einen angeblichen Root-Exploit, der von einer künstlichen Intelligenz gebaut wurde. Fangen wir mit einer Frage an, die nebensächlich wirkt, es aber nicht ist: Was ist MPTCP, und warum ist es wichtig, selbst wenn du es nicht nutzt?
Was ist MPTCP, und warum betrifft es auch dich, wenn du es nicht nutzt
Multipath TCP (MPTCP) ist der Standard RFC 8684. Er erweitert das klassische TCP, damit eine einzelne Verbindung gleichzeitig über mehrere Netzwerkpfade laufen kann. Ein Smartphone kann WiFi und Mobilfunk im selben Moment nutzen, für dieselbe Verbindung. Ein Server mit mehreren Schnittstellen kann dasselbe tun, für Redundanz oder um Bandbreite zu summieren. Apple nutzt es produktiv schon seit iOS 7, im Jahr 2013, für Siri: das ist der bekannteste reale Anwendungsfall. Manche Mobilfunkanbieter, zum Beispiel in Südkorea, setzen es für WiFi/LTE-Bonding ein. Mehrere Rechenzentren nutzen es für Multihoming zwischen verschiedenen Uplinks. Im Linux-Mainline-Kernel ist es seit Version 5.6 enthalten.
Der Punkt, der mich die Augenbraue hochziehen ließ, ist ein anderer. Seit Version 1.24 verlangen in Go geschriebene Programme standardmäßig MPTCP für lauschende Sockets. Das Go Security Team hat das am 29. Oktober bestätigt. Gleichzeitig hat es eine unangenehme Warnung ausgesprochen: Der Bug, von dem wir heute sprechen, ist nicht MPTCP-spezifisch. Ein System ohne aktive MPTCP-Listener kann trotzdem ähnlichen Angriffen ausgesetzt sein. Der verwundbare Code liegt im generischen TCP-IPv4-Pfad, nicht in einem optionalen Modul. Man kann MPTCP pro Programm deaktivieren, mit der Variable GODEBUG=multipathtcp=0 zur Laufzeit. Doch das Go Security Team bezeichnet diese Abmilderung als „brüchig“: Ein einziger verbleibender MPTCP-Listener reicht aus, um sie zunichtezumachen. Niemand hat bewiesen, dass jeder funktionierende Exploit tatsächlich von MPTCP abhängt. Deshalb bleibt der MPTCP-Code eine Angriffsfläche, auch wenn du ihn in deinem Stack nie bewusst aktivierst: Es reicht, dass er in den Kernel compiliert und erreichbar ist.
Das MPTCP-Projekt selbst erklärt auf seiner eigenen Seite, dass die wichtigsten aktuellen Linux-Distributionen den Kernel standardmäßig mit MPTCP-Unterstützung compiliert ausliefern (CONFIG_MPTCP=y). Es nennt ausdrücklich Debian, Ubuntu, RHEL und Fedora. Das ist eine Aussage des Projekts selbst, keine unabhängige Überprüfung Distribution für Distribution, aber das Konzept bleibt gültig: Die Unterstützung ist auf Kernel-Ebene aktiviert, nicht „opt-in“ auf Betriebssystemebene. Nur die Aushandlung pro einzelner Verbindung bleibt Aufgabe der Anwendung.
Die Schwachstelle im Linux-Kernel CVE-2026-98432 im Überblick
Das CVE-Team des Linux-Kernels hat CVE-2026-98432 am 15. Oktober 2026 veröffentlicht. Der Upstream-Fix war bereits zehn Tage zuvor angewendet worden, am 5. Oktober. Es kommt häufig vor, dass die Veröffentlichung dem Commit mit einer gewissen Verzögerung folgt. Der CVSS-Score von 9,8 (kritisch) kam erst am 24. Oktober, neun Tage nach der Veröffentlichung der CVE.
Das Problem liegt in der Behandlung des TCP-Handshakes für IPv4, genauer in der Funktion tcp_v4_syn_recv_sock(). Wenn eine Verbindung erstellt wird, werden die IP-Optionen des SYN-Pakets vom wartenden Request-Socket an den neuen Socket übergeben. Zum Beispiel Record Route oder Timestamp, falls der Client sie in einem eigens konstruierten SYN einfügt. Das Problem ist, dass sie per Referenz übergeben werden, nicht per Kopie, und ohne das Lock des Listeners. Laut der technischen Analyse des Patches heißen die betroffenen Strukturen inet_opt und ireq_opt. Eine zweite CPU kann diesen Puffer mit kfree() freigeben, aufgerufen von inet_sock_destruct() oder von tcp_v4_reqsk_destructor(). Währenddessen liest eine erste CPU ihn noch in ip_options_build(), um das SYNACK zu bauen. Es ist ein klassisches Use-after-free, verursacht durch eine Race Condition. Der entsprechende IPv6-Pfad, tcp_v6_syn_recv_sock(), kopiert die Optionen statt sie per Referenz zu übergeben: Er ist von der Haupt-Race nicht betroffen. Es gibt auch einen zweiten Angriffsweg, über die Migration von Request-Sockets: net.ipv4.tcp_migrate_req=1 oder ein eBPF-Programm mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Beide sind standardmäßig deaktiviert.
Der Bug ist remote ausnutzbar und erfordert laut Einschätzung des Kernel-Teams weder Authentifizierung noch Benutzerinteraktion. Er ist seit Kernel-Version 4.4 vorhanden. Der Fix stammt von Eric Dumazet, gemeldet von Xinyang Ge von Anthropic. Er verschiebt die Freigabe des Speichers auf die Zeit nach einer RCU-Grace-Period, mit kfree_rcu(): So kann keine CPU mehr einen bereits freigegebenen Puffer lesen. Die korrigierten stabilen Versionen sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und die Mainline ab 7.3-rc7.
Widersprüchliche CVSS-Scores: Nicht alle Hersteller sind sich einig
Hier wird die Geschichte komplizierter. Das Kernel-CVE-Team und Ubuntu bewerten die Angriffskomplexität als niedrig und vergeben 9,8 (kritisch). Oracle und SUSE vergeben dagegen 8,1 (wichtig): derselbe CVSS-Vektor, aber hohe Angriffskomplexität. Red Hat hat merkwürdigerweise zwei Bewertungen, die nicht übereinstimmen. Die öffentliche CVE-Seite zeigt „Moderate, 5.9“. Die maschinenlesbare Advisory-Datei, aktualisiert am 29. Oktober, zeigt dagegen „Important, 8.1“, mit hoher Auswirkung auf Vertraulichkeit und Integrität. Am selben Tag hat der interne Bugtracker von Red Hat die Schwere von medium auf high angehoben. Amazon vergibt seinerseits 7,0. Zum Zeitpunkt, an dem ich das schreibe, hat die NVD noch keinen eigenen Score veröffentlicht.
Das sollte man ehrlich sagen. Diese interne Unstimmigkeit bei Red Hat ist kein Detail, das ich selbst hergeleitet habe: Sie wird so vom Originalartikel von The Hacker News berichtet, meiner Hauptquelle für diese Daten. Es ist nicht das erste Mal, dass ein Hersteller für denselben Bug zwei unterschiedliche Zahlen auf unterschiedlichen Kanälen veröffentlicht. Aber hier sagt der Sprung von „moderat“ zu „wichtig“ am selben Tag viel aus. Auch für diejenigen, die den Code schreiben, ist es schwierig, die tatsächliche Ausnutzbarkeit einer Race Condition im Kernel mit Sicherheit einzuschätzen.
Patch-Status: Debian schon korrigiert, andere noch nicht
Das ist der Punkt, der mich am direktesten betrifft: Die Hosting-Umgebungen, die ich verwalte, laufen auf Debian Stable. Und hier sprechen die Fakten klar, ohne dass man etwas betonen müsste: Debian hat diese Schwachstelle im Linux-Kernel bereits korrigiert, sowohl auf trixie als auch auf bookworm. Debian trixie (stable) wurde am 16. Oktober 2026 korrigiert, mit dem Paket linux 6.12.113-1, Advisory DSA-6568-1. Debian 12 (bookworm) wurde in zwei Schritten korrigiert: am 17. und am 22. Oktober 2026, mit linux 6.1.190-1 (Advisory DLA-4841-1) und linux-6.12 6.12.113-1~deb12u1 (Advisory DLA-4850-1). In seiner eigenen Tracking-Tabelle listet Debian für diese CVE keinen eigenen CVSS-Score auf. Es markiert nur den Fix-Status für jedes Release: Das ist die Information, die wirklich zählt, für alle, die entscheiden müssen, ob sie einen Server neu starten.
Es hilft, das mit dem Status anderer weit verbreiteter Distributionen zu vergleichen, um der Sache Gewicht zu geben. Am 30. Oktober hat Red Hat den Status für RHEL 8, 9, 10 und OpenShift 4 aktualisiert. Zuvor war es „fix deferred“ (markiert am 29. Oktober), jetzt ist es „affected“. Kein Veröffentlichungsdatum wurde mitgeteilt. Ubuntu gilt auf allen unterstützten Versionen (22.04, 24.04, 26.04, 26.10) noch als „in Bearbeitung“, ohne Datum. Ubuntu 16.04, 18.04 und 20.04 gelten als verwundbar, ohne dass überhaupt ein Fix aufgelistet ist. SUSE Linux Enterprise Server, von SP4 bis SP7 plus 16.0, befindet sich in derselben Lage. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 und Amazon Linux 2023 sind dagegen schon korrigiert. RHEL 7 ist nicht betroffen: Der verwundbare Codepfad wurde auf dieser Release nie ausgeliefert.
Ich sage das nicht, um Ubuntu oder RHEL schlechtzumachen. Es bleiben seriöse Distributionen mit robusten Sicherheitsprozessen. Ich sage es, weil bei diesem einzelnen Bug, in diesem Zeitfenster, die Fakten so sind: Wer sich auf Hosting mit Debian Stable verlässt, hat den Fix schon installiert. Auf anderen, stark genutzten Distributionen bleibt der Server dagegen für einen unbestimmten Zeitraum exponiert. Das ist ein konkreter, nachprüfbarer Vorteil, wenn man sich die Daten ansieht. Es ist keine Meinung über das Debian-Projekt im Allgemeinen.
Der (berichtete, nicht unabhängig verifizierte) Exploit von Anthropic
Der ungewöhnlichste Teil dieser Geschichte betrifft Anthropic, das Unternehmen, das den Bug als erstes über Xinyang Ge gemeldet hat. Laut Branchenberichten hat eines seiner internen KI-Modelle, nicht öffentlich veröffentlicht, selbstständig einen funktionierenden Root-Exploit gebaut. Ausgehend nur vom Patch und vom Report als Prompt. Der zweistufige Angriff würde so funktionieren. In der ersten Phase lässt die Race den Angreifer zusätzliche Bytes aus der Antwort des Kernels empfangen. Von dort gewinnt er eine Kernel-Adresse, um KASLR auszuhebeln. In der zweiten Phase würde derselbe Bug einen Buffer-Overflow verursachen. Er überschreibt einen Callback-Pointer mit der Adresse eines Payloads, den der Angreifer bereits im Kernel-Speicher platziert hat. Wenn der Kernel diesen Pointer aufruft, führt das Payload einen beliebigen Shell-Befehl als Root aus. Eine verlorene Race würde nur diesen einzelnen Verbindungsversuch scheitern lassen, ohne das System abstürzen zu lassen: Wiederholte Versuche wären also möglich. Im von Anthropic beschriebenen Test: 48 Minuten, um die Kernel-Adresse zu stehlen, weitere 5 Minuten bis zur Befehlsausführung.
Red Hat sagt, dass ein entfernter Angreifer, der einen exponierten TCP-Dienst erreicht, die Race generell auslösen kann. Der von Anthropic beschriebene Root-Exploit hätte jedoch gezielt Server mit einem aktiven Multipath-TCP-Listener angegriffen. Der Beitrag von Anthropic klärt nicht, ob ein Server ohne MPTCP genauso ausnutzbar ist. Weder der CVE-Eintrag noch der Upstream-Fix erwähnen MPTCP an irgendeiner Stelle. Es ist die Fachpresse, keine Primärquelle, die diesen Zusammenhang berichtet: Ich schreibe das deshalb mit der Skepsis, die es verdient, nicht als zu hundert Prozent gesicherte Tatsache. Anthropic hat weder den Exploit-Code veröffentlicht, noch die genaue verwendete Kernel-Version, noch die Konfiguration des Zielservers. Ein anderes Unternehmen, Innora, hat eine Root-Cause-Analyse veröffentlicht, mit einer QEMU-Reproduktionsumgebung. Es hat erklärt, kurzfristig keinen bewaffneten Exploit zu veröffentlichen. Derzeit gibt es keine Beweise für eine tatsächliche Ausnutzung durch Hersteller oder CERTs. Der Bug ist nicht im CISA-KEV-Katalog, laut der von CIRCL Luxemburg aktualisierten Kopie vom 28. Oktober.
Was jetzt auf deinen Servern zu tun ist
Kein Hersteller hat einen offiziell sanktionierten Workaround für diese Schwachstelle im Linux-Kernel veröffentlicht. Red Hat sagt ausdrücklich, dass keine der bisher kursierenden Maßnahmen seinem Standard an Deployment-Einfachheit und Stabilität entspricht. Die primäre Abmilderung bleibt, den korrigierten Kernel einzuspielen und neu zu starten, sobald der Patch für deine Distribution verfügbar ist. Auf Debian ist er das schon. Auf RHEL und Ubuntu noch nicht, zum Zeitpunkt, an dem ich das schreibe.
Als Verteidigung in der Tiefe, nicht als endgültige Lösung, ergeben einige Maßnahmen Sinn. Prüfen, dass net.ipv4.tcp_migrate_req auf 0 gesetzt ist. Kontrollieren, dass keine eBPF-Programme mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE geladen sind. Eine Filterung eingehender IPv4-Pakete mit Record-Route- oder Timestamp-Optionen erwägen. Abstürze überwachen, die ip_options_build, ip_build_and_send_pkt oder skb_under_panic zitieren. Ein Inventar eventuell exponierter MPTCP-Listener erstellen und vermeiden, sie ohne Grund erreichbar zu lassen. Wenn du auch Schutz gegen häufigere Angriffe auf Anwendungsebene verwaltest, findest du unter wie ich meine Server bis zum Patch für PHP2Shell abgesichert habe denselben Ansatz. Er lautet: abmildern, was möglich ist, während man auf den endgültigen Fix wartet, ohne Schutz zu versprechen, den es nicht gibt.
Für alle, die mich fragen, ob sie sofort aktualisieren sollen: Wenn du Debian Stable nutzt, ist der korrigierte Kernel schon in den Security-Repositories. Das Update ist einfach, und das Zeitfenster der Exposition ist schon geschlossen. Wenn du andere Distributionen nutzt, gibt es heute noch keinen Patch zu installieren. Es lohnt sich, die Advisories deines Herstellers in den nächsten Tagen genau zu verfolgen: Die Lage ändert sich schnell.
Quellen: The Hacker News, Debian Security Tracker und der Fix-Commit. Debian, Red Hat, Ubuntu und die anderen genannten Namen sind Marken ihrer jeweiligen Eigentümer.
Schreibe einen Kommentar