Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 30.10.2026 · 4 min Lesezeit

Linux-Kernel-TCP-Lücke CVE-2026-98432: Ubuntu und RHEL noch ohne Fix

Für CVE-2026-98432, eine Use-after-free-Lücke im IPv4-TCP-Verbindungsaufbau mit Kernel-CVSS 9.8, gibt es Fixes bei Debian, Oracle Linux, SUSE und Amazon Linux. Ubuntu und RHEL haben am 29. Oktober noch kein Paket. Anthropic beschreibt einen Root-Exploit über MPTCP-Listener.

Mit KI erstellt – redaktionelle Prüfung ausstehend

Abstrakte Netzwerkkugel mit gebrochenem Kern, daneben die Schlagzeile Linux-Kernel: TCP-Lücke

Für die Linux-Kernel-Lücke CVE-2026-98432 im IPv4-TCP-Verbindungsaufbau gibt es seit dem 29. Oktober ein deutlich gemischtes Bild: Debian, Oracle Linux, Teile von SUSE und Amazon Linux 2023 liefern korrigierte Kernel aus, Ubuntu und Red Hat Enterprise Linux dagegen noch nicht. Das Kernel-CVE-Team bewertet den Fehler mit CVSS 9.8, Anthropic hat dazu einen Exploit beschrieben, der auf Servern mit Multipath-TCP-Listener ohne Anmeldung Root-Befehle ausführt.

Betroffen sind Linux-Server mit verwundbarem Kernel, besonders solche mit Diensten, die MPTCP-Sockets öffnen. Systeme mit bereits eingespieltem Distributionsfix sind nach Neustart abgesichert, RHEL 7 ist laut Red Hat nicht betroffen. Wer Debian, Oracle Linux oder Amazon Linux 2023 betreibt, sollte das Kernel-Update zeitnah im nächsten Wartungsfenster samt Reboot einspielen. Auf Ubuntu und RHEL bleibt vorerst nur, die Angriffsfläche zu prüfen und zu verkleinern.

Was ist passiert?

Der Fehler ist eine Race Condition in tcp_v4_syn_recv_sock(): Verarbeitet eine zweite CPU gleichzeitig ein erneut gesendetes SYN für dieselbe Request-Socket, kann der Kernel beim Bau des SYNACK bereits freigegebenen Speicher lesen (Use-after-free). Ein ähnliches Problem besteht bei der Socket-Migration mit net.ipv4.tcp_migrate_req=1. Der Upstream-Fix gibt die IP-Optionen erst nach einer RCU-Wartezeit frei. IPv6 ist vom ersten Fall laut Kernel-Beschreibung nicht betroffen.

Anthropic schreibt am 27. Oktober, das eigene Modell habe einen Exploit erstellt, der zunächst KASLR aus der Ferne aushebelt und anschließend einen Callback-Zeiger überschreibt. Ein verlorenes Rennen bricht nur den Handshake ab, ohne das System abstürzen zu lassen. Im Proof of Concept dauerte das Auslesen eines Kernel-Zeigers 48 Minuten, die Codeausführung weitere fünf Minuten. Weder CVE-Eintrag noch Kernel-Fix erwähnen MPTCP, dieser Bezug stammt allein aus dem Anthropic-Beitrag.

Wer ist betroffen?

Laut The Hacker News (Stand 29. Oktober) gilt:

  • Ubuntu 22.04, 24.04, 26.04 und 26.10: Fix in Arbeit, ältere LTS-Versionen verwundbar, kein Paket.
  • RHEL 8, 9, 10 und OpenShift 4: Fix zurückgestellt, kein Paket. RHEL 7 nicht betroffen.
  • Amazon Linux 2023: kernel6.18 seit 24. Oktober (ALAS2023-2026-3251), kernel6.12 seit 29. Oktober mit 6.12.113-138.209 (ALAS2023-2026-3335). Das Standardpaket kernel und Amazon Linux 2 warten noch.
  • Debian trixie: linux 6.12.113-1 (DSA-6568-1). Debian 12: linux 6.1.190-1 (DLA-4841-1) und linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1).
  • Oracle Linux 7 bis 10 mit UEK: seit 16. Oktober gepatcht.
  • SUSE Linux Micro 6.2 und openSUSE Leap 16.0 gepatcht, SLES 15 SP4 bis SP7 und SLES 16.0 noch in Test oder Arbeit.

Wie kritisch ist das?

Die Bewertungen gehen weit auseinander. Das Kernel-CVE-Team vergibt 9.8, Red Hat 8.1 mit hoher Angriffskomplexität und auf der CVE-Seite nur Moderate, Amazon 7.0, Ubuntu stuft die Priorität als High ein. Red Hat beschreibt vor allem Abstürze und mögliche Speicherbeschädigung durch zeitlich abgestimmte Anfragen. Der Angriff läuft über das Netz ohne Zugangsdaten, braucht aber viele Versuche. Ob andere Wege als ein MPTCP-Listener ausnutzbar sind, ist öffentlich nicht belegt.

Was sollten Admins jetzt tun?

  • Inventar prüfen: laufenden Kernel mit uname -r erfassen und mit den Advisories der eigenen Distribution abgleichen.
  • Auf Debian, Oracle Linux, SUSE Micro, Leap 16.0 und Amazon Linux 2023 das Kernel-Update einspielen und neu starten.
  • Mit sysctl net.mptcp.enabled den MPTCP-Status lesen und mit ss -Mlnp nach lauschenden MPTCP-Sockets suchen.
  • Wo MPTCP nicht gebraucht wird, sysctl -w net.mptcp.enabled=0 setzen und dauerhaft in /etc/sysctl.d/ eintragen. Das verhindert neue MPTCP-Sockets, ersetzt aber den Kernel-Fix nicht.
  • net.ipv4.tcp_migrate_req auf 0 belassen, sofern die Migration nicht bewusst genutzt wird.
  • Dienste auf Ubuntu und RHEL per Firewall auf bekannte Quellnetze begrenzen und die Herstellerseiten täglich prüfen.

Einordnung für Unternehmen

Die Lücke ist nicht mit Fragnesia (CVE-2026-46300) zu verwechseln: Fragnesia setzte lokalen Zugriff voraus, CVE-2026-98432 ist aus der Ferne erreichbar. Heikel ist der Zeitversatz: Upstream und mehrere Distributionen sind seit Mitte Oktober gepatcht, der Fix ist öffentlich nachvollziehbar, während die verbreiteten Enterprise-Plattformen Ubuntu und RHEL noch ohne Paket dastehen. Für diese Systeme zählen bis dahin Netzsegmentierung, ein deaktiviertes MPTCP und eine vorbereitete Reboot-Planung, damit das Update am Tag der Veröffentlichung eingespielt werden kann.

Passende Anleitungen auf S-EDV

Quellen

LinuxKernelCVE-2026-98432TCPMPTCPUbuntuRHELDebianPatch-Management