CVE-2026-98432: Überprüfen Sie Ihren Ubuntu VPS und reduzieren Sie die Belastung

#Update am 3 November 2026

Am 3 November haben wir den offiziellen Ubuntu-Fix auf beiden VPS-Instanzen installiert. Sie führen jetzt den Kernel 7.0.0-43-generic aus, nachdem sie neu gestartet und den neuen SSH-Zugriff, HTTPS-Sites und die getesteten Anwendungen überprüft haben. Diese Pakete stammen von -proposed: Dies bedeutet nicht, dass Ubuntu die allgemeine Qualifikation oder den Vertrieb über die stabilen Kanäle abgeschlossen hat. Eine externe Abhängigkeit bleibt nicht verfügbar; Die vollständige Wiederherstellung der Anwendung muss noch überprüft werden.

In den folgenden Abschnitten wird der Bericht über unsere Schadensbegrenzung im Oktober 30 zusammengestellt. Im November-Follow-up von 3 werden die gezielte Installation, die Überprüfungen nach dem Neustart und der Unterschied zwischen den vier Tagen von unserer Schadensbegrenzung bis zur Installation des Fixes und den neunzehn Tagen seit der Veröffentlichung des Eintrags von Ubuntu detailliert beschrieben.

Lesen Sie das November-Follow-up vom 3 und die beiden VPS-Ergebnisse

Lesen Sie die November-Ankündigung von Ubuntu für 2

Überprüfen Sie den aktuellen Ubuntu-Status

#Überprüfen Sie zunächst Ihren VPS

Diese Befehle identifizieren den laufenden Kernel, die Distribution, zwei Netzwerkeinstellungen und überwachende MPTCP-Sockets. Sie ändern die Konfiguration nicht. Wenn Ihre SS-Version keine MPTCP-Unterstützung bietet, bedeutet ein Fehler nicht, dass der Server geschützt ist.

Vergleichen Sie die Ergebnisse mit dem Sicherheits-Tracker Ihrer Distribution. Eine aus einem Social-Media-Beitrag kopierte Kernel-Version reicht nicht aus: Distributionen können Korrekturen in ihre eigenen Pakete zurückportieren. Ein installiertes Paket ist auch nicht unbedingt der aktuell ausgeführte Kernel.

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -p

#Was wir an unseren beiden VPS-Instanzen geändert haben

Am 30 Oktober haben wir unsere beiden Ubuntu VPS-Instanzen geprüft und gezielte temporäre Maßnahmen ergriffen. Wir haben einen dedizierten Filter für IPv4 TCP-Pakete mit IP-Optionen hinzugefügt und die Erstellung von MPTCP-Sockets in den relevanten Netzwerk-Namespaces deaktiviert.

Ein Caddy-Dienst hatte einen kontrollierten Neustart, um seine Sockets mit der angepassten Einstellung neu zu erstellen. Die fünf vorhandenen Container behielten ihre Prozesse und Startzeiten. Anschließend überprüften wir neue SSH-Verbindungen und erhielten HTTPS 200 Antworten von allen sieben von uns getesteten Websites.

Wir haben weder das Betriebssystem aktualisiert noch einen VPS neu gestartet. Diese Ergebnisse beschreiben unsere Kontrollen nach dem Eingriff; Sie beweisen nicht, dass jeder mögliche Ausbeutungsweg blockiert ist.

#Filtern Sie IP-Optionen mit einem separaten Regelsatz

Dies ist die Struktur unseres Filters anhand eines Beispieltabellennamens. Die erste Regel schränkt die Protokollierung ein; Der zweite verwirft jedes passende Paket, auch wenn dieses Limit erreicht ist. IP-Optionen unterscheiden sich von gewöhnlichen TCP-Optionen wie MSS oder SACK.

Betrachten Sie dies als Beispiel, das Sie überprüfen und in Ihre bestehende Firewall integrieren können, mit Wiederherstellungszugriff und einem bereichsbezogenen Rollback. Ersetzen Sie nicht Ihre gesamte Konfiguration. Überprüfen Sie alle speziellen Netzwerkanforderungen, einschließlich der für die Sicherheitskennzeichnung verwendeten IP-Optionen.

Dieser Filter zielt auf IPv4. Wir bezeichnen es als Expositionsreduzierung, ohne eine Garantie dafür, dass es die Schwachstelle vollständig abdeckt.

