CVE-Veröffentlichungstrends

Im Jahr 2025 wurden 47.802 CVE-Einträge veröffentlicht, 20 % mehr als im Vorjahr. 2026 hat bereits 88.746 erreicht, und es stehen noch Monate aus.

Das Volumen ist seit dem Start des CVE Program jedes Jahr gewachsen, aber die Wachstumsrate hat sich 2026 stark verändert. Im Diagramm oben sehen Sie den Trend nach Monat, Quartal oder Jahr.

Auf dieser Seite. Das Diagramm und die Kennzahlen oben sind CVE-Statistiken, die täglich aus dem Repository cvelistV5 des CVE Program neu erstellt werden, derselben Quelle, aus der das CVE Program veröffentlicht.

Sie decken das Veröffentlichungsvolumen nach CVSS-Schweregrad, nach vergebender Organisation und nach Woche, Monat, Quartal oder Jahr ab, dazu die neuesten kritischen Einträge. Details zu einer einzelnen Schwachstelle erhalten Sie, wenn Sie einer Kennung zu cve.org folgen.

Drei Dinge geschehen gleichzeitig, und die veröffentlichten Einträge können sie nicht voneinander trennen.

Mehr Organisationen können heute CVE-IDs vergeben, sodass Schwachstellen erfasst werden, die zuvor nie registriert wurden. Automatisierte und KI-gestützte Schwachstellensuche hat erhöht, wie viel ein einzelner Forscher finden kann. Und das Anreicherungsprogramm von CISA hat ältere Einträge nachträglich ergänzt, was historische Zahlen im Nachhinein verändert.

Steigende CVE-Zahlen sind daher für sich genommen kein Beleg dafür, dass Software unsicherer wird.

Eine CNA ist eine Organisation, die befugt ist, innerhalb ihres eigenen Bereichs, meist ihrer eigenen Produkte, CVE-IDs zu vergeben und Einträge zu veröffentlichen. 497 CNAs kommen in diesem Datensatz vor.

Hersteller, Open-Source-Projekte, Bug-Bounty-Plattformen und nationale CERTs treten alle als CNAs auf. Die größte hier ist mitre mit 39.586 Einträgen. Da eine einzelne CNA die Gesamtzahlen spürbar bewegen kann, wenn sie ihren Prozess ändert, lässt sich das Diagramm auf jeweils eine Organisation filtern.

CVSS bewertet eine Schwachstelle von 0,0 bis 10,0 und ordnet sie in Bänder ein: Niedrig (0,1–3,9), Mittel (4,0–6,9), Hoch (7,0–8,9) und Kritisch (9,0–10,0).

Der Score beschreibt inhärente technische Merkmale, etwa wie die Schwachstelle erreicht wird und was sie kompromittiert. Er ist kein Maß dafür, wie stark eine bestimmte Organisation gefährdet ist.

18.0% der seit 2020 veröffentlichten Einträge haben weder in den eigenen Daten der CNA noch in der Anreicherung von CISA einen CVSS-Score.

Während des Großteils der Geschichte des CVE Program war eine Bewertung nicht vorgeschrieben. Die Abdeckung verbessert sich ab 2023 stark und ist heute nahezu vollständig, das Schrumpfen des Bandes Unbekannt im Diagramm spiegelt also eine geänderte Meldepraxis wider, nicht eine Veränderung der Schwachstellen selbst. Jede Analyse, die Einträge ohne Score ignoriert, unterschätzt ältere Jahre.

Eine Schwachstelle ist ein Fehler in Software. Eine CVE ist eine öffentliche Kennung, die einem bestimmten, offengelegten Fall davon zugewiesen wird.

Die meisten Schwachstellen erhalten nie eine CVE: Sie werden intern gefunden und behoben oder fallen in den Bereich keiner CNA. CVE-Zahlen messen daher die Offenlegungsaktivität, nicht die tatsächliche Menge vorhandener Fehler.

Jede Zahl stammt aus dem offiziellen Repository cvelistV5 des CVE Program, auf Basis des Snapshots vom 31.10.2026 UTC.

Einträge werden nach Veröffentlichungsdatum gezählt, nicht nach dem Jahr in der CVE-ID, denn etwa ein Fünftel der Einträge wird in einem anderen Jahr veröffentlicht als dem, das ihre Kennung nennt. Abgelehnte und zurückgezogene Einträge sind ausgeschlossen.

Für sich genommen nicht. Eine kritische Schwachstelle in einer Komponente, die Sie ausliefern, aber nie aufrufen, kann weniger dringend sein als eine mittlere in Ihrer öffentlichen API.

Für eine echte Priorisierung müssen Sie wissen, ob die betroffene Komponente in Ihrer Software vorhanden ist, ob der verwundbare Code erreichbar ist und ob die Schwachstelle ausgenutzt wird. Auf nichts davon gibt CVSS eine Antwort.

Der CRA verlangt von Herstellern, Schwachstellen während des gesamten Unterstützungszeitraums eines Produkts zu behandeln, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an ENISA zu melden und die technische Dokumentation aktuell zu halten.

Diese Pflichten skalieren mit dem Volumen in diesem Diagramm. Zehntausende neue Einträge pro Jahr manuell gegen Ihre eigene Software zu sichten, ist nicht realistisch, weshalb der CRA faktisch eine SBOM und einen automatisierten Abgleich voraussetzt.

Sie brauchen ein genaues Inventar dessen, was Ihre Software enthält, und einen laufenden Abgleich dieses Inventars mit dem CVE-Feed.

CRACI erzeugt eine SBOM aus Ihrem Build, gleicht sie bei ihrer Veröffentlichung mit neuen CVE-Einträgen ab und zeigt nur die Advisories, die Code erreichen, den Sie tatsächlich ausliefern, zusammen mit der Dokumentation, die Sie laut CRA aufbewahren sollen.

Sehen Sie, wie Schwachstellenverfolgung in der Praxis funktioniert.