Ein Verbindungsaufbau mit ungewöhnlichen Optionen im IP-Header genügt, um den Linux-Kernel auf bereits freigegebenen Speicher zugreifen zu lassen. Die Schwachstelle CVE-2026-98432 steckt im Code für eingehende IPv4-TCP-Verbindungen und reicht bis Linux 4.4 zurück. Das CVE-Team des Kernels bewertet sie mit 9,8 von 10 Punkten: Angreifer brauchen weder Zugangsdaten noch die Mitwirkung eines Nutzers, nur einen erreichbaren TCP-Port. Damit betrifft die Lücke potenziell nicht nur Server, sondern auch Router, NAS-Systeme und Einplatinenrechner mit Linux – also genau die Geräte, die in vielen Heimnetzen und Homelabs laufen.

Die Korrektur landete laut Akamai bereits am 5. Oktober im Kernel, am 15. Oktober folgte die CVE-Nummer. Breite Aufmerksamkeit bekam die Lücke aber erst, als Anthropic am 27. Oktober beschrieb, wie sich daraus ein Root-Exploit bauen lässt. Seitdem ziehen Distributionen und Hersteller nach – unterschiedlich schnell.

Wie die Lücke funktioniert

Enthält ein SYN-Paket IPv4-Optionen, speichert der Kernel diese, um sie in seiner Antwort, dem SYN-ACK, zurückzuschicken. Ist der Handshake abgeschlossen, übergibt er die Optionen ohne Kopie an den neuen Socket. Schickt der Client sein SYN erneut, kann ein anderer Prozessorkern gleichzeitig ein SYN-ACK aus denselben Optionen bauen – während der neue Socket samt Optionen womöglich schon freigegeben ist. Ein ähnliches Problem besteht, wenn die Migration von TCP-Request-Sockets aktiv ist (net.ipv4.tcp_migrate_req, standardmäßig aus). IPv6 ist vom Hauptproblem nicht betroffen. Der Fix von Eric Dumazet gibt den Speicher erst nach einer RCU-Wartezeit frei; er steckt in den Kernelversionen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3.

Anthropics Frontier Red Team schreibt, das KI-Modell Claude habe nach anfänglichen Vorgaben einen Exploit verfasst, mit dem ein entfernter Angreifer auf Linux-Servern mit einem Multipath-TCP-Listener (MPTCP) Befehle als root ausführen kann. Im ersten Schritt verrät ein fehlerhafter Lesezugriff Kernel-Adressen und hebelt so die Speicherrandomisierung KASLR aus, im zweiten überschreibt der Angriff einen Funktionszeiger. Ein verlorenes Wettrennen lässt laut Anthropic nur den Handshake scheitern, ohne das System abstürzen zu lassen; der Angreifer kann es also beliebig oft versuchen. Im Proof of Concept dauerte das Auslesen eines Kernel-Zeigers 48 Minuten, die Befehlsausführung weitere fünf. Veröffentlicht hat Anthropic den Exploit nicht. Berichte über Angriffe gibt es bislang nicht, im Katalog aktiv ausgenutzter Schwachstellen der US-Behörde CISA fehlt die Lücke (Stand 4. November).

Die MPTCP-Bedingung ist nur ein schwacher Trost. Das Go-Sicherheitsteam weist darauf hin, dass Go-Programme seit Go 1.24 unter Linux für lauschende Sockets standardmäßig MPTCP aktivieren, sofern der Kernel es zulässt; AlmaLinux etwa schaltet MPTCP ab Werk ab. Vor allem aber betont das Team, dass der eigentliche Fehler nicht MPTCP-spezifisch ist und auch Systeme ohne MPTCP-Listener angreifbar sein könnten.

Router: MikroTik liefert, andere schweigen

Bei Routern kommt es darauf an, ob ein TCP-Dienst auf dem Gerät selbst für Angreifer erreichbar ist. MikroTik erklärt in seinem Hinweis vom 3. November, dass nur Verkehr an TCP-Dienste des Routers die Lücke auslöst, nicht aber weitergeleiteter Verkehr. Mit der Standard-Firewall sei kein Zugriff aus dem WAN möglich; gefährdet seien Geräte, deren Verwaltungs- oder andere TCP-Dienste aus nicht vertrauenswürdigen Netzen erreichbar sind. Betroffen ist RouterOS 7, behoben ist der Fehler in 7.25.1 (Stable), 7.24.6 (Long-Term) und 7.26beta5. RouterOS 6 ist laut MikroTik nicht betroffen.

