Linux-Kernel-Lücken aktiv ausgenutzt: Ein Wartungsfenster in 14 Tagen schützt keinen Server

Die US-Behörde CISA hat am 18. September zwei Linux-Kernel-Schwachstellen in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen, weil sie nachweislich angegriffen werden. Viele Teams legen dafür ein Ticket an und planen die Korrektur für ein Wartungsfenster in 14 Tagen. Aus dem Internet erreichbare Server bleiben in dieser Zeit angreifbar. Ein Ticket senkt keine Gefahr.

Der Ablauf ist vertraut. Am Freitag erscheint die Meldung, am Samstag legt jemand ein Ticket an, setzt die Priorität auf „hoch“, hängt den Link an und schreibt: Korrektur im nächsten Wartungsfenster. Das sind vierzehn Tage, manchmal drei Wochen. Die Server, die von außen erreichbar sind, bleiben in dieser Zeit genau das: erreichbar und ungepatcht. Das Ticket fühlt sich nach Arbeit an. Mit dem Zustand der Maschinen hat es nichts zu tun.

Was die CISA am 18. September in den Katalog aufgenommen hat

Die CISA hat zwei Linux-Kernel-Schwachstellen aufgenommen und stützt sich dabei auf Belege für aktive Ausnutzung. Das geht aus dem Alert der CISA vom 18. September hervor. Der Katalog heißt im Original Known Exploited Vulnerabilities Catalog, kurz KEV. Die beiden Einträge lauten:

• CVE-2025-39964, eine Race Condition im Linux-Kernel, also ein Fehler durch ungünstig verschränkte Abläufe
• CVE-2026-53266, ein Schreibzugriff außerhalb der Speichergrenzen (Out-of-Bounds Write) im Linux-Kernel

Für die operative Entscheidung braucht es nicht mehr. Die CISA nennt solche Schwachstellen ein häufiges Angriffsmuster und ein erhebliches Risiko für die Bundesbehörden der USA. Anleitungen zum Nachbauen enthält der Alert bewusst nicht. Auch Paketlisten, Versionstabellen und Prüfrezepte fehlen.

Beide Fehlerklassen können nach erfolgreicher Ausnutzung die volle Kontrolle über das betroffene System bedeuten. Der Katalog ist der Ort, an dem „irgendwann patchen“ als Antwort ausgedient hat. Wer nun Subsysteme seziert oder Angriffswege nachzeichnet, verteidigt nichts. Sinnvoll ist, den Hinweisen der Hersteller und Distributionen zu folgen, das Inventar zu ziehen und die Erreichbarkeit zu senken.

Was die Anweisung BOD 26-04 für Behörden und für alle anderen bedeutet

Die CISA verweist parallel auf die Binding Operational Directive 26-04 mit dem Titel „Prioritizing Security Updates Based on Risk“, auf Deutsch eine verbindliche Betriebsanweisung zur risikobasierten Priorisierung von Sicherheitsupdates. Sie richtet sich an die zivilen Bundesbehörden der USA, im Original Federal Civilian Executive Branch Agencies, kurz FCEB. Für Unternehmen und Behörden anderswo ist sie kein Gesetz, wohl aber ein unbequemer Maßstab.

Die Anweisung legt laut CISA drei Dinge fest:

• Schwachstellen aus dem Katalog mit hohem Risiko sind auf öffentlich erreichbaren Systemen rasch zu beheben, wenn eine Ausnutzung die vollständige Kontrolle über das System erlauben kann.
• Niedrigere Risiken dürfen zurückgestellt werden. Nicht alles ist gleich dringend, Risiko und Erreichbarkeit sind getrennt zu bewerten.
• Es gibt grundlegende Erwartungen, wann geprüft werden muss, ob Angreifende das System schon vor dem Patch kompromittiert haben.

Der letzte Punkt fehlt in vielen Änderungsanträgen. Wer patcht, ohne vorher nach Spuren zu suchen, schließt eine Tür ab, ohne nachzusehen, ob drinnen schon jemand sitzt.

Die CISA betont, dass die Anweisung nur für die FCEB gilt. Zugleich ermutigt sie alle Organisationen, Schwachstellen risikobasiert zu behandeln und Katalogeinträge vorrangig zu beheben. Die Hinweise zur Umsetzung von BOD 26-04 liegen öffentlich vor. Für den Alltag genügt die Kernbotschaft: Was öffentlich erreichbar ist, im Katalog steht und nach einem Angriff die volle Kontrolle preisgibt, kommt zuerst dran.

Bei Aufnahmen in den Katalog verlangt die CISA eine CVE-Kennung, Belege für die Ausnutzung und klare Hinweise zur Abhilfe. Behörden bekommen Fristen, Unternehmen bekommen Ausreden. Der Unterschied ist eher kulturell als technisch.

Warum ein Ticket noch keine Absicherung ist

Ein Ticket dokumentiert eine Absicht und ändert nichts am Zustand der Systeme. Am Montag steht es auf „bereit für den Sprint“, die Beschreibung zitiert die CISA, die Priorität stimmt. Im Kommentarverlauf fragt jemand nach dem Einfrieren von Änderungen, jemand anderes nach dem Plan für den Rückweg. Alles ist vernünftig, alles ist dokumentiert, und alles ist noch offen.

Priorisierung legt nur die Reihenfolge fest. Behoben ist eine Lücke erst, wenn dazwischen vier Dinge geschehen sind: die Erreichbarkeit sinkt, der Patch ist eingespielt, der Rechner wurde neu gestartet, und der neue Kernel läuft tatsächlich. Dazu kommt die Frage, ob das System schon vor der Aktualisierung kompromittiert war.

Vierzehn Tage Wartungsfenster gegen aktive Ausnutzung sind eine Wette auf Zeit. Sie fühlt sich wie Steuerung an, weil sie in Boards und Freigaberunden besprochen wird. Wer den Katalog nur abonniert, ihn „trackt“ und Fristen setzt, hat damit noch keinen Rechner geschützt. Angreifende interessiert die Aktenlage nicht.

Frühere Katalogeinträge zeigen das Muster. Beim Fall Langflow im Katalog und bei der Meldung zu vCenter und dem Druck auf Administratoren löste die Aufnahme zunächst Hektik aus. Die eigentliche Arbeit an den Systemen folgte deutlich langsamer. Der Kernel-Fall betrifft vermutlich mehr Rechner und verträgt keine Vertröstung auf nächste Woche.

Wie die Verteidigung konkret aussieht

Verteidigen heißt hier, eine feste Reihenfolge einzuhalten, und sie beginnt mit dem Inventar. Gesucht werden die Linux-Systeme, die aus dem Internet erreichbar sind: Verwaltungsoberflächen, Sprungrechner, VPN-Endpunkte auf Linux-Basis, Build-Rechner mit öffentlicher Adresse, vergessene Testmaschinen und Container-Hosts mit offenen Ports. Wer diese Liste nicht hat, kann keine risikobasierte Auswahl treffen. Aus „priorisieren“ wird dann wieder „alles irgendwann“. Die Quellen, etwa Bestandsverzeichnis, Cloud-Übersicht, Scanner-Ergebnisse, Firewall-Regeln und Lastverteiler, gehören in dieser Woche zusammengeführt, nicht in einem Quartalsprojekt.

Für beide Schwachstellen gilt anschließend die einfachste Regel: den Hinweisen der Hersteller und Distributionen folgen. Keine Paketnamen aus dem Gedächtnis, keine Versionsnummern aus Foren, keine erfundenen Zwischenlösungen aus Blogbeiträgen. Fixes übernehmen und die Änderungsliste gegen die CVE-Kennungen halten. Hat der Hersteller noch nichts veröffentlicht, ist das kein Freibrief. Dann rücken Erreichbarkeit und Überwachung nach vorn.

Die Schritte in der richtigen Reihenfolge:

1. Alert lesen: Quelle CISA, zwei CVE-Kennungen, die Fehlerklassen Race Condition und Out-of-Bounds Write, Belege für aktive Ausnutzung.
2. Erreichbare Linux-Systeme erfassen: nicht „alle Server“, sondern zuerst die aus dem Internet erreichbaren.
3. Herstellerhinweise prüfen: nur offizielle Quellen der Hersteller und Distributionen.
4. Erreichbarkeit sofort senken: Verwaltungsports schließen, Zugriffslisten enger ziehen, Sprungrechner vorschalten, unkritische Dienste vorübergehend abschalten und die Netzsegmentierung durchsetzen, die oft nur auf Folien existiert.
5. Auf Kompromittierung prüfen: vor dem Patch, nicht nur danach.
6. Patchen und den laufenden Kernel nachweisen: das Ticket erst schließen, wenn der Zustand stimmt.
7. Erneut prüfen: nach dem Patch, denn ein Fix löscht keine bereits bestehende Präsenz.

Die Prüfung auf Kompromittierung bleibt auf hoher Ebene. Verglichen werden bekannte gute Zustände mit den aktuellen Spuren. Auffällig sind dauerhafte Hintertüren, unerwartete Konten, verdächtige zeitgesteuerte Aufgaben und ungewöhnliche Netzwerkverbindungen von Rechnern, die eigentlich still sein sollten. Dazu kommen die Protokolle aus der Zeit vor dem Alert und vor dem Wartungsfenster.

Schließlich der Klassiker: Das Paket ist installiert, das Ticket steht auf „erledigt“, die Überwachung zeigt Grün, und der Host läuft weiter mit dem alten Kernel. Der Neustart wurde verschoben, Live-Patching wurde angenommen, wo keines greift, oder jemand hat in einer uneinheitlichen Flotte die falsche Maschine geprüft. Nachzuweisen ist deshalb der laufende Zustand, nicht das installierte Paket. Diese Pedanterie ist bei Kernel-Updates der Unterschied zwischen „gepatcht“ und „behoben“.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2PromptAdult hands holding a printed change-window checklist beside a laptop in a quiet server room, soft overhead light, defensive hardening mood, photorealistic, no logos, no readable UI, no exploit code, no payloads, 16:9

Wie sich ein Aufschub verantworten lässt

Wartungsfenster haben legitime Gründe: Verfügbarkeit, Abhängigkeiten, zertifizierte Abbilder, gestaffelte Neustarts im Cluster. Niemand verlangt Neustarts um drei Uhr nachts ohne Plan. Ist ein System aber öffentlich erreichbar und erlaubt der Katalogeintrag nach einem Angriff die volle Kontrolle, dann ist „nächstes Fenster in 14 Tagen“ eine bewusste Risikoübernahme. Sie gehört dokumentiert, nach oben gemeldet und möglichst verkürzt, statt sich hinter einem Prioritätsetikett zu verstecken.

Die Meldung kann schriftlich knapp ausfallen: Diese erreichbaren Hosts bleiben eine bestimmte Zahl von Tagen ungepatcht, obwohl die CISA für Katalogeinträge aktive Ausnutzung dokumentiert. Manches Gremium wird unruhig werden. Das ist billiger als ein Sicherheitsvorfall.

Auch die üblichen Einwände tragen nicht weit. Wer sich „nicht so kritisch wie Behörden“ nennt, übersieht, dass der Katalog nicht nach Branche unterscheidet. Er listet, was ausgenutzt wird. Halten Verantwortliche Kernel-Updates für zu riskant, folgt daraus kein Abwarten: Die Erreichbarkeit sinkt, die Testumgebung wird hochgefahren, der Rückweg erprobt, der Blick auf Kompromittierung geschärft und das Fenster vorgezogen. Und wer das Ticket auf „Beobachtung“ stellt und auf Überwachungssysteme hofft, hat nur Sicht gewonnen. Beobachtung ersetzt weder den Patch noch die Suche nach Spuren früherer Angriffe.

Das Ticket beruhigt, weil es Verantwortung in ein System auslagert, das einen Status anzeigt. „In Bearbeitung“, „blockiert durch Änderungsstopp“, „wartet auf das Gremium“ – jede Angabe stimmt, und keine sagt etwas darüber, welchen Kernel der Host im Internet gerade fährt. Wer interne Leitfäden schreibt, kann den Grundsatz groß setzen: Ein Katalogeintrag ist der Startschuss, nicht die Härtung. Darunter gehört die Logik der Anweisung: Erreichbares mit hoher Wirkung zuerst, vor und nach dem Patch auf Kompromittierung prüfen, niedrige Risiken bewusst zurückstellen.

Die CISA nimmt laufend Einträge auf, die ihre Kriterien erfüllen, und auch frühere Fälle wie der Advisory-Druck bei kritischen Einstufungen folgen diesem Mechanismus aus Katalog, Beleg und Druck zur Behebung. Ein Linux-Kernel-Eintrag, erst recht zwei an einem Tag, gehört deshalb nicht in die wöchentliche Nachrichtenrunde, sondern in die Arbeitsplanung für die Flotte. Die Verantwortung dafür sollte namentlich festliegen. Die Ausrede, die Linux-Leute erledigten das nächste Woche, hilft niemandem, solange keiner für die erreichbaren Systeme zuständig ist.

Meine Meinung dazu in einem Satz: Eine Organisation, die in Präsentationen „risikobasiert“ sagt und im Betrieb nach dem Kalender handelt, belügt vor allem sich selbst. Warum sollte ein Unternehmen langsamer sein als eine Anweisung, die es gar nicht bindet?

Bei der Frage nach dem Stand hilft ein einfacher Test. Wenn im Stand-up jemand sagt, man sei auf Kurs, lohnt die Nachfrage nach dem Zustand der Hosts statt nach dem Status des Tickets. Der Katalog wartet nicht auf die nächste Rückschau, und die Angreifenden warten auch nicht.