Cybersecurity
April 29, 2026
Julia Wolf
CISA hat seinen Known Exploited Vulnerabilities-Katalog erneut erweitert – 2025 mit dem stärksten Zuwachs seit dem Launch. Acht neue Schwachstellen betreffen kritische Infrastrukturen unmittelbar. Das Pikante daran: Manche der frisch aufgenommenen Lücken sind älter als so mancher IT-Praktikant.
1.484. Das ist der aktuelle Stand des CISA Known Exploited Vulnerabilities-Katalogs, und die Zahl wächst schneller als je zuvor. Im Jahr 2025 kamen 245 neue Einträge hinzu – ein Zuwachs von 20 Prozent gegenüber dem Vorjahr. Zum Vergleich: 2023 waren es 187 neue Schwachstellen, 2024 noch 185. Der Trend ist eindeutig, und er zeigt steil nach oben.
Was steckt hinter diesem Wachstum? Nicht nur frische Zero-Days. Ein erheblicher Teil der neu aufgenommenen Einträge – nämlich 94 von 245 – stammt aus 2024 oder früher. Die älteste frisch aufgenommene Lücke datiert auf das Jahr 2007: CVE-2007-0671, eine Microsoft-Office-Schwachstelle, die offenbar immer noch aktiv ausgenutzt wird. Man kann über vieles lachen in dieser Branche, aber über 18 Jahre alte Lücken, die noch in freier Wildbahn ihr Unwesen treiben – das ist Gallows Humor auf Systemadmin-Niveau.
Der KEV-Katalog ist dabei keine akademische Sammlung. SecurityWeek dokumentiert detailliert, dass die Binding Operational Directive 22-01 (BOD 22-01) US-Bundesbehörden zur sofortigen Behebung aller gelisteten Schwachstellen verpflichtet. Fristen, keine Empfehlungen. Für private Organisationen weltweit gilt zumindest eine dringende Empfehlung, den Katalog als Priorisierungsgrundlage für das eigene Patch-Management zu nutzen – was vernünftig ist, denn all diese Lücken werden aktiv in der Praxis ausgenutzt. Semantisch passt dazu unser Hintergrund IT-Security-Prognosen für 2026.
Wenig überraschend dominieren dabei bekannte Verdächtige: Microsoft, Google Chrome und Chromium, Fortinet, Citrix/NetScaler und SonicWall führen die Hitliste der betroffenen Produkte an. Wer in seiner Infrastruktur auf eines dieser Produkte setzt – und das dürfte die überwiegende Mehrheit der Unternehmens-IT betreffen – sollte den folgenden Abschnitt mit besonderer Aufmerksamkeit lesen.
Die Schwachstellendatenbank NVD listet Zehntausende von CVEs. Die Frage, die jeden Security-Verantwortlichen nachts wach hält: Welche davon werden tatsächlich ausgenutzt? Genau hier liegt der Clou des KEV-Katalogs. CISA nimmt nur Lücken auf, für die es konkrete Beweise aktiver Ausnutzung in der Praxis gibt. Keine theoretischen Angriffsvektoren, keine Proof-of-Concept-Szenarien aus der akademischen Forschung – echte Angriffe auf echte Systeme.
Das reduziert die Menge drastisch. Von den Zehntausenden gemeldeten Schwachstellen landen nur die tatsächlich gefährlichen im Katalog. Known Exploited Vulnerabilities sind damit ein hocheffizientes Filter-Werkzeug für Organisationen, die ihren Patch-Rückstau priorisieren müssen. Und der Rückstau ist real: Kaum eine IT-Abteilung schafft es, alle bekannten Sicherheitslücken zeitnah zu schließen. Der KEV-Katalog sagt: Fang hier an.
Der Mechanismus ist einfach. CISA sammelt Hinweise aus eigenen Analysen, Meldungen der Bundesbehörden, Informationen von Sicherheitsforschern und Berichten aus der Security-Community. Sobald eine Schwachstelle als aktiv ausgenutzt gilt, wandert sie in den Katalog. Parallel dazu erhalten FCEB-Agenturen (Federal Civilian Executive Branch) klare Deadlines für die Behebung – typischerweise zwei bis vier Wochen, je nach Kritikalität. Wer die Frist verpasst, hat ein ernstes Compliance-Problem.
Plot Twist: Der Katalog ist öffentlich zugänglich. Jede Organisation, jeder Security-Analyst, jeder Tool-Hersteller kann ihn nutzen. Es gibt sogar inoffizielle GitHub-Projekte, die den Katalog offline durchsuchbar machen – praktisch für Umgebungen mit eingeschränktem Internet-Zugang. Die Transparenz ist Absicht: CISA möchte, dass private Unternehmen die Daten verwenden, auch wenn sie technisch nicht an BOD 22-01 gebunden sind. Semantisch passt dazu unser Hintergrund Cybersicherheit Europa 2025: Netskope Threat Labs Report deckt alarmierende Trends auf.
Unter den jüngsten Ergänzungen stechen besonders acht Known Exploited Vulnerabilities hervor, die kritische Infrastrukturen unmittelbar betreffen. Sie decken ein breites Spektrum ab: Von Browser-Engines über Netzwerkgeräte bis hin zu Enterprise-Software. Jede einzelne ist für sich genommen brisant – in Kombination ergeben sie ein Bild der aktuellen Bedrohungslandschaft, das man sich genau ansehen sollte.
Zwei der neuesten Ergänzungen betreffen Google Chrome direkt: CVE-2026-3909 in der Skia-Grafikbibliothek (Out-of-Bounds Write, CVSS 8.8) und CVE-2026-3910 in der V8-JavaScript-Engine (ebenfalls CVSS 8.8). Beide ermöglichen Remote Code Execution – ein Angreifer muss das Opfer lediglich dazu bringen, eine manipulierte HTML-Seite zu öffnen. Security Affairs berichtet, dass FCEB-Agenturen umgehend patchen müssen.
Das Szenario ist simpel und deshalb so gefährlich: Eine Phishing-Mail, ein kompromittierter Werbebanner, ein manipulierter Link in einer Slack-Nachricht – fertig ist der Angriff. Chrome ist mit einem Marktanteil von über 65 Prozent der meistgenutzte Browser weltweit. Die Angriffsfläche bei diesen Known Exploited Vulnerabilities ist entsprechend gigantisch.
Das Pikante daran: Beide Lücken wurden nicht erst entdeckt und dann ausgenutzt. CISA-Einträge belegen aktive Exploitation bereits vor der öffentlichen Bekanntmachung. Zero-Day-Nutzung durch vermutlich staatlich gesponserte Akteure, bevor ein Patch verfügbar war. Update-Disziplin ist hier keine Option, sondern Überlebensstrategie.
Fortinet-Produkte tauchen im KEV-Katalog mit beunruhigender Regelmäßigkeit auf. Die jüngst aufgenommenen Lücken betreffen FortiOS und FortiGate – Produkte, die gerade in kritischen Infrastrukturen flächendeckend eingesetzt werden. OS-Command-Injection und Path-Traversal-Schwachstellen dominieren hier. Ein Angreifer mit Netzwerkzugang kann ohne gültige Credentials Befehle auf dem Zielsystem ausführen oder auf geschützte Dateipfade zugreifen.
Das Angriffsszenario bei Fortinet-Known-Exploited-Vulnerabilities läuft oft so ab: Erstinfizierung über eine exponierte Admin-Oberfläche, dann laterale Bewegung ins interne Netzwerk. Ransomware-Gruppen lieben diesen Weg – er ist effizient, skalierbar und erfordert keine ausgefeilten Exploits, wenn der initiale Zugangspunkt bereits bekannt und öffentlich dokumentiert ist.
Wenig überraschend finden sich Fortinet-Lücken auch unter den 24 neu aufgenommenen Ransomware-assoziierten Einträgen des Jahres 2025. Wer FortiGate betreibt und noch nicht gepatcht hat, sitzt buchstäblich auf einer Zeitbombe, deren Zündschnur bereits brennt.
Microsoft dominiert den KEV-Katalog quantitativ. Neu aufgenommen wurden unter anderem Schwachstellen in Windows-Kernkomponenten: Use-after-Free-Fehler, die Privilege Escalation von Standard-User auf SYSTEM ermöglichen, sowie Out-of-Bounds-Write-Lücken in Treiber-Code, die Kernel-Exploits erlauben. Das klassische Angriffsmuster: Erstinfizierung über einen anderen Vektor (Phishing, Browser-Exploit), dann Privilege Escalation über eine dieser Known Exploited Vulnerabilities.
Besonders beunruhigend ist die Aufnahme von CVE-2007-0671 – einer Microsoft-Office-Schwachstelle aus dem Jahr 2007. Das ist kein Tippfehler. 2007. Die Lücke wird offenbar noch immer aktiv ausgenutzt, weil Legacy-Systeme in kritischen Infrastrukturen schlicht nicht aktualisiert werden können oder werden. Industriesteuerungen, medizinische Geräte, SCADA-Systeme – sie alle laufen manchmal auf Software-Ständen, die in der EU noch unter Sarkozy und vor dem iPhone-Launch verbreitet waren.
Die verbleibenden fünf der acht hervorgehobenen Schwachstellen betreffen Enterprise-Lösungen, die in kritischen Infrastrukturen besonders häufig anzutreffen sind. Ivanti-Produkte (VPN-Gateways, MDM-Lösungen) wurden 2025 gleich mehrfach im KEV-Katalog gelistet. SonicWall-Firewalls tragen Lücken in der Fernzugriffsverwaltung. SAP-Systeme – das Rückgrat vieler Industriekonzerne – weisen Deserialisierungslücken auf, die Remote Code Execution ermöglichen.
Mitel-Kommunikationssysteme runden das Bild ab. Unified-Communications-Plattformen sind häufig schlecht in das reguläre Patch-Management einbezogen, weil sie als „Telefonanlage“ und nicht als kritische IT-Infrastruktur wahrgenommen werden. Plot Twist: Genau diese Unterschätzung macht sie zu bevorzugten Angriffszielen.
Der KEV-Katalog ist nicht nur eine technische Sammlung – er ist auch ein Lagekarte der Bedrohungsakteure. Von den 1.484 Einträgen sind 230 mit Ransomware-Gruppen verknüpft. 24 davon wurden 2025 neu aufgenommen. Acht dieser Lücken werden von mehr als zehn verschiedenen Ransomware-Gruppen gleichzeitig ausgenutzt – ein Zeichen dafür, dass entsprechende Exploit-Toolkits im Untergrund weit verbreitet sind.
Auf der APT-Seite sieht es nicht besser aus: 240 Known Exploited Vulnerabilities tragen eine APT-Verknüpfung. Mehr als 50 Prozent davon werden von mehreren Gruppen genutzt, was auf eine Praxis des Exploit-Sharings und des Kaufs von Zugangsdaten im Darknet hindeutet. Securin analysiert, dass China-nahe APT-Gruppen den KEV-Katalog quantitativ dominieren, gefolgt von russischen Akteuren – allen voran APT29/Nobelium mit 53 verknüpften Lücken.
Das ist keine abstrakte Bedrohung. APT29 ist dieselbe Gruppe, die für den SolarWinds-Angriff und den Microsoft-Exchange-Hack verantwortlich gemacht wird. Wenn diese Gruppe 53 spezifische Lücken aus dem KEV-Katalog aktiv einsetzt, dann ist die Frage nicht ob, sondern wann ein ungepatchtes System damit kompromittiert wird.
Für kritische Infrastrukturen ist die Kombination aus Ransomware-Gruppen und APT-Akteuren besonders gefährlich. Erstere wollen Geld. Letztere wollen Daten, Sabotage oder langfristigen Zugang. Ein Angriff auf ein Energieversorgungsunternehmen oder ein Krankenhaus kann beides gleichzeitig bedeuten – oder einer der Akteure bereitet lediglich den Weg für den anderen vor, indem er initialen Zugang verkauft.
Wenn man die 2025 neu aufgenommenen Known Exploited Vulnerabilities nach Typ klassifiziert, ergibt sich ein klares Muster. CISA dokumentiert acht dominante Schwachstellenklassen für das laufende Jahr:
Was diese Liste so beunruhigend macht: Keine dieser Schwachstellenklassen ist neu. OS-Command-Injection ist seit den 1990er Jahren bekannt und dokumentiert. Path Traversal genauso. Die OWASP Top 10 sprechen diese Typen seit über zwei Jahrzehnten an. Und trotzdem landen sie 2025 als aktiv ausgenutzte Known Exploited Vulnerabilities im CISA-Katalog. Das sagt mehr über den Zustand der Software-Entwicklung und des Patch-Managements aus als über die Kreativität der Angreifer.
Meine persönliche Meinung dazu: Wer angesichts dieser Liste noch argumentiert, dass Security-by-Design zu teuer oder zu aufwendig sei, hat schlicht die Prioritäten falsch gesetzt. Die Kosten eines erfolgreichen Ransomware-Angriffs auf kritische Infrastruktur übersteigen die Kosten sauberer Entwicklungspraktiken um Größenordnungen.
Der Begriff „kritische Infrastruktur“ klingt abstrakt. Er meint: Energieversorgung, Wasserwerke, Krankenhäuser, Telekommunikation, Finanzdienstleister, Verkehrsleitsysteme. Systeme, deren Ausfall unmittelbare gesellschaftliche Konsequenzen hat. Und genau diese Systeme sind bei Known Exploited Vulnerabilities überproportional gefährdet – aus einem simplen Grund: Sie können oft nicht einfach gepatcht werden.
Ein Krankenhaus kann seinen Radiologie-Server nicht für vier Stunden offline nehmen, um ein Windows-Update einzuspielen, wenn währenddessen Patienten auf Notaufnahme-Ergebnisse warten. Ein Stromversorger kann seine SCADA-Steuerung nicht unkontrolliert neu starten, um Firmware-Updates einzuspielen. Diese betrieblichen Restriktionen sind real und legitim – aber sie schaffen genau die Lücken, die Angreifer ausnutzen.
Hinzu kommt das Legacy-Problem. Kritische Infrastrukturen betreiben oft Systeme mit Laufzeiten von 15, 20 oder 30 Jahren. Industriesteuerungen von Siemens oder ABB, die Ende der 1990er Jahre installiert wurden und auf Betriebssystemversionen laufen, für die es keine Updates mehr gibt. Diese Systeme tauchen nicht im Patch-Management auf, weil der Hersteller keine Patches mehr liefert – aber sie sind im Netzwerk, sie sind erreichbar, und sie haben Schwachstellen, von denen manche inzwischen im KEV-Katalog stehen. Semantisch passt dazu unser Hintergrund Digitale Fertigung: Siemens und TRUMPF schmieden Allianz für die Smart Factory der Zukunft.
Das Angriffsszenario für kritische Infrastruktur läuft typischerweise in mehreren Phasen ab. Erstinfizierung über eine exponierte Schwachstelle – oft eine der Known Exploited Vulnerabilities aus dem CISA-Katalog. Dann Persistenz herstellen, laterale Bewegung im Netzwerk, Reconnaissance der IT/OT-Schnittstellen. Erst dann kommt die eigentliche Nutzlast: Ransomware, Sabotage oder stille Datenexfiltration über Monate.
Der Clou: Zwischen Erstinfizierung und Entdeckung vergehen im Durchschnitt noch immer über 200 Tage. Das gibt Angreifern reichlich Zeit, sich tief im Netzwerk zu verankern, bevor irgendjemand merkt, dass etwas nicht stimmt.
Die Binding Operational Directive 22-01 ist ein US-amerikanisches Instrument. Sie bindet ausschließlich Federal Civilian Executive Branch Agencies – also US-Bundesbehörden. Für europäische Unternehmen und Behörden gibt es keine direkte rechtliche Verpflichtung, den KEV-Katalog zu beachten. Aber: Die EU-Gesetzgebung nähert sich diesem Modell an.
NIS2 – die überarbeitete Richtlinie zur Netzwerk- und Informationssicherheit – verpflichtet EU-Mitgliedsstaaten seit Oktober 2024 zur Umsetzung in nationales Recht. Sie schreibt für Betreiber kritischer Infrastrukturen unter anderem ein aktives Schwachstellenmanagement vor. Das schließt zwar keine explizite Referenz auf den KEV-Katalog ein, aber die inhaltliche Anforderung ist deckungsgleich: Bekannte, aktiv ausgenutzte Schwachstellen müssen priorisiert und zeitnah behoben werden.
Wenig überraschend ist der KEV-Katalog in der Praxis längst zu einem De-facto-Standard geworden, der weit über die USA hinaus genutzt wird. SIEM-Anbieter integrieren ihn in ihre Threat-Intelligence-Feeds. Schwachstellenscanner wie Tenable Nessus und Qualys VMDR nutzen KEV-Daten zur Priorisierung. Managed-Security-Dienste berichten ihren Kunden explizit über KEV-Expositionen. Der Katalog hat eine normative Wirkung entwickelt, die weit über seinen rechtlichen Anwendungsbereich hinausgeht.
Konkret bedeutet das für deutsche Unternehmen und Behörden: Wer kritische Infrastruktur betreibt und den KEV-Katalog ignoriert, handelt fahrlässig – auch ohne dass BOD 22-01 formell gilt. Die Lücken werden ausgenutzt. Die Angreifer lesen dieselben Kataloge wie die Verteidiger. Wer nicht patcht, wählt aktiv das Risiko.
Der KEV-Katalog ist als Priorisierungswerkzeug konzipiert. Wie nutzt man ihn in der Praxis? Hier ist ein konkreter Ansatz für Security-Teams, die mit begrenzten Ressourcen und einem realen Patch-Rückstand arbeiten:
Ohne vollständiges Asset-Inventar ist jedes Schwachstellenmanagement wirkungslos. Der erste Schritt ist daher die Erhebung aller Software-Komponenten, Betriebssystemversionen und Firmware-Stände in der Infrastruktur. Moderne CMDB-Tools und Discovery-Scanner können dabei helfen, aber in komplexen OT/IT-Umgebungen ist manuelle Erhebung oft unvermeidlich.
Mit dem Inventar in der Hand folgt der Abgleich gegen den KEV-Katalog. CISA stellt den Katalog als maschinenlesbare JSON-Datei bereit – integrierbar in Vulnerability-Management-Plattformen oder per Skript abfragbar. Für jedes identifizierte Asset: Gibt es eine oder mehrere zugehörige CVE-Einträge im KEV-Katalog? Wenn ja, hat diese Schwachstelle die höchste Priorität.
Nicht alle Known Exploited Vulnerabilities sind gleich gefährlich. Ein CVSS-Score von 8.8 ist bedeutsam, aber der Kontext entscheidet. Ist das betroffene System intern oder extern erreichbar? Verarbeitet es sensitive Daten oder Steuerungssignale? Gibt es Kompensationskontrollen (Firewall-Regeln, Segmentierung, EDR)?
Eine sinnvolle Risikobewertung kombiniert den KEV-Status (aktiv ausgenutzt: ja/nein), den CVSS-Score, die Erreichbarkeit des Systems, die Geschäftskritikalität und verfügbare Kompensationskontrollen. Nur diese Kombination ergibt eine sinnvolle Patch-Priorität. Ein CVSS-9-Fehler auf einem air-gapped System ohne externe Erreichbarkeit ist weniger dringend als ein CVSS-7-Fehler auf einem externen Web-Server mit direktem Internet-Zugang.
Gerade in kritischen Infrastrukturen ist die Frage nicht nur „Wie patchen?“ sondern „Wann patchen, ohne den Betrieb zu gefährden?“. Bewährt haben sich dedizierte Wartungsfenster, die mit dem Betrieb koordiniert werden, Rollback-Pläne für den Fall, dass ein Patch unerwartete Seiteneffekte hat, sowie Testinstanzen, auf denen kritische Patches vor dem Produktiv-Einsatz validiert werden.
Für Systeme, bei denen ein sofortiger Patch nicht möglich ist, greifen virtuelle Patches – Regeln auf WAF, IDS/IPS oder Netzwerk-Segmentierungsebene, die spezifische Angriffsvektoren blockieren, bis ein regulärer Patch eingespielt werden kann. Das ist kein Dauerzustand, aber eine legitime Übergangslösung.
Patchen allein reicht nicht. Security-Teams müssen verifizieren, dass der Patch tatsächlich erfolgreich eingespielt wurde und die Schwachstelle nicht mehr vorhanden ist. Vulnerability-Scans nach dem Patchen sind Standard. Zusätzlich empfiehlt sich die Integration der CVE-IDs aus dem KEV-Katalog in SIEM-Alerts – so erkennt man sofort, wenn ein Exploit-Versuch gegen eine gelistete Schwachstelle stattfindet, auch auf bereits gepatchten Systemen (was auf ein Patch-Management-Problem hinweisen kann).
Wenn CISA den Katalog mit neuen Known Exploited Vulnerabilities erweitert – was im Jahr 2025 im Schnitt fast alle zwei Tage passiert – brauchen Security-Teams einen definierten Reaktionsprozess. Folgende Checkliste hat sich in der Praxis bewährt:
Das klingt nach viel. Ist es auch. Aber es ist weniger Aufwand als die Bewältigung eines erfolgreichen Ransomware-Angriffs auf kritische Infrastruktur, der im Schnitt mehrere Millionen Euro Schaden verursacht und Wochen bis Monate Wiederherstellungszeit erfordert.
Der KEV-Katalog entfaltet seinen vollen Nutzen erst in Kombination mit vorhandenen Security-Tools. Die gute Nachricht: Die Integration ist weitgehend standardisiert und in den meisten modernen Security-Plattformen bereits vorgesehen.
Vulnerability-Management-Plattformen wie Tenable.io, Qualys VMDR oder Rapid7 InsightVM markieren Known Exploited Vulnerabilities automatisch, sobald CISA einen Eintrag hinzufügt. Der KEV-Status ist dort ein eigenes Priorisierungsattribut, das unabhängig vom CVSS-Score abgefragt werden kann. Filter wie „zeige mir alle KEV-Lücken in meiner Infrastruktur, sortiert nach Erreichbarkeit“ sind standardmäßig verfügbar.
SIEM-Systeme wie Splunk, Microsoft Sentinel oder IBM QRadar können die KEV-Daten als Threat-Intelligence-Feed importieren. Eingehende Log-Ereignisse werden dann automatisch gegen die CVE-Liste abgeglichen – erkennt das SIEM einen Exploit-Versuch gegen eine KEV-Lücke, löst es einen High-Priority-Alert aus. Das ist besonders wertvoll für die Früherkennung von Angriffen auf noch ungepatchte Systeme.
EDR-Lösungen wie CrowdStrike Falcon oder Microsoft Defender for Endpoint haben KEV-Daten ebenfalls integriert. Verhaltensbasierte Erkennung wird mit CVE-spezifischen Exploit-Signaturen kombiniert, was die Erkennungsrate für aktiv ausgenutzte Lücken erhöht. Das ist kein Ersatz für Patching, aber eine wichtige Erkennungsebene.
Für kleinere Organisationen ohne Enterprise-Security-Stack gibt es preisgünstigere Optionen. Der CISA-Katalog ist als CSV und JSON frei downloadbar. Einfache Skripte – Python, PowerShell – können das Asset-Inventar gegen die KEV-Liste abgleichen und Reports generieren. Die Community hat dafür entsprechende Open-Source-Tools entwickelt, die auf GitHub verfügbar sind.
245 neue Known Exploited Vulnerabilities in einem Jahr. Das ist keine Erfolgsmeldung für die Cybersecurity-Branche. Es ist ein Symptom. Aber wofür genau?
Erstens: Die Angriffsfläche wächst schneller als die Verteidigungsfähigkeiten. Mehr Software, mehr Vernetzung, mehr Geräte – und damit mehr potenzielle Schwachstellen. Die Digitalisierung kritischer Infrastrukturen, die Einführung von IIoT und die Konvergenz von IT und OT-Netzwerken schaffen neue Angriffsvektoren in einem Tempo, das klassisches Patch-Management schlicht nicht abbilden kann.
Zweitens: Die Qualität von Software-Entwicklungsprozessen ist nach wie vor unzureichend. OS-Command-Injection und Path Traversal in kommerzieller Enterprise-Software sind keine unvermeidbaren Komplexitätsprobleme – sie sind Fehler, die bei ausreichend strikten Code-Reviews und automatisierten SAST-Scans in der CI/CD-Pipeline auffallen würden. Dass sie trotzdem in Produkten landen, die in kritischen Infrastrukturen eingesetzt werden, ist ein Hinweis auf ökonomischen Druck, der Security-by-Design verdrängt.
Drittens – und das ist der wirklich unbequeme Teil: Der Markt bestraft mangelnde Sicherheit nicht ausreichend. Hersteller, deren Produkte regelmäßig im KEV-Katalog auftauchen, verlieren in der Regel keine signifikanten Marktanteile. Procurement-Entscheidungen in Organisationen basieren auf Features, Preis und Vendor-Beziehungen – Security-Track-Record ist selten ein ausschlaggebendes Kriterium.
Die Biden-Regierung hatte versucht, hier gegenzusteuern: Executive Order 14028 und die dazugehörigen CISA-Richtlinien haben Software-Hersteller stärker in die Pflicht genommen. Das Konzept „Secure by Design“ wird von CISA aktiv propagiert. Ob sich das langfristig auf die Wachstumsrate des KEV-Katalogs auswirkt, wird man in einigen Jahren sehen.
Ein Argument, das gelegentlich zu hören ist: Veröffentlicht CISA mit dem KEV-Katalog nicht eine priorisierte Angriffsliste für Cyberkriminelle? Wenn bekannt ist, welche Lücken aktiv ausgenutzt werden und welche Systeme betroffen sind, können Angreifer gezielter vorgehen.
Das Argument klingt intuitiv plausibel, ist aber bei näherer Betrachtung schwach. Erstens: Angreifer kennen die ausnutzbaren Lücken bereits. Sie haben sie ja gefunden und ausgenutzt – das ist die Voraussetzung für die KEV-Aufnahme. Die Information fließt von Angreifern zu CISA, nicht umgekehrt. Der Katalog macht Verteidigern zugänglich, was in der Angreifer-Community schon bekannt ist.
Zweitens: Security through Obscurity funktioniert nicht. Wer darauf angewiesen ist, dass Angreifer seine Schwachstellen nicht kennen, hat bereits verloren. Die einzig wirksame Verteidigung ist das tatsächliche Schließen der Lücken.
Drittens: Die empirische Evidenz spricht für Transparenz. Studien zeigen, dass Schwachstellen, die öffentlich dokumentiert sind, schneller gepatcht werden als solche, die im Verborgenen bleiben. Der Druck auf Administratoren und Hersteller steigt, wenn eine Lücke öffentlich als aktiv ausgenutzt gilt. Dieser Effekt überwiegt das theoretische Risiko der „Angreiferunterstützung“ bei weitem.
Bei einem Zuwachs von 245 Einträgen im Jahr 2025 – dem höchsten seit Launch 2021 – stellt sich die Frage: Wohin geht die Reise? Wird der Katalog weiter wachsen, oder ist eine Konsolidierung in Sicht?
Die Antwort ist komplex. Einerseits wächst die Angriffsfläche durch Digitalisierung und IIoT weiter. Andererseits verbessern sich Threat-Intelligence-Mechanismen, sodass Lücken schneller identifiziert und gelistet werden – was das Wachstum kurzfristig erhöht, aber die Reaktionszeit verkürzt. Langfristig könnte ein stärkerer regulatorischer Druck auf Hersteller (Secure by Design, EU Cyber Resilience Act) die Basis der entstehenden Schwachstellen verringern.
Was sicher zunehmen wird: die Integration des KEV-Katalogs in regulatorische Frameworks weltweit. NIS2 in der EU, der Cyber Resilience Act, nationale Sicherheitsrahmen – sie alle bewegen sich in Richtung einer verbindlicheren Referenz auf aktiv ausgenutzte Schwachstellen als Patch-Pflicht. Der KEV-Katalog könnte in einigen Jahren so etwas wie ein globaler Standard für Patch-Priorisierung werden, auch außerhalb der USA.
Meine persönliche Einschätzung: Das ist überfällig. Ein Werkzeug, das kostenlos verfügbar ist, auf echter Bedrohungsintelligenz basiert und direkt umsetzbare Priorisierungen liefert, sollte in jeder Organisation genutzt werden, die sich ernsthaft mit IT-Sicherheit befasst – unabhängig von Größe und Standort. Dass es das noch nicht ist, liegt nicht an mangelnder Verfügbarkeit, sondern an mangelnder Priorisierung.
Der CISA Known Exploited Vulnerabilities-Katalog ist 2025 auf 1.484 Einträge gewachsen. 245 neue Schwachstellen, 24 davon mit Ransomware-Verknüpfung, acht besonders relevant für kritische Infrastrukturen – von Chrome über Fortinet bis SAP. Die Bedrohungsakteure hinter diesen Known Exploited Vulnerabilities reichen von opportunistischen Ransomware-Gruppen bis zu staatlich gesponserten APT-Akteuren mit 53 gelisteten Lücken im Portfolio.
Die technische und organisatorische Antwort darauf ist bekannt: Asset-Inventarisierung, KEV-Abgleich, priorisiertes Patching, Kompensationskontrollen für ungepatchte Systeme, Integration in SIEM und Vulnerability-Management, klare Reaktionsprozesse bei neuen Katalog-Ergänzungen. Das ist kein Geheimwissen, es ist dokumentierter Best Practice.
Was bleibt, ist die eigentlich entscheidende Frage: Warum werden diese Schritte in so vielen Organisationen, die kritische Infrastruktur betreiben, noch immer nicht konsequent umgesetzt – obwohl die Bedrohung dokumentiert, die Werkzeuge kostenlos verfügbar und die Konsequenzen eines Angriffs hinreichend dramatisch sind? Und: Wird der EU Cyber Resilience Act zusammen mit NIS2 den Druck erzeugen, der nötig ist, um diese Lücke zwischen bekanntem Risiko und tatsächlicher Handlung endlich zu schließen?
Der Katalog wächst weiter. Die Angreifer aktualisieren ihre Tools. Und in zu vielen Maschinenhallen, Serverräumen und Rechenzentren wartet CVE-2007-0671 noch immer darauf, ausgenutzt zu werden.