Bei OpenWrt enthält die aktuelle Version 25.12.6 vom 18. Oktober noch Kernel 6.12.112 und damit nicht den Fix. Im Entwicklungszweig openwrt-25.12 ist seit dem 31. Oktober Kernel 6.12.113 eingepflegt, ein Service-Release damit stand zum Redaktionsschluss noch aus. Ubiquiti hat die Lücke nach Angaben von Hardwareluxx für Dream Machines, Dream Router und Cloud Gateways mit UniFi OS 5.1.35 geschlossen. FRITZ! (ehemals AVM) hat auf seiner Seite zu aktuellen Sicherheitsthemen bislang keinen Hinweis zu CVE-2026-98432 veröffentlicht. Firewall-Systeme wie pfSense und OPNsense basieren auf FreeBSD und nutzen den betroffenen Linux-Kernel nicht.

Symbolbild: Raspberry Pi 4 im Kühlgehäuse auf einem Acht-Port-Netzwerk-Switch mit gelben und grauen Netzwerkkabeln

Symbolbild: Raspberry Pi 4 auf einem Netzwerk-Switch. Auch Einplatinenrechner mit Linux brauchen einen aktuellen Kernel. Bild: RAIL P (RAIL.PHOTOGRAPHY) / Wikimedia Commons, CC0

Server und Homelab: Patches fast überall verfügbar

Die großen Server-Distributionen haben reagiert. Debian 13 „Trixie“ erhielt den Fix mit Kernel 6.12.113-1 bereits am 16. Oktober (DSA-6568-1), für Debian 12 „Bookworm“ steht Version 6.1.190-1 bereit. Red Hat hat am 1. November korrigierte Kernel für RHEL 8, 9 und 10 veröffentlicht, AlmaLinux verteilt seine Kernel seit dem 2. November über die regulären Repositorys. Ubuntu stuft die Lücke als kritisch ein, die Kernel-Updates für 22.04, 24.04 und 26.04 standen laut Ubuntus CVE-Seite am 5. November aber noch auf „pending“, waren also noch nicht regulär verteilt; das gilt auch für die Raspberry-Pi-Kernel. Für Ubuntu 20.04 und 18.04 fehlt ein Fix noch.

Was du jetzt tun solltest

  • Kernel aktualisieren und neu starten: Erst nach dem Neustart läuft der korrigierte Kernel. Prüfe die laufende Version mit uname -r und vergleiche sie mit den Angaben deiner Distribution.
  • Router-Firmware prüfen: Spiele verfügbare Updates ein, bei MikroTik mindestens RouterOS 7.25.1 beziehungsweise 7.24.6.
  • Angriffsfläche verkleinern: Schalte Fernzugriffe auf Weboberflächen und SSH aus dem Internet ab, wo du sie nicht brauchst, und prüfe Portfreigaben auf Linux-Server im Heimnetz. MikroTik empfiehlt für den Fernzugriff ein VPN wie WireGuard statt offener Verwaltungsports.
  • Übergangslösung für Linux-Hosts: Wer noch nicht neu starten kann, verwirft eingehende IPv4-TCP-Pakete mit IP-Optionen. Normaler Verkehr nutzt solche Optionen laut AlmaLinux fast nie.
# Laufenden Kernel und MPTCP-Status prüfen
uname -r
sysctl net.mptcp.enabled
sudo ss -lnMp    # lauschende MPTCP-Sockets anzeigen

# Übergangsregel nach AlmaLinux: verwirft IPv4-TCP-Pakete mit IP-Optionen
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -300; policy accept;
    meta l4proto tcp ip hdrlength > 5 counter drop
  }
}
EOF

Die Regel überlebt keinen Neustart und lässt sich mit sudo nft delete table ip cve_2026_98432 wieder entfernen. Sie schützt den Host und Container, deren Verkehr über ihn läuft; Verkehr zwischen Containern auf demselben Host kann sie umgehen. Auf Systemen, die Verkehr weiterleiten, verwirft sie auch durchgeleitete Pakete mit IP-Optionen. MPTCP allein abzuschalten genügt laut Akamai nicht, es senkt lediglich die Wahrscheinlichkeit, die Race Condition auszulösen. Vollständigen Schutz bietet nur ein gepatchter Kernel.

Quellen

Bildnachweis