Anfang Oktober hat CISA wieder mehrere Einträge in den Known Exploited Vulnerabilities Catalog aufgenommen. Der auffälligste neue Eintrag vom 04. Oktober betrifft CVE-2026-88779 in Citrix NetScaler ADC und NetScaler Gateway; CISA nennt aktive Ausnutzung als Grundlage für die Aufnahme und fordert für betroffene Behörden eine schnelle Behandlung. [1]

In derselben aktuellen KEV-Welle tauchen außerdem Produkte auf, die in echten Umgebungen oft nah am Rand des Netzes stehen: FortiMail, Cisco Catalyst SD-WAN Manager, Zammad und Apple-Plattformen. Der maschinenlesbare KEV-Feed listet zum Beispiel FortiMail am 01. Oktober, Cisco Catalyst SD-WAN Manager am 30. September und Apple iOS/macOS/iPadOS am 29. September. [2]

KEV heißt nicht automatisch: „Alles stehen lassen und blind patchen.“ KEV heißt: „Dieses Thema gehört sichtbar auf die Prioritätenliste.“

Was der KEV-Katalog gut kann

Der KEV-Katalog ist keine vollständige Schwachstellen-Datenbank. Er ist enger gefasst: CISA führt dort Schwachstellen, für die es Hinweise auf Ausnutzung in freier Wildbahn gibt. Genau das macht ihn für Admins nützlich. Statt nur nach CVSS-Wert, Bauchgefühl oder Hersteller-Marketing zu sortieren, kommt ein praktisches Signal dazu: Diese Lücke ist nicht nur theoretisch. [3]

Das ist besonders hilfreich, wenn die Liste der offenen Updates größer ist als das verfügbare Wartungsfenster. Ein hoher CVSS-Wert beschreibt Schwere und technische Eigenschaften, aber nicht automatisch, ob gerade Angriffe laufen. Umgekehrt kann eine scheinbar „kleinere“ Lücke dringend werden, wenn sie bereits ausgenutzt wird und auf öffentlich erreichbaren Systemen sitzt.

CISA hat dieses Denken in BOD 26-04 noch stärker in Richtung Risiko geschoben: Behörden sollen hochriskante Schwachstellen priorisieren, besonders wenn KEV-Einträge öffentlich erreichbare Assets betreffen und eine Übernahme des Systems möglich ist. Für private Firmen, kleine Büros und Homelabs ist das keine Pflicht, aber ein brauchbares Betriebsmodell. [4]

Ruhige Triage statt Alarmmodus

Der praktische Ablauf kann klein anfangen. Jeden Morgen oder vor dem wöchentlichen Wartungsfenster wird geprüft, ob neue KEV-Einträge zur eigenen Umgebung passen. Nicht „haben wir irgendein Citrix?“, sondern konkret: Gibt es NetScaler ADC oder Gateway? Welche Version? Ist das System vom Internet erreichbar? Gibt es vorgeschaltete Schutzmaßnahmen? Wer besitzt das System fachlich?

Danach lohnt sich eine einfache Einordnung in drei Gruppen:

  • Treffer mit Exposition: Produkt vorhanden, verwundbare Version wahrscheinlich, System erreichbar oder kritisch.
  • Treffer ohne direkte Exposition: Produkt vorhanden, aber nicht öffentlich oder nur in einem begrenzten Netz erreichbar.
  • Kein Treffer: Produkt nicht vorhanden oder sicher nicht betroffen; kurz dokumentieren und weiter.

Gerade diese letzte Gruppe ist wichtig. Gute Triage bedeutet nicht, jedes Advisory in ein Großprojekt zu verwandeln. Sie bedeutet, begründet zu entscheiden und die Entscheidung wiederfinden zu können. Ein Ticket mit „nicht betroffen, geprüft am 07.10., keine NetScaler-Instanz im Inventar“ ist später wertvoller als eine Erinnerung im Kopf.

Patchen ist manchmal nicht der erste Schritt

Bei mehreren aktuellen KEV-Einträgen markiert CISA zusätzlich forensische Triage als erforderlich. Das ist ein wichtiger Punkt: Wenn eine Lücke bereits aktiv ausgenutzt wird, reicht „Update installiert“ nicht immer als Abschluss. Vor oder direkt nach dem Schließen der Lücke sollte geprüft werden, ob das System schon kompromittiert wurde. [2]

In der Praxis heißt das nicht automatisch vollständige Incident-Response mit Blaulicht. Aber es heißt: Logs sichern, Hersteller-IOCs prüfen, ungewöhnliche Prozesse oder Dateien betrachten, Admin-Konten kontrollieren und Monitoring-Ereignisse nicht vorschnell als „Patch erledigt“ abhaken. Bei FortiMail beschreibt der KEV-Eintrag zum Beispiel eine Path-Traversal-Schwachstelle, über die ein unauthentifizierter Angreifer Dateien auf dem zugrunde liegenden System schreiben kann. [2]

Merksatz: Patchen schließt die Tür. Triage prüft, ob schon jemand im Raum steht.

Was heißt das fürs Homelab?

Auch im Homelab ist KEV nützlich, nur mit anderer Flughöhe. Niemand braucht dort einen Behördenprozess mit Formularfriedhof. Sinnvoll sind aber dieselben Grundfragen: Welche Dienste hängen am Internet? Welche Admin-Oberflächen sind nur intern erreichbar? Welche Container, Appliances oder selbst gehosteten Tools habe ich seit Monaten nicht mehr angefasst?

Ein kleiner Wochenrhythmus reicht oft: KEV-Neuzugänge überfliegen, eigene Produktnamen abgleichen, externe Dienste priorisieren, Backup oder Snapshot vor riskanten Änderungen prüfen und nach dem Update einen echten Funktionstest machen. Bei Webmail, VPN, Reverse Proxy, Monitoring und Identity-Diensten sollte die Schwelle niedriger sein als bei einem ausgeschalteten Test-Container.

Mini-Runbook für die nächste KEV-Meldung

  1. KEV-Eintrag lesen und Produkt, CVE, Datum, Fälligkeitsdatum und Herstellerlink notieren.
  2. Inventar durchsuchen: Produkt vorhanden, Version bekannt, Besitzer bekannt?
  3. Exposition prüfen: Internet, VPN, internes Admin-Netz, nur Testumgebung?
  4. Herstellerhinweis lesen: Update, Workaround, bekannte Nebenwirkungen, Neustart nötig?
  5. Vor Änderung Backup, Snapshot oder Wiederherstellungspfad prüfen.
  6. Patch oder Mitigation durchführen, danach Dienstfunktion und Logs prüfen.
  7. Wenn aktive Ausnutzung gemeldet ist: IOCs und Auffälligkeiten dokumentiert prüfen.

Das klingt unspektakulär, und genau das ist der Punkt. Gute Security im Admin-Alltag besteht oft nicht aus großen Gesten, sondern aus klarer Reihenfolge. Der KEV-Katalog ersetzt kein Inventar, kein Monitoring und keine Backups. Aber er ist ein guter Kompass, wenn die Frage lautet: „Was muss zuerst auf den Tisch?“

Quellen

  1. CISA: CISA Adds One Known Exploited Vulnerability to Catalog
  2. CISA: Known Exploited Vulnerabilities JSON Feed
  3. CISA: Known Exploited Vulnerabilities Catalog
  4. CISA: BOD 26-04 – Prioritizing Security Updates Based on Risk