table inet cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

#Deaktivieren Sie MPTCP, wenn Sie es nicht verwenden

Wenn Ihre Dienste kein MPTCP benötigen, verhindert diese Einstellung neue MPTCP-Sockets im aktuellen Netzwerk-Namespace. Bereits geöffnete Sockets werden nicht geschlossen. Überprüfen Sie die Sockets erneut und planen Sie Neustarts nur für die betroffenen Dienste.

Um diese Einstellung beim Booten beizubehalten, fügen Sie net.mptcp.enabled = 0 zu einer dedizierten sysctl.d-Datei hinzu, nachdem Sie die vorhandenen Einstellungen überprüft haben. Die Persistenz sollte dann bei einem geplanten Neustart getestet werden.

sudo sysctl -w net.mptcp.enabled=0

#Überprüfen Sie auch die in Go geschriebenen Dienste

Go 1.24 aktiviert MPTCP standardmäßig für ListenConfig auf unterstützten Systemen. Ein in Go geschriebener Reverse-Proxy verdient daher eine Überprüfung, auch wenn Ihre Anwendung Node.js verwendet.

Die folgende Einstellung ändert diesen Standardwert, wenn er in der Serviceumgebung bereitgestellt wird. Behalten Sie alle anderen GODEBUG-Werte bei und erstellen Sie die Sockets des betroffenen Prozesses neu. Wir haben es für Caddy verwendet; Es ersetzt keinen Kernel-Fix.

GODEBUG=multipathtcp=0

#Docker: Die Host-Einstellung ist nur ein Teil der Prüfung

Die MPTCP-Einstellung gehört zu jedem Netzwerk-Namespace. Ein Nullwert auf dem Host stellt daher nicht sicher, dass jeder Container die gleiche Konfiguration hat.

Wir haben die vorhandenen Namespaces überprüft und eine regelmäßige Überprüfung auf neue hinzugefügt. Ein Test mit einem nach der Aktivierung erstellten Namespace bestätigte, dass er verarbeitet wurde. Diese Überprüfung findet regelmäßig statt, daher gibt es eine Verzögerung, bevor sie angewendet wird. Dies ist einer der Gründe, warum wir auch weiterhin am Eingang des Hosts filtern.

Einige zuvor geöffnete interne Container-Sockets können bestehen bleiben. Wir haben diese Sockets von öffentlichen Listenern unterschieden, anstatt eine Systemeinstellung als Beweis dafür zu betrachten, dass jeder Socket verschwunden war.

#Wie wir die Schadensbegrenzung überprüft haben

Wir haben überprüft, ob der Filter geladen war, seine Zähler überprüft und die MPTCP-Einstellungen und Listener überprüft. Ein Nicht-Exploit-Diagnosepaket bestätigte, dass die Drop-Regel erreicht wurde. Wir haben keinen Exploit-Code ausgeführt.

Außerdem haben wir eine neue SSH-Verbindung geöffnet und die Seiten extern überprüft. Bestehende Firewall-Regeln blieben erhalten. Persistenzmechanismen wurden konfiguriert und neu geladen, aber wir haben sie nach einem vollständigen VPS-Neustart nicht getestet.

Ein ansteigender Zähler stellt fest, dass ein Paket einer Regel entsprach. Es beweist weder einen Einbruchsversuch noch einen vollständigen Schutz: Unsere eigenen Diagnoseprüfungen können ihn auch erhöhen.

#Als nächstes: Booten Sie einen gepatchten Kernel

Der offizielle Fix Ihrer Distribution hat weiterhin Priorität. Wenn es für Ihr System verfügbar ist, planen Sie seine Installation und den erforderlichen Neustart und überprüfen Sie dann den tatsächlich ausgeführten Kernel mit uname -r. Entscheiden Sie anhand des offiziellen Status und der Anforderungen Ihrer Dienste, ob vorübergehende Maßnahmen aufgehoben werden sollen.

Diese Arbeit betrifft die Linux-Infrastruktur, die Ihre Anwendungen hostet. Ein npm-Update auf PRNext kann keinen VPS-Kernel patchen. Selbsthosting bedeutet auch, dieser Schicht des Systems zu folgen und Änderungen mit echten Diensten zu vergleichen.

Lesen Sie weiter: Bereitstellen einer Anwendung auf einem VPS