CISA KEV: Fortinet, Citrix, Chromium und Cisco jetzt prüfen

CISA hat am 9. September 2026 vier Schwachstellen neu in den Katalog der Known Exploited Vulnerabilities aufgenommen. Der Grund ist nicht allein ein hoher theoretischer Schweregrad, sondern nachgewiesene aktive Ausnutzung. Betroffen sind Produkte von Fortinet, Citrix, Google und Cisco. Für Unternehmen ist das ein klares Signal, die eigenen Systeme nicht nach dem nächsten regulären Patchfenster, sondern nach realer Exposition und möglicher Kompromittierung zu priorisieren.

Die amerikanische Binding Operational Directive 26-04 richtet sich verbindlich an US-Bundesbehörden. Für DACH-Unternehmen entsteht daraus keine automatische Rechtspflicht. CISA empfiehlt aber allen Organisationen, den KEV-Katalog für risikobasiertes Schwachstellenmanagement zu nutzen. Besonders im Fokus stehen öffentlich erreichbare Systeme, bei denen eine erfolgreiche Ausnutzung weitreichende Kontrolle ermöglichen kann.

Diese vier aktiv ausgenutzten Schwachstellen sind betroffen

• CVE-2025-25249: Heap-basierter Pufferüberlauf in mehreren Fortinet-Produkten.
• CVE-2026-19490: Authentifizierungsumgehung über einen alternativen Pfad oder Kanal in Citrix NetScaler.
• CVE-2026-87491: Out-of-Bounds-Write in Google Chromium V8.
• CVE-2026-20079: Authentifizierungsumgehung über einen alternativen Pfad oder Kanal im Cisco Firewall Management Center.

Die CISA-Meldung nennt die Produkte und Schwachstellentypen, enthält aber keine vollständige Zuordnung aller betroffenen Versionen oder individuelle Installationsanweisungen. Verantwortliche müssen deshalb für jedes gefundene Produkt die aktuelle Herstellerempfehlung, verfügbare Updates, Workarounds und Hinweise zur Kompromittierungsprüfung heranziehen. Aus der bloßen Produktnennung darf weder Betroffenheit noch Entwarnung abgeleitet werden.

Die richtige Priorität: Exposition vor Kalender und CVSS

Ein starrer Ablauf nach Patchdatum oder numerischem Score greift bei KEV-Einträgen zu kurz. Zuerst muss geklärt werden, wo die betroffenen Produkte tatsächlich betrieben werden und welche Instanzen aus dem Internet oder aus weniger vertrauenswürdigen Netzen erreichbar sind. Danach zählen Berechtigungsniveau, Geschäftskritikalität, gespeicherte Daten und die Möglichkeit, von dem System in weitere Bereiche vorzudringen.

1. Produktbestand verifizieren: exakte Produkte, Versionen, Instanzen, Owner und Betriebsorte erfassen.
2. Exposition bestimmen: Internetzugang, externe Verwaltungsoberflächen, VPN-Zugänge, Reverse Proxies und vorgelagerte Schutzmaßnahmen prüfen.
3. Auswirkung bewerten: mögliche Kontrolle, erreichbare Konten, sensible Daten und Abhängigkeiten zu weiteren Systemen dokumentieren.
4. Behebungsweg festlegen: aktuelle Herstellerupdates oder offizielle Mitigationen mit Verantwortlichem und Wartungsfenster zuordnen.
5. Kompromittierungsprüfung einplanen: besonders exponierte oder privilegierte Systeme vor und nach der Behebung forensisch angemessen prüfen.

Chromium V8 benötigt dabei eine andere Inventarisierung als eine zentrale Appliance. Neben verwalteten Browsern können eingebettete Laufzeitumgebungen oder Anwendungen relevant sein, sofern der jeweilige Hersteller die Schwachstelle für sein Produkt bestätigt. Diese Betroffenheit ist eine technische Prüfung, keine pauschale Schlussfolgerung aus dem Begriff Chromium.

Kompromittierung prüfen, ohne Beweise zu verlieren

CISA betont bei besonders riskanten Systemen die Frage, ob ein Angreifer bereits vor dem Update erfolgreich war. Die Prüfung sollte zur Kritikalität des Systems passen. Bevor Logs überschrieben, Dienste neu installiert oder virtuelle Systeme zurückgesetzt werden, müssen relevante Zeiträume und Beweise gesichert werden. Welche Indicators of Compromise gelten, muss aus aktuellen Hersteller- und Incident-Response-Hinweisen kommen.

• Authentifizierungs- und Administrationsprotokolle auf unerwartete Anmeldungen, neue Konten und Rechteänderungen prüfen.
• Konfigurationsänderungen, neue Weiterleitungen, unbekannte Integrationen und deaktivierte Schutzfunktionen untersuchen.
• Ausgehende Verbindungen, DNS-Anfragen und ungewöhnliche Datenübertragungen mit der bekannten Systemrolle vergleichen.
• Datei-, Prozess- und Persistenzänderungen nach den herstellerspezifischen Hinweisen bewerten.
• Bei belastbaren Anzeichen den Incident-Response-Prozess starten, betroffene Zugangsdaten behandeln und die Reichweite über das Ursprungssystem hinaus prüfen.

Eine fehlende Auffälligkeit in Standardlogs ist keine Garantie, dass kein Angriff stattgefunden hat. Umgekehrt beweist ein ungewöhnlicher Eintrag noch keine Kompromittierung. Der Befund muss nachvollziehbar dokumentiert, mit weiteren Telemetriedaten abgeglichen und bei kritischen Systemen durch qualifizierte Security-Verantwortliche bewertet werden.

Operativer Ablauf für Behebung und Freigabe

1. Evidenz sichern und zuständige Incident-Response-Rolle informieren, bevor stark veränderte Systeme aktualisiert werden.
2. Offizielle Herstellermaßnahme in einer kontrollierten Umgebung prüfen und anschließend nach Exposition gestaffelt ausrollen.
3. Nach Update oder Mitigation Version, Dienststatus, externe Erreichbarkeit und zentrale Geschäftsprozesse validieren.
4. Veraltete Instanzen, temporäre Ausnahmen und nicht mehr benötigte Verwaltungszugänge entfernen oder isolieren.
5. Abschlussnachweis mit Asset, CVE, Maßnahme, Zeitpunkt, Prüfergebnis, Restrisiko und zuständiger Freigabe erstellen.

Für die Geschäftsführung sind vier Kennzahlen aussagekräftiger als eine bloße Patchquote: Zeit bis zur vollständigen Inventarisierung, Anteil exponierter betroffener Systeme, Zeit bis zur Risikoreduktion und Anteil der Fälle mit dokumentierter Kompromittierungsprüfung. So wird sichtbar, ob die Organisation aktiv ausgenutzte Lücken tatsächlich schneller und gründlicher behandelt als gewöhnliche Updates.

Die GNS-Einordnung: KEV ist ein Prioritätssignal, kein Ersatz für Inventar

Die vier neuen Einträge zeigen erneut, warum ein aktuelles Asset- und Softwareinventar die Grundlage jeder schnellen Reaktion ist. Wer erst nach einer CISA-Warnung herausfinden muss, wo NetScaler, Fortinet-Produkte, Chromium-V8-Komponenten oder Cisco Firewall Management Center laufen, verliert wertvolle Zeit. Der KEV-Katalog liefert das externe Risikosignal; wirksam wird es erst durch klare Owner, belastbare Expositionsdaten, gesicherte Evidenz und einen dokumentierten Abschluss.