CISA KEV: Zwei Linux-Kernel-Lücken jetzt priorisieren

CISA hat zwei Schwachstellen im Linux-Kernel in den Katalog der Known Exploited Vulnerabilities, kurz KEV, aufgenommen. Damit gilt die aktive Ausnutzung als belegt: CVE-2025-39964 ist als Race Condition eingeordnet, CVE-2026-53266 als Out-of-Bounds-Write-Lücke. Für Unternehmen ist das ein klares Priorisierungssignal. Es ist aber noch kein Beleg dafür, dass jede Linux-Installation betroffen oder über denselben Angriffsweg erreichbar ist.

Die offizielle Meldung fordert US-Bundesbehörden zu einer risikobasierten, priorisierten Behebung auf und empfiehlt dieses Vorgehen auch anderen Organisationen. CISA betont außerdem, dass bei hochriskanten KEV-Lücken auf öffentlich erreichbaren Systemen nicht nur das Update zählt: Je nach Lage muss geprüft werden, ob ein Angreifer das System bereits vor der Behebung kompromittiert hat. Genau dieser zweite Schritt wird in der Praxis häufig übersehen.

Was bestätigt ist – und was Unternehmen noch prüfen müssen

Bestätigt sind die Aufnahme beider CVEs in den KEV-Katalog, die aktive Ausnutzung und die beiden Fehlerklassen. Die CISA-Meldung nennt dagegen keine allgemeingültige Liste betroffener Distributionen, Kernelpakete oder Betriebsmodelle. Sie beschreibt auch nicht, ob ein konkreter Angriff lokal, remote oder nur unter zusätzlichen Voraussetzungen möglich ist. Solche Details dürfen nicht aus der Fehlerklasse abgeleitet werden.

Operativ bedeutet das: Security- und Plattformteams müssen zuerst eine belastbare Systemliste erstellen und anschließend die Hinweise der jeweiligen Distribution oder des Appliance-Anbieters auswerten. Bei verwalteten Angeboten, Containern und Appliances ist zudem zu klären, wer den Host-Kernel betreibt. Ein Container bringt beispielsweise typischerweise keinen eigenen Kernel mit; das Risiko liegt dann auf der darunterliegenden Host- oder Plattformebene.

Vier Stufen für die risikobasierte Priorisierung

Solange noch nicht für jedes System ein vollständiger Herstellerabgleich vorliegt, lässt sich die Reihenfolge anhand von Exposition, Berechtigungen, Geschäftskritikalität und vorhandenen Schutzmaßnahmen steuern. Diese Einstufung ersetzt die technische Betroffenheitsprüfung nicht, verhindert aber, dass alle Linux-Systeme ungeordnet in dieselbe Warteschlange gelangen.

1. Priorität 1: öffentlich erreichbare Linux-Systeme oder Plattformknoten mit hoher Berechtigung, sensiblen Daten oder zentraler Funktion. Hier laufen Herstellerabgleich, Eindämmung und Behebung parallel.
2. Priorität 2: intern erreichbare Produktionssysteme, die viele Nutzer, Automationen oder privilegierte Dienste bedienen. Sie folgen unmittelbar, weil eine vorhandene interne Angriffsmöglichkeit große Folgewirkung haben kann.
3. Priorität 3: Entwicklungs-, Test- und Build-Systeme mit Zugang zu Quellcode, Secrets oder Deployment-Rechten. Geringere Verfügbarkeit nach außen bedeutet nicht automatisch geringeren Schaden.
4. Priorität 4: isolierte oder abgeschaltete Systeme ohne produktive Funktion. Sie bleiben im Inventar, werden aber erst nach den exponierten und geschäftskritischen Beständen bearbeitet.

Diese Reihenfolge ist eine nachvollziehbare Unternehmensableitung, keine Aussage von CISA über den konkreten Exploitpfad der beiden CVEs. Wird durch Herstellerinformationen ein System als nicht betroffen bestätigt, kann es dokumentiert aus der Remediation-Liste entfernt werden. Bleibt die Lage unklar, sollte es bis zur Klärung nicht vorschnell als sicher gelten.

Sechsstufiges Runbook für Update und Nachweis

1. Inventar einfrieren: Hostname, Zweck, Verantwortliche, Distribution, Paketstand, aktuell laufende Kernelversion, Exposition und Kritikalität erfassen. Cloud-Instanzen, Hypervisor, Appliances und Kubernetes-Knoten ausdrücklich einschließen.
2. Betroffenheit belegen: Die CVEs mit offiziellen Hinweisen des Distributions- oder Produktanbieters abgleichen. Die Entscheidung betroffen, nicht betroffen oder noch unklar samt Quelle dokumentieren.
3. Sofortmaßnahmen setzen: Wo ein Update nicht sofort möglich ist, Erreichbarkeit reduzieren, unnötige Dienste deaktivieren, privilegierte Zugänge begrenzen und zusätzliche Überwachung aktivieren. Diese Maßnahmen sind zeitlich begrenzt und kein dauerhafter Ersatz für die Behebung.
4. Update kontrolliert ausrollen: Wartungsfenster, Abhängigkeiten und Rollback festlegen. Zuerst repräsentative Systeme aktualisieren, Funktions- und Sicherheitskontrollen prüfen und erst danach breiter ausrollen.
5. Laufenden Kernel verifizieren: Die Installation eines Pakets allein schließt den Vorgang nicht ab. Nach einem erforderlichen Neustart muss bestätigt werden, dass tatsächlich die korrigierte Kernelversion läuft und die betroffenen Dienste wieder ordnungsgemäß funktionieren.
6. Abschluss belegen: Paketquelle, Zeitpunkt, laufende Version, Testresultate, Ausnahmen und verbleibende Risiken in einem gemeinsamen Nachweis erfassen. Nicht erreichbare oder stillgelegte Systeme erhalten einen Eigentümer und eine verbindliche Folgeaktion.

Besondere Aufmerksamkeit verdient die Trennung zwischen installiertem und laufendem Kernel. Wird ein korrigiertes Paket eingespielt, der Rechner aber nicht neu gestartet, kann weiterhin der alte Kernel aktiv sein. Für Geschäftsleitung und Audit reicht daher keine Quote installierter Updates. Sinnvoller sind drei getrennte Kennzahlen: technisch bewertet, korrigiert und nach Neustart verifiziert.

Kompromittierung prüfen statt nur Patchstatus melden

Weil CISA aktive Ausnutzung bestätigt, sollte die Untersuchung möglicher Voraktivität risikobasiert Teil des Vorgangs sein. Ohne veröffentlichte, belastbare Details zum konkreten Angriff darf das Team jedoch keine erfundenen Indicators of Compromise verwenden. Ausgangspunkt sind die vorhandenen Telemetriedaten und später veröffentlichte Hersteller- oder Behördenhinweise.

• Zeitraum zwischen möglicher Verwundbarkeit und bestätigter Behebung festlegen.
• Authentifizierungs-, Prozess-, Netzwerk- und Integritätsereignisse auf unerklärliche Abweichungen prüfen.
• Neue privilegierte Konten, Schlüssel, geplante Aufgaben, Dienste und ungewöhnliche ausgehende Verbindungen untersuchen.
• Bei verdächtigen Befunden das System isolieren, forensisch sichern und Zugangsdaten beziehungsweise Secrets nach einem abgestimmten Plan rotieren.
• Ergebnis und Datenlücken dokumentieren; fehlende Telemetrie darf nicht als Beweis für eine ausgebliebene Kompromittierung gelten.

Für Entscheider ergibt sich ein einfaches Steuerungsbild: Wie viele Systeme sind geprüft, wie viele tatsächlich betroffen, wie viele laufen nachweislich mit korrigiertem Kernel und bei welchen war eine Kompromittierungsprüfung erforderlich oder mangels Daten nur eingeschränkt möglich? Diese Sicht verbindet technische Remediation mit dem verbleibenden Geschäftsrisiko – und verhindert, dass ein grüner Patchstatus offene Angriffsfragen verdeckt.