Am 18. September hat die US-Behörde CISA drei Lücken im Linux-Kern in ihr Verzeichnis der aktiv ausgenutzten Schwachstellen aufgenommen. Die Frist zur Behebung: der 21. September. Drei Tage.
Wir wollten wissen, was das für die Server bedeutet, die wir betreiben. Die Antwort auf diese Frage war unspektakulär. Die Antwort auf die nächste nicht.
Erst einmal: Was in den Meldungen dazu nicht stimmt
Mehrere Berichte schreiben, alle drei Lücken bräuchten lokalen Zugang. Das klingt beruhigend und ist für die schwerste der drei falsch.
Wir haben die Bewertungen einzeln nachgelesen. CVE-2025-39682 trägt 9.8 von 10 und ist über das Netz erreichbar, ohne jede Anmeldung. Sie steckt in der TLS-Verarbeitung im Kern selbst.
Nur gilt auch das Gegenteil dessen, was man daraus folgern möchte: Diese 9.8 betrifft Ubuntu 22.04 überhaupt nicht. Der Fehler existiert erst ab Kernel-Version 6.0; die Standard-Linie von 22.04 ist 5.15. Ubuntu führt sie für das Standardpaket ausdrücklich als «nicht betroffen».
Eine hohe Zahl in einer Meldung ist keine Aussage über Ihre Lage. Sie ist der Anlass nachzusehen, mehr nicht.
Die Lücke, für die es keine Korrektur gibt
Die zweite, CVE-2026-53266 mit 8.8, betrifft Ubuntu 22.04 sehr wohl. Sie steckt in einer Netzwerkfunktion des Kerns und braucht lokalen Zugang mit einer bestimmten Berechtigung, die sich über Namensräume erlangen lässt.
Der Stand bei Ubuntu lautet für jede 22.04-Variante gleich: verwundbar, in Arbeit. Es gibt bis heute keinen Fix.
Damit steht eine verbindliche Drei-Tage-Frist im Raum für eine Korrektur, die es nicht gibt. Die CISA hat das mitbedacht — die geforderte Massnahme lautet wörtlich, man solle die Herstellerkorrektur einspielen oder das Produkt einstellen, wenn keine verfügbar ist. Den Linux-Kern einzustellen ist für einen Webserver keine Option, und das weiss auch die CISA.
Die dritte, CVE-2025-39964 mit 7.8, ist behoben — ab Kernel 5.15.0-164.
Und an dieser Stelle wurde die Sache für uns unangenehm.
Was wir auf dem eigenen Server gefunden haben
Auf der Maschine, die unsere Websites ausliefert, läuft der Kern 5.15.0-89. Gestartet wurde sie am 1. Dezember 2023 — das sind zwei Jahre und 42 Wochen ohne Neustart.
Die Korrektur für die dritte Lücke beginnt bei 5.15.0-164. Wir laufen auf 5.15.0-89.
Das Ärgerlichste daran ist nicht die alte Zahl. Es ist die Zahl daneben: 5.15.0-191 ist installiert. Die Korrektur liegt auf der Platte. Sie läuft nur nicht.
Das System sagt das auch. Es setzt eine Markierung, dass ein Neustart nötig ist, und führt die Pakete auf, die darauf warten. Wir haben sie gezählt: 56 Kernel-Pakete, von 5.15.0-91 bis 5.15.0-191, dazu die zentrale Systembibliothek.
Warum das passiert, und warum es nicht an Nachlässigkeit liegt
Die Aktualisierungen wurden die ganze Zeit eingespielt. Die Markierung wurde zuletzt am 9. September neu geschrieben — das System arbeitet, wie es soll.
Was fehlt, ist der Neustart. Und der fehlt aus einem Grund, den jeder kennt, der einen Server betreibt: Er unterbricht. Auf dieser Maschine liegen mehrere Auftritte; ein Neustart trifft alle gleichzeitig. Also verschiebt man ihn auf nächste Woche, und nächste Woche ist genauso ungünstig.
Dazu kommt etwas Unausgesprochenes: Eine lange Betriebszeit gilt in unserer Branche als Auszeichnung. Zwei Jahre ohne Neustart heisst: nichts ist abgestürzt. Man sagt es nicht laut, aber man ist ein bisschen stolz darauf.
Bei einem Kern, der Sicherheitskorrekturen bekommt, ist es das Gegenteil. Eine lange Betriebszeit heisst dort: Alles, was seither korrigiert wurde, läuft hier noch im alten Zustand.
Was das praktisch bedeutete
Ehrlich bleiben heisst auch, nicht zu dramatisieren. Die einzige der drei Lücken, die unseren laufenden Kern betrifft, braucht lokalen Zugang. Ein Besucher der Website kann sie nicht auslösen.
Auf einem Server, auf dem fremder Code läuft — und das tut er auf jedem Webserver, der PHP ausführt —, ist lokaler Zugang allerdings kein hoher Zaun, sondern die zweite Stufe. Aus «eine Website übernommen» wird damit unter Umständen «die Maschine übernommen». Das ist ein anderer Vorfall, mit anderen Meldepflichten.
Belegt ist bei uns nichts dergleichen. Gefallen hat uns der Befund trotzdem nicht.
Was wir getan haben
Der Neustart war für den Abend des 22. September angesetzt, mit Vorlauf für die anderen Auftritte auf derselben Maschine. Das Ergebnis tragen wir am Ende dieses Beitrags nach — es gehört dazu, sonst wäre dies ein Bekenntnis ohne Folgen.
Zwei Tage hintereinander schreiben wir nun über einen eigenen Mangel; gestern über die Statusseite, die wir nicht haben. Das ist kein Zufall und auch keine Koketterie. Wenn man anfängt, die eigenen Sachen mit derselben Strenge anzusehen wie die der anderen, findet man etwas. Das ist der Zweck der Übung.
Was Sie daraus mitnehmen können
Fragen Sie nach der Betriebszeit Ihres Servers. Nicht nach dem Update-Stand — nach der Betriebszeit. «Wann wurde die Maschine zuletzt neu gestartet» ist die Frage, die den Unterschied zwischen eingespielt und in Betrieb sichtbar macht. Beides ist nicht dasselbe, und nur eines davon schützt.
Verlangen Sie ein Wartungsfenster statt eines Versprechens. Ein Server, der nie neu startet, sammelt nicht nur Kernel-Korrekturen an, sondern auch das Risiko, dass er beim nächsten erzwungenen Neustart nicht sauber hochkommt — weil seit zwei Jahren niemand geprüft hat, ob er das noch tut. Ein geplanter Neustart ist immer billiger als ein ungeplanter.
Und werten Sie eine Meldung nicht nach ihrer Zahl. Die 9.8 aus diesem Fall betrifft unsere Kernel-Linie gar nicht; die 7.8 sehr wohl. Wer nach Schlagzeilen handelt, arbeitet an der falschen Stelle. Wir haben im August schon einmal den eigenen Bestand durchgezählt statt geschätzt, damals bei den PHP-Versionen — es ist derselbe Handgriff und er lohnt sich jedes Mal.
Und passend dazu die Erinnerung an einen Fall von letzter Woche: Dort kam die Korrektur für einen Serverdienst gar nicht erst von allein. Hier kam sie — und blieb liegen. Beide Male ist das Ergebnis dasselbe: Der Betrieb läuft ungeschützt weiter und niemand merkt es, weil nichts kaputtgeht.
Wenn Sie nicht wissen, wie es bei Ihnen aussieht
Zwei Zeilen auf der Kommandozeile beantworten es, und wir sagen Ihnen gern, welche. Bei Servern, die wir betreuen, gehört das ab sofort in den festen Turnus — das ist die zweite Konsequenz aus diesem Tag.