CVE-2026-98432 ist eine Lücke in der Art, wie der Linux-Kernel TCP-Verbindungsanfragen annimmt. Sie erlaubt einem entfernten Angreifer ohne Passwort, den Server abstürzen zu lassen oder den Kernel-Speicher zu beschädigen. Das CVE-Team des Linux-Kernels bewertet sie mit 9,8 von 10, und Anthropic gibt an, dass sein Modell Claude einen Exploit geschrieben hat, der einem Angreifer Root-Rechte auf Servern verschafft, die MPTCP-Verbindungen annehmen. Der Fix steckt im Upstream-Kernel und Debian hat ihn ausgeliefert, doch am 30. Oktober 2026 führt Ubuntu ihn für 22.04, 24.04 und 26.04 als "work in progress" (in Arbeit), und Red Hat führt RHEL 8, 9 und 10 als betroffen und ohne Update. Bis das Update kommt: Schalten Sie MPTCP ab, wenn Sie es nicht brauchen, blockieren Sie IPv4-Pakete mit IP-Optionen, schränken Sie ein, wer Ihre Server erreichen kann, und planen Sie den Neustart ein.

Was ist CVE-2026-98432, und warum betrifft sie Ihr Unternehmen?

Laut dem offiziellen CVE-Eintrag sitzt die Lücke in dem Moment, in dem ein IPv4-TCP-Handshake abgeschlossen wird: Der Kernel übergibt die mit der Verbindungsanfrage gespeicherten IP-Optionen an die neue Verbindung, ohne sie zu kopieren, während eine andere CPU im selben Moment eine doppelte Anfrage verarbeiten und aus diesen Optionen eine Antwort bauen kann. Gibt der Kernel den Speicher zuerst frei, liest er ihn danach trotzdem, ein Fehler, der als Use-after-free bekannt ist. Die Lücke existiert seit Kernel 4.4. Das CVE-Team des Kernels hat sie am 15. Oktober 2026 veröffentlicht und mit 9,8 von 10 bewertet, weil sie über das Netzwerk erreichbar ist, während des Handshakes und vor jeder Anmeldung, ohne Zutun eines Nutzers.

In einem Beitrag vom 27. Oktober schrieb Anthropic, Claude habe einen Exploit geschrieben, mit dem ein entfernter Angreifer ohne Zugangsdaten Befehle als Root auf Linux-Servern ausführen kann, die MPTCP-Verbindungen (Multipath TCP) annehmen. In seinem Test brauchte der Exploit 48 Minuten, um eine Adresse aus dem Kernel-Speicher abzugreifen, und dann 5 Minuten bis zur Befehlsausführung. Schlimmer noch: Ein fehlgeschlagener Versuch lässt den Server nicht abstürzen, nur diese eine Verbindung scheitert, sodass ein Angreifer es immer wieder versuchen kann, ohne dass es jemand bemerkt. Den Exploit selbst hat Anthropic nicht veröffentlicht.

Red Hat beschreibt die Hauptfolge als Serverabsturz und Denial of Service, mit möglicher Speicherbeschädigung. In der Ausgabe vom 30. Oktober des CISA-Katalogs bekannter ausgenutzter Schwachstellen war die Lücke noch nicht aufgeführt.

Ist ein Update schon bei Ihrer Distribution angekommen?

So sah der Stand auf der offiziellen Seite jeder Distribution am 30. Oktober 2026 aus:

DistributionStand
Ubuntu 22.04, 24.04, 26.04 und 26.10Verwundbar, Fix "work in progress" (in Arbeit); für 24.04 im Kernel 6.8.0-149 (Ubuntu-Seite)
Ubuntu 16.04, 18.04 und 20.04Verwundbar
Red Hat Enterprise Linux 8, 9 und 10Betroffen, kein Update veröffentlicht (Red-Hat-Seite)
Red Hat Enterprise Linux 6 und 7Nicht betroffen
Debian 12 und 13Behoben in 6.1.190-1 und 6.12.113-1 (Debian-Tracker)

Im Upstream-Kernel kam der Fix mit den 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. Die meisten Server laufen aber mit dem Kernel ihrer Distribution, entscheidend ist also die Seite Ihrer Distribution, nicht die Upstream-Versionsnummer.

Woran erkennen Sie, ob ein Server angreifbar ist?

Führen Sie diese Befehle auf jedem Linux-Server aus, der Verbindungen aus dem Internet annimmt:

uname -r
cat /proc/sys/net/mptcp/enabled
ss -Mln
cat /proc/sys/net/ipv4/tcp_migrate_req
  • Der erste zeigt die Kernel-Version; vergleichen Sie sie mit der Seite Ihrer Distribution. Unter Ubuntu 24.04 zum Beispiel ist jede heute verfügbare Version noch ungepatcht.
  • Ein Wert von 1 beim zweiten bedeutet, dass MPTCP aktiviert ist, laut der Kernel-Dokumentation die Standardeinstellung.
  • Der dritte listet die Dienste auf, die MPTCP-Verbindungen annehmen. Jeder Dienst, der dort erscheint, ist die Art von Ziel, die Anthropic ausgenutzt hat. Achten Sie auf Go-Programme: Laut den Versionshinweisen zu Go 1.24 nutzen ihre Listener jetzt standardmäßig MPTCP, wo es unterstützt wird.
  • Der vierte sollte 0 ausgeben; laut CVE-Eintrag funktioniert der zweite Weg der Lücke nur, wenn der Wert 1 ist.

Die vorübergehende Lösung, bis das Update kommt: 5 Schritte

  1. Wenn Ihre Distribution den Fix schon hat, installieren Sie ihn jetzt und starten Sie neu. Unter Debian 12 und 13 zum Beispiel: 
    sudo apt update && sudo apt upgrade
sudo reboot
    Der neue Kernel schützt Sie erst, wenn der Server tatsächlich mit ihm läuft.
  2. Schalten Sie MPTCP ab, wenn kein Dienst es braucht. Damit schließen Sie die Art von Ziel, die Anthropic ausgenutzt hat: 
    sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
    Der erste Befehl wendet die Einstellung sofort an, der zweite erhält sie über einen Neustart hinweg. Laut Kernel-Dokumentation gilt die Einstellung pro Netzwerk-Namespace, wenden Sie sie also auch in Containern an. Go-Programme fallen automatisch auf normales TCP zurück, wenn MPTCP nicht verfügbar ist. Weder Anthropic noch eine Distribution sagt jedoch, dass das Abschalten die Lücke selbst beseitigt, es verkleinert also das Risiko, statt es zu beheben.
  3. Blockieren Sie TCP-Pakete mit IPv4-Optionen. Das Bewertungsszenario im CVE-Eintrag geht von einem Angreifer aus, der eine Verbindungsanfrage mit der IPv4-Option Record Route oder Timestamp sendet, und normaler Web-, Mail- und SSH-Verkehr braucht diese Optionen nicht. Bitten Sie Ihren Netzwerkadministrator um eine Firewall-Regel, die eingehende TCP-Pakete verwirft, deren IPv4-Header länger als 20 Bytes ist, und testen Sie sie zuerst auf einem Server. Keine Distribution sagt, dass dies die Lücke blockiert, aber es entfernt die Bedingung, von der die Bewertung ausgeht.
  4. Schränken Sie ein, wer Ihre Server erreichen kann. Die Lücke braucht einen offenen TCP-Port, der Verbindungen annimmt. Schließen Sie also jeden Port, den Sie nicht brauchen, und machen Sie SSH und Admin-Oberflächen nur von bestimmten IP-Adressen oder über ein VPN erreichbar. Steht die Website hinter einem Vermittler wie einem CDN, lassen Sie den Ursprungsserver nur Verbindungen von den Adressen dieses Dienstes annehmen.
  5. Bereiten Sie das Update vor, bevor es da ist. Verfolgen Sie die Seiten von Ubuntu und Red Hat zu dieser CVE, genehmigen Sie das Kernel-Update vorab und legen Sie ein Neustart-Fenster fest, damit der Fix am Tag seines Erscheinens eingespielt wird. Beobachten Sie das Kernel-Log auf Abstürze, die ip_options_build erwähnen: 
    sudo journalctl -k | grep -i ip_options_build
    Ein ruhiges Log heißt allerdings nicht, dass Sie sicher sind, denn ein fehlgeschlagener Versuch lässt den Server nicht abstürzen.

Und wenn Ihre Server bei einem Hosting-Anbieter stehen?

Bei Shared Hosting und verwalteten Diensten gehört der Kernel dem Anbieter, nicht Ihnen. Stellen Sie drei Fragen: welche Distribution und welche Kernel-Version seine Server nutzen, wann er den Fix einspielt und was er bis dahin tut, um das Risiko zu senken. Bei einem virtuellen privaten Server (VPS) liegt der Kernel meist in Ihrer Hand, wenden Sie die obigen Schritte also selbst an.

Die Sicht von Origami

Wie in unserem Artikel über PHP-Sicherheitslücken gilt: Wenn sich das offizielle Update verspätet, sind es die vorübergehenden Schritte, die Server in den ersten Tagen schützen. Sie verkleinern allerdings nur das Risiko; die einzige Heilung ist der gepatchte Kernel nach einem Neustart. Bei Origami können wir Ihre Linux-Server prüfen, die vorübergehenden Schritte ohne Unterbrechung Ihrer Dienste umsetzen und den Fix einspielen, sobald er erscheint. Kontaktieren Sie uns.

Das Wichtigste in Kürze

  • CVE-2026-98432 ist eine Lücke im Linux-Kernel, vom Kernel-Team mit 9,8 von 10 bewertet, über die ein Server während des TCP-Handshakes aus der Ferne angegriffen werden kann, vor jeder Anmeldung.
  • Debian hat den Fix ausgeliefert, Ubuntu und Red Hat hatten das am 30. Oktober 2026 noch nicht getan.
  • Bis es so weit ist: Schalten Sie MPTCP ab, wenn Sie es nicht brauchen, blockieren Sie TCP-Pakete mit IPv4-Optionen und schließen Sie ungenutzte Ports.
  • Installieren Sie den gepatchten Kernel, sobald er erscheint, und starten Sie neu; die vorübergehenden Schritte ersetzen ihn nicht.

Quellen