PRNextNeunzehn Tage sind vergangen, seit Ubuntu am 15 Oktober seinen CVE-2026-98432-Eintrag veröffentlicht hat. Für ein Team, das internetbasierte Dienste betreibt, ist diese Wartezeit zu lang und besorgniserregend.
Unsere eigene Intervention begann am 30 Oktober mit vorübergehenden Maßnahmen. Am 3 November, vier Tage später, installierten wir den offiziellen Fix auf beiden VPS-Instanzen und überprüften, ob sie im Kernel 7.0.0-43-generic gebootet hatten.
Diese Ubuntu-Pakete stammen aus der vorgeschlagenen Testtasche. Die angekündigte allgemeine Qualifizierung von Ubuntu ist noch im Gange: Unsere verifizierte Installation verwandelt diese Pakete nicht in ein Update, das bereits über die üblichen stabilen Kanäle verteilt wird.
Eine Anwendung antwortet weiterhin. Seine Zertifikate sind gültig. Bereitstellungen sind erfolgreich. Keines dieser Ergebnisse weist darauf hin, dass ein Fehler im Kernel, der Netzwerkverbindungen empfängt, behoben wurde. Ein Dienst kann völlig normal aussehen, während die Sicherheitsreaktion noch nicht abgeschlossen ist.
Für einen Administrator bedeutet jeder zusätzliche Tag, eine Zwischenentscheidung zu treffen, Ankündigungen zu befolgen und einen Eingriff vorzubereiten. Dieser Zeitraum ist unser Anliegen. Es unterstützt weder einen unbegründeten Vorwurf der Fahrlässigkeit noch die Möglichkeit, dass eine vorübergehende Maßnahme durch Vernachlässigung dauerhaft wird.
Die am 2 November veröffentlichte Ubuntu-Ankündigung beschreibt Korrekturen im vorgeschlagenen Test-Pocket für mehrere unterstützte Versionen. Für Ubuntu 26.04 LTS und das Linux-Paket wird die Version 7.0.0-43.43. genannt. In der Ankündigung heißt es, dass die Veröffentlichung in -updates nach Tests erfolgt, ohne dass ein festes Datum angegeben wird.
Das ändert die Art und Weise, wie die Situation beschrieben werden sollte. Zu sagen, dass es keine Lösung gibt, wäre ungenau. Zu sagen, dass jeder Ubuntu VPS bereits gepatcht ist, wäre ebenso ungenau. Ein getestetes Paket, seine Verfügbarkeit über die üblichen Update-Kanäle und seine tatsächliche Verwendung auf einer Maschine sind unterschiedliche Tatsachen.
Canonical beschreibt den frühen Zugriff auf vorgeschlagene Kernel als eine Möglichkeit für Teams, ihre eigenen Abnahmetests durchzuführen. Mit diesem Kanal kann die Arbeit früher beginnen. Es stellt nicht sicher, dass der umfassendere Qualifizierungsprozess abgeschlossen ist.
Bei einem VPS, der echte Anwendungen bedient, umfasst die Entscheidung auch den Neustart, die Treiber, die Netzwerkanbindung und die Wiederherstellung. Durch die umfassende Aktivierung eines Repositorys und die Durchführung eines Upgrades ohne Überprüfung der ausgewählten Pakete kann der Eingriff über den beabsichtigten Fix hinausgehen. Dieser Artikel bietet daher keinen allgemeinen Befehl zum Umschalten einer Produktionsmaschine auf -proposed.
Die nützliche Frage ist nicht nur, ob ein Fix verfügbar ist. Es kommt darauf an, welcher Kanal es bereitstellt, für welche Verteilung und Kernel-Variante und mit welcher Validierung.
Der TinyDigit VPS wurde von 7.0.0-38-generic auf 7.0.0-43-generic umgestellt. Der PRNext-VPS wurde von 7.0.0-28-generisch auf 7.0.0-43-generisch umgestellt. Auf jedem Server haben wir vier Ubuntu-Kernelpakete in der Version 7.0.0-43.43 installiert und dann nach dem Neustart den tatsächlich ausgeführten Kernel überprüft.
Die Installation war auf diese Pakete beschränkt, ohne dass ein Distributions-Upgrade oder eine globale Aktivierung erforderlich war. Die bisherigen Kernel bleiben als Boot-Fallbacks verfügbar. Auch bei dieser Nachverfolgung bleiben die temporären Netzwerkfilter- und MPTCP-Einstellungen erhalten.
Nach den Neustarts haben wir eine neue SSH-Verbindung zu jedem Server geöffnet und die HTTPS-Antworten der getesteten PRNext- und TinyDigit-Endpunkte überprüft. Die fünf Original-Bewerbungsbehälter sind vorhanden und bereit; Ihre fünf nativen Aliase antworten ebenfalls über HTTPS.
Eine externe Abhängigkeit bleibt nicht verfügbar; Die vollständige Wiederherstellung der Anwendung muss noch überprüft werden.
Das auf der Festplatte installierte Kernelpaket kann sich vom aktuell ausgeführten Kernel unterscheiden. Nach einem Eingriff muss die Prüfung das laufende System, den neuen SSH-Zugriff, HTTPS und die darauf gehosteten Anwendungen umfassen. Ein erfolgreiches Beenden des Paketmanagers reicht nicht aus, um die Arbeit abzuschließen.
Diese Befehle verändern den Server nicht. Sie bieten einen Ausgangspunkt für den Vergleich mit dem offiziellen Tracker der Distribution. Eine Versionsnummer allein, ohne die Paketidentität und die zurückportierten Fixes der Distribution, kann das Ergebnis nicht bestimmen.
uname -r
cat /etc/os-releaseUnser ursprünglicher Leitfaden dokumentiert die am 30 Oktober angewendeten vorübergehenden Maßnahmen und die danach durchgeführten Kontrollen. Es bleibt ein historischer Bericht und kein Beweis für den aktuellen Status jeder VPS-Instanz.
Durch das Deaktivieren von MPTCP wird der zugrunde liegende Fehler nicht behoben. Der Tracker von Ubuntu beschreibt auch Grenzen für die gezielte Filterung von IPv4-Optionen. Eine geladene Regel, ein Paketzähler oder eine erreichbare Website garantieren keinen Schutz vor jedem Ausnutzungsweg.
Es ist vernünftig, eine klare Darstellung dessen zu erwarten, was behoben wurde, was noch getestet wird und was an den Maschinen selbst noch getan werden muss. Ebenso wichtig ist es, die Kosten für die Bereitstellung eines Kernel-Updates ohne ausreichende Validierung zu berücksichtigen. Dringlichkeit und Stabilität gehören in die gleiche Entscheidung.
Unser Standpunkt ist einfach: Eine Übergangsmaßnahme muss in der noch zu erledigenden Arbeit sichtbar bleiben. Der Endpunkt sollte eine gepatchte Version sein, die tatsächlich mit verifizierten Diensten läuft, und nicht nur eine beruhigende Ankündigung. Ein npm-Update auf PRNext kann diese Linux-Systemaufgabe nicht ausführen.
Was wir an zwei Ubuntu VPS-Instanzen überprüft haben: nftables, MPTCP, Container und Servicezustand. Vorübergehende Maßnahmen während des Wartens auf einen Linux-Kernel-Fix.
PRNextStellen Sie eine Next.js-Anwendung auf einem Linux-VPS mit einem Produktionsserver, systemd, einem Reverse-Proxy und Überprüfungen bereit, bevor Sie den Datenverkehr wechseln.
PRNextDer lokale Kandidat für PRNext 0.1.18-alpha gegen Next.js 16.4.3: Durchsatz, CPU, RAM, Navigation und Wake-Latenz, mit genauen Versionen und Testgrenzen.
PRNext