Dieselbe Lücke, drei völlig verschiedene Noten: Das Kernel-Team bewertet CVE-2026-98432 mit 9,8 von 10. Red Hat nannte erst 5,9, setzte die Lücke am 29. Oktober aber auf 8,1. Und bei zwei großen Distributionen fehlt noch immer der Patch. The Hacker News hat die Lage am 29. Oktober zusammengetragen.
Wichtig vorab: Bisher sind keine Angriffe bekannt. Die Lücke steht laut dem Bericht nicht im KEV-Katalog der US-Behörde CISA. Trotzdem lohnt sich ein Blick auf deine Server.
WAS IST KAPUTT?
Der Fehler sitzt in dem Kernel-Code, der neue IPv4-TCP-Verbindungen aufbaut. Beim Handschlag zwischen Client und Server merkt sich der Kernel die IP-Optionen der Anfrage. Wenn die Verbindung fertig ist, reicht er diese Optionen an den neuen Socket weiter, ohne sie zu kopieren.
Wird dieser Socket zerstört, während eine andere CPU die Optionen noch braucht, um eine wiederholte Verbindungsanfrage zu beantworten, liest der Kernel freigegebenen Speicher. Das nennt man Use-after-free. Die Lücke steckt seit Linux 4.4 im Code. IPv6 ist nicht betroffen, weil der Kernel dort die Optionen kopiert.
Die Korrektur ist einfach: Der Kernel wartet jetzt, bis alle anderen CPUs mit dem Lesen fertig sind, bevor er den Speicher freigibt. Sie wurde laut Bericht am 5. Oktober eingespielt, rund zehn Tage vor der Veröffentlichung der CVE.
WARUM DIE NOTE SO STARK SCHWANKT
Die Bewertungen gehen weit auseinander. Das liegt vor allem an der Frage, wie schwer der Angriff wirklich ist.
- Kernel-CVE-Team: 9,8. Es setzt IPv4-Optionen wie Record Route oder Timestamp und geringe Angriffskomplexität voraus.
- Red Hat (CVE-Seite): 5,9, „Moderate“. Das Rennen sei schwer zu gewinnen, wahrscheinlich ende es in einem Absturz. Auswirkungen auf Vertraulichkeit oder Integrität seien nicht gezeigt.
- Red Hat (Advisory-Datei): 8,1, „Important“, aktualisiert am 29. Oktober.
- Oracle und SUSE: 8,1, gleicher Vektor, aber hohe statt niedriger Angriffskomplexität.
- Amazon: 7,0.
- NVD: Stand 28. Oktober noch keine eigene Wertung.
Der Unterschied zwischen 9,8 und 8,1 liegt allein in der Angriffskomplexität. Für dich heißt das: Die Zahl ist weniger wichtig als der Patch-Stand deiner Distribution.
WO IST SCHON GEPATCHT?
Der Stand vom 29. Oktober laut Bericht:
- Debian: trixie ist seit 16. Oktober gefixt (linux 6.12.113-1). Bookworm folgte am 17. und 22. Oktober.
- Oracle Linux 7 bis 10 (UEK): gefixt seit 16. Oktober.
- Amazon Linux 2023: kernel6.18 seit 24. Oktober, kernel6.12 seit 29. Oktober gefixt.
- SUSE: Linux Micro 6.2 und openSUSE Leap 16.0 sind gefixt. SLES 15 SP4 bis SP6 LTSS und SLES 16.0 sind in Tests, SLES 15 SP7 ist in Arbeit.
- Ubuntu 22.04, 24.04, 26.04, 26.10: hohe Priorität, Arbeit läuft, kein Fix veröffentlicht. Ubuntu 16.04, 18.04 und 20.04 sind verwundbar, ebenfalls ohne Fix.
- RHEL 8, 9, 10 und OpenShift 4: Fix auf ein künftiges Update verschoben, ohne Termin. RHEL 7 ist nicht betroffen.
Upstream steckt der Fix in den Kernel-Versionen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Das Kernel-Team rät, auf den neuesten stabilen Kernel zu gehen, und unterstützt kein einzelnes Cherry-Picking.
DIE ANTHROPIC-VERBINDUNG
Ins Rampenlicht geriet die Lücke durch Anthropic. Das Unternehmen erklärte am 27. Oktober, sein KI-Modell habe nach „initial prompting“ einen funktionierenden Exploit geschrieben. Der Fix nennt Anthropic-Forscher Xinyang Ge als Melder. Wir haben in der Meldung über die Exploit-Ketten schon kurz darüber berichtet.
Laut dem Bericht erlaubt der Exploit einem Angreifer ohne Zugangsdaten, Befehle als Root auszuführen, wenn auf dem Server ein Multipath-TCP-Listener (MPTCP) läuft. In zwei Schritten:
- Das Rennen sorgt dafür, dass der Kernel zusätzliche Bytes zurückschickt. Steckt eine Kerneladresse darin, ist KASLR ausgehebelt.
- Derselbe Fehler überschreibt einen Callback-Zeiger. Der Kernel ruft dann vorbereiteten Code als Root auf.
Ein verlorenes Rennen scheitert nur an diesem Verbindungsversuch und stürzt das System nicht ab, der Angreifer kann also wiederholen. In Anthropics Test dauerte es etwa 48 Minuten, bis eine Kerneladresse offen lag, und weitere 5 Minuten bis zur Befehlsausführung. Exploit-Code, Kernel-Version und Konfiguration sind nicht veröffentlicht.
Offen bleibt: Red Hat sagt, jeder erreichbare TCP-Dienst könne das Rennen auslösen. Ob Server ohne MPTCP-Listener genauso kompromittierbar sind, sagt der Anthropic-Beitrag nicht. Dass der Angriff über MPTCP läuft, steht nur dort, nicht im CVE-Eintrag oder im Kernel-Fix.
WAS DU JETZT TUN SOLLTEST
- Kernel-Version prüfen:
uname -r. Liegt sie unter dem fixierten Stand deiner Reihe, bist du betroffen. - Debian, Oracle, Amazon, SUSE-Teile: Updates einspielen und neu starten.
- Ubuntu und RHEL: Security-Tracker im Auge behalten und sofort patchen, sobald der Kernel erscheint.
- Bis dahin: Nur nötige Ports öffnen, Firewall-Regeln straffen. Red Hat sagt, es gebe keine Abhilfe, die den eigenen Ansprüchen genügt.
- MPTCP: Ob das Abschalten von MPTCP oder das Blockieren von Anfragen mit IP-Optionen das Risiko senkt, sagen weder die Advisories noch Anthropic.
FAZIT: Kein Panik-Fall, aber ein Patch-Fall
Es gibt keine bekannten Angriffe, die Lücke braucht ein gewonnenes Rennen, und IPv6 bleibt verschont. Doch ein Root-Exploit aus dem Labor und fehlende Fixes bei Ubuntu und RHEL sind ein klares Signal. Wer Ubuntu oder RHEL im Netz betreibt, sollte die Updates ab sofort täglich prüfen.