CISA KEV: der Known-Exploited-Vulnerabilities-Katalog

Was ist der CISA-KEV-Katalog?

Der Known-Exploited-Vulnerabilities-Katalog (KEV) wird von der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) gepflegt. CISA bezeichnet ihn als maßgebliche Quelle für Schwachstellen, die in freier Wildbahn ausgenutzt wurden, und empfiehlt allen Organisationen nachdrücklich, deren Behebung vorrangig zu behandeln.

CISA richtete den Katalog im November 2021 zusammen mit der Binding Operational Directive 22-01 ein. Mit Stand der Katalogversion vom 24. September 2026 enthält er 1.723 Schwachstellen. Das ist ein winziger Anteil aller veröffentlichten CVEs, und genau deshalb ist er nützlich: Ein KEV-Eintrag ist weder eine Vorhersage noch eine Schweregradbewertung, sondern der Nachweis einer Ausnutzung.

Wie eine Schwachstelle aufgenommen wird

CISA nimmt eine Schwachstelle auf, wenn sie drei Kriterien erfüllt:

1. Sie hat eine CVE-ID.
2. Sie wird aktiv ausgenutzt, und es gibt verlässliche Belege, dass sie ausgenutzt wurde oder wird.
3. Es gibt eine klare Anleitung zur Behebung, also eine klare Maßnahme für betroffene Organisationen, etwa ein Hersteller-Update.

Das dritte Kriterium ist in der Praxis wichtig: Eine Schwachstelle kann eine Weile ausgenutzt werden, bevor sie in KEV erscheint, weil es keinen Fix gab, auf den verwiesen werden konnte. Jeder kann über ein Formular, das auf der KEV-Seite von CISA verlinkt ist, eine Schwachstelle vorschlagen.

Was jeder KEV-Eintrag enthält

Feld	Was es enthält
cveID	Die CVE-Kennung
vendorProject, product	Wer die betroffene Software herstellt und welches Produkt es ist
vulnerabilityName, shortDescription	Einen Namen und eine Kurzbeschreibung
dateAdded, dueDate	Wann CISA sie aufgenommen hat, und die Behebungsfrist für US-Bundesbehörden
requiredAction	Was zu tun ist, meist die Updates oder Abhilfemaßnahmen des Herstellers anwenden oder die Nutzung einstellen
knownRansomwareCampaignUse	„Known“, wenn sie in einer Ransomware-Kampagne genutzt wurde, sonst „Unknown“
forensicTriage	„Yes“, wenn BOD 26-04 dafür eine forensische Triage verlangt
notes, cwes	Referenzen und die Schwächetypen

361 Einträge sind derzeit als in Ransomware-Kampagnen genutzt markiert. Wenn Sie innerhalb von KEV eine Rangfolge bilden müssen, kommen diese zuerst.

BOD 26-04: KEV-Fristen für Bundesbehörden

Für zivile Bundesbehörden der US-Exekutive ist KEV kein Ratschlag. Die Binding Operational Directive 26-04, erlassen am 10. Juni 2026, legt fest, wie schnell sie beheben müssen. Sie hob BOD 22-01 auf, die für die meisten KEV-Einträge zwei Wochen und für vor 2021 vergebene CVEs sechs Monate vorsah, sowie BOD 19-02. Die Kriterien für die Aufnahme einer Schwachstelle in KEV haben sich nicht geändert.

BOD 26-04 bestimmt jede Frist anhand von vier Fragen, gestützt auf das SSVC-Entscheidungsmodell von CISA:

• Öffentlich exponiert: Ist das Asset aus öffentlichen Netzen erreichbar?
• KEV-Status: Steht die Schwachstelle im Katalog?
• Automatisierung der Ausnutzung: Kann ein Angreifer die Ausnutzung automatisieren?
• Technische Auswirkung: Gibt die Ausnutzung teilweise oder vollständige Kontrolle?

Aus den Antworten ergeben sich Fristen von 3 Tagen, mit forensischer Triage zur Prüfung, ob das System bereits kompromittiert war, bis zur Behebung beim nächsten System-Upgrade. Die Richtlinie gilt nicht für Unternehmen außerhalb der Bundesverwaltung, sofern ein Vertrag nichts anderes vorsieht. Trotzdem ist sie ein nützlicher Maßstab für Ihre eigene Policy.

So nutzen Sie KEV, wenn Sie Software bauen

Die meisten KEV-Einträge betreffen Produkte großer Anbieter: Allein auf Microsoft entfallen 388, gefolgt von Cisco, Apple, Adobe und Google. Auch Open Source taucht auf, und wenn, dann in den Produkten anderer. Log4Shell (CVE-2021-44228) ist das Beispiel, an das sich alle erinnern.

Build-Pipelines sind nicht ausgenommen. Die kompromittierten GitHub Actions tj-actions/changed-files (CVE-2025-30066) und reviewdog/action-setup (CVE-2025-30154) stehen beide im Katalog: Eine bekannt ausgenutzte Schwachstelle kann in dem Workflow stecken, der Ihr Produkt baut, nicht nur im Produkt.

1. Gleichen Sie KEV mit dem ab, was Sie ausliefern, nicht mit dem, was Ihre Repositories deklarieren. Eine verwundbare Bibliothek, die transitiv nachgezogen oder von einem Build-Skript heruntergeladen wurde, steckt trotzdem im Produkt.
2. Behandeln Sie einen Treffer als Vorfall, nicht als Backlog-Eintrag. Beheben Sie das Problem oder mildern Sie es ab und halten Sie den Grund fest.
3. Prüfen Sie Ihren Expositionszeitraum. Welche Releases enthielten die verwundbare Version, und seit wann? Genau das fragen Kunden.
4. Behalten Sie die Meldefrist im Blick. Nach dem EU Cyber Resilience Act löst eine aktiv ausgenutzte Schwachstelle in einem Produkt für den Hersteller die Pflicht zu einer Frühwarnung innerhalb von 24 Stunden aus.
5. Ordnen Sie alles andere mit EPSS und CVSS ein. Schwachstellen priorisieren beschreibt die Methode.

So erhalten Sie die KEV-Daten

• CISA: die Katalogseite sowie CSV, JSON und ein JSON-Schema.
• GitHub: cisagov/kev-data spiegelt die Datendateien und wird aktualisiert, wenn sich der Katalog ändert.
• E-Mail: CISA bietet ein Abonnement für Katalog-Updates an.
• Ihre Tools: Viele Scanner und Plattformen für Schwachstellenmanagement markieren KEV-Einträge, darunter Grype, Tenable, Qualys und Rapid7.

Wie CRACI hilft

KEV sagt Ihnen, welche Schwachstellen ausgenutzt werden. CRACI sagt Ihnen, wo sie stecken. Es führt Ihre GitHub-Actions-Jobs aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, gecachter Pakete und versteckter Abhängigkeiten, die kein Lockfile auflistet, und bewertet überwachte SBOMs laufend neu.

• Welche Builds betroffen sind. Die Build-Historie zeigt, welche früheren Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie den Expositionszeitraum kennen.
• Wer sie behebt. Sicherheitsteams sichten Befunde und leiten jeden an das Team weiter, das für die Behebung zuständig ist.
• Verhindern, dass sie erneut ausgeliefert wird. Policy-Gates können einen Build blockieren, der eine bestimmte CVE enthält.
• Melden. Für aktiv ausgenutzte Schwachstellen nach dem CRA reicht CRACI die Meldungen im Namen des Herstellers bei den Behörden ein.

CISA KEV: häufig gestellte Fragen

Was ist CISA KEV?

Der Known-Exploited-Vulnerabilities-Katalog (KEV) ist die Liste von CISA mit Schwachstellen, die in freier Wildbahn ausgenutzt wurden. CISA bezeichnet ihn als maßgebliche Quelle für ausgenutzte Schwachstellen und empfiehlt jeder Organisation, deren Behebung vorrangig zu behandeln.

Wie viele Schwachstellen stehen im KEV-Katalog?

1.723 mit Stand der Katalogversion vom 24. September 2026, von Hunderttausenden veröffentlichten CVEs. 361 davon sind als bekanntermaßen in Ransomware-Kampagnen genutzt markiert.

Wann wird eine Schwachstelle in KEV aufgenommen?

Wenn drei Kriterien erfüllt sind: Sie hat eine CVE-ID, es gibt verlässliche Belege, dass sie ausgenutzt wurde oder wird, und es gibt eine klare Anleitung zur Behebung, etwa ein Hersteller-Update.

Müssen private Unternehmen die KEV-Fristen einhalten?

Nein. Die Fristen binden zivile Bundesbehörden der US-Exekutive nach der Binding Operational Directive 26-04. Alle anderen können den Katalog als Priorisierungssignal nutzen, und viele Kunden und Auditoren erwarten das.

Wodurch wurde BOD 22-01 ersetzt?

BOD 26-04, erlassen am 10. Juni 2026, hob BOD 22-01 und BOD 19-02 auf. Statt fester zwei Wochen für KEV-Einträge setzt sie Fristen von 3 Tagen bis zum nächsten System-Upgrade, abhängig von KEV-Status, öffentlicher Exposition, Automatisierbarkeit der Ausnutzung und technischer Auswirkung.

Was ist der Unterschied zwischen KEV und EPSS?

KEV verzeichnet Schwachstellen, die bereits ausgenutzt werden. EPSS schätzt die Wahrscheinlichkeit, dass eine veröffentlichte CVE in den nächsten 30 Tagen ausgenutzt wird. Nutzen Sie zuerst KEV und dann EPSS, um alles andere einzuordnen.