Viele Unternehmen kennen das Problem: Der Schwachstellen-Scanner produziert mehr Findings, als Betrieb, Entwicklung und Security sauber abarbeiten können. Bisher ließ sich dieses Rauschen oft mit Schweregrad, Asset-Kritikalität und Patch-Zyklen halbwegs steuern. Die neue Zwischenprognose des Forum of Incident Response and Security Teams (FIRST) zeigt nun: Die Größenordnung verändert sich. Nicht, weil Software über Nacht deutlich unsicherer geworden wäre. Sondern weil Schwachstellen schneller gefunden, katalogisiert und nachgemeldet werden.
FIRST veröffentlichte am 15. Juni 2026 seinen „Mid-Year Vulnerability Forecast“. Die Kernaussage: Von Januar bis April lagen die tatsächlichen CVE-Veröffentlichungen bereits 46,3 Prozent über der Prognose, die FIRST erst im Februar vorgelegt hatte. Für das Gesamtjahr rechnet die Organisation nun mit rund 66.000 CVEs. Der zugehörige GitHub-Report nennt als Modellwert 65.632 Einträge und legt Methodik, Datenquellen und Skripte offen. Für Unternehmen ist das mehr als Statistik. Wenn sich die Zahl öffentlich erfasster Schwachstellen in dieser Größenordnung bewegt, wird Priorisierung zum eigentlichen Sicherheitsproblem.
Entscheidend ist, was hinter dem Anstieg steht. FIRST nennt drei strukturelle Treiber: KI-gestützte Schwachstellensuche, stark wachsende GitHub Security Advisories und eine massive Zunahme der VulnCheck-Aktivität als CNA of Last Resort — also als Stelle, die bislang unzugeordnete Schwachstellen nacherfasst. Laut FIRST stieg das GHSA-Volumen im Jahresvergleich um 449 Prozent. Die VulnCheck-Aktivität legte sogar um 3.119 Prozent zu. Ein Teil der CVE-Flut ist damit bessere Sichtbarkeit und Aufräumarbeit. Er steht nicht automatisch für neue Exploit-Wellen.
Der KI-Anteil ist dennoch real. FIRST verweist auf eine 164-prozentige Zunahme der Q1-CVE-Veröffentlichungen aus dem Mozilla-CNA-Kontext, zurückgeführt auf KI-gestützte Analysen gegen die Firefox-Engine. Help Net Security bewertet die Entwicklung ähnlich: Autonome Discovery-Agenten und spezialisierte Cyber-Modelle werden Teil des Disclosure-Ökosystems. Frühere Einzelbeispiele — etwa KI-Analysen in großen C/C++-Codebasen — werden damit zu einem messbaren Branchentrend.
Die zweite zentrale Aussage fällt beruhigender aus, bleibt aber anspruchsvoll: FIRST unterscheidet zwischen „Rain“ und „Flood“. Der Regen ist die stark wachsende Gesamtzahl an CVEs. Die Flut sind Schwachstellen, die tatsächlich aktiv ausgenutzt werden oder mit hoher Wahrscheinlichkeit kurzfristig relevant werden. Nach FIRST bleibt diese actionable burden bislang relativ flach, wenn man nach CISA Known Exploited Vulnerabilities oder EPSS-Werten über zehn Prozent filtert. Der GitHub-Report dokumentiert den Datenstand: 1.587 KEV-Einträge und 329.934 mit EPSS bewertete CVEs zum Stichtag 1. Mai 2026.
Für die Praxis ist genau diese Trennung entscheidend. Ein Security-Team, das jede CVE gleich behandelt, wird 2026 scheitern. Ein Team, das nur auf den CVSS-Score schaut, setzt ebenfalls falsche Prioritäten. CVSS beschreibt technische Schwere, nicht die konkrete Wahrscheinlichkeit, dass eine Schwachstelle im eigenen Umfeld ausgenutzt wird. EPSS und CISA KEV liefern keine perfekte Wahrheit. Sie helfen aber, Ausnutzbarkeit und reale Angreiferaktivität in die Entscheidung einzubeziehen.
Der Branchenfokus verschiebt sich damit vom reinen Finden zum Verifizieren, Koordinieren und Schließen. KI kann alte Codepfade schneller prüfen, Varianten bekannter Fehlerklassen finden und Reports vorbereiten. Sie entscheidet aber nicht automatisch, ob ein Finding in einer produktiven Architektur erreichbar ist, ob ein Patch geschäftskritische Prozesse gefährdet oder welche Ausnahme regulatorisch vertretbar ist. Der Engpass liegt zunehmend bei Ownership, Testbarkeit und Veränderungsgeschwindigkeit.
Für Unternehmen ergeben sich daraus klare Konsequenzen. Erstens braucht Vulnerability Management ein belastbares Asset-Inventar. Ohne saubere Zuordnung von Software, Version, Exposition und Geschäftsprozess bleibt jede Priorisierung unscharf. Zweitens sollten Schwachstellendaten mit Exploitability-Overlays kombiniert werden: KEV, EPSS, Internet-Exposition, Privilegien, vorhandene Kontrollen und beobachtete Angriffsaktivität gehören in dieselbe Entscheidungsmatrix. Drittens müssen Patch-Spuren differenziert werden. Internetnahe Systeme, Identitätskomponenten, CI/CD-Plattformen, Agenten-Gateways und zentrale Bibliotheken brauchen andere Reaktionszeiten als isolierte interne Anwendungen.
Viertens sollten Hersteller und interne Entwicklungsteams mit mehr validen Reports pro Release-Zyklus rechnen. Das betrifft nicht nur große Softwareanbieter. Auch interne Plattformteams, die APIs, Automatisierungen oder KI-Workflows betreiben, werden häufiger Findings aus automatisierten Analysen sehen. Sinnvolle Kennzahlen sind deshalb nicht nur „offene CVEs“. Wichtiger werden Zeit bis zur Triage, Anteil reproduzierbarer Findings, Zeit bis zum getesteten Fix und Anteil risikobasierter Ausnahmen.
Besonders relevant ist das für DevSecOps-Organisationen, die bereits viele automatisierte Prüfungen einsetzen. Wenn SAST, Dependency-Scanning, Container-Scanning, Cloud-Security-Posture-Management und KI-gestützte Codeanalyse getrennte Ticketströme erzeugen, entsteht schnell ein organisatorischer Denial-of-Service gegen die eigenen Engineering-Teams. Besser ist ein gemeinsamer Risikobacklog mit klaren Regeln für Deduplizierung, akzeptierten False-Positive-Prozessen und technischer Evidenz. Ein Finding sollte möglichst zeigen, welches Paket, welcher Endpunkt, welche Laufzeitumgebung und welcher Angriffsweg betroffen sind. Erst dann kann ein Produktteam entscheiden, ob ein sofortiger Hotfix, ein Konfigurationswechsel, eine Netzwerkregel oder ein geplanter Release die richtige Antwort ist.
Die Prognose hat Grenzen. FIRST arbeitet mit Daten bis Ende April beziehungsweise Stichtagen Anfang Mai. Es handelt sich um eine Projektion, nicht um ein Naturgesetz. Backfills und veränderte Katalogisierungspraktiken können Zahlen verzerren. Eine stark steigende CVE-Zahl bedeutet nicht automatisch, dass jedes Unternehmen proportional mehr Notfallpatches durchführen muss. Umgekehrt wäre es riskant, den Trend als reines Datenbankrauschen abzutun. Wenn KI die Entdeckung beschleunigt, verkürzt sich auch die Zeit, in der unklare Findings unbeachtet liegen bleiben können.
Die wichtigste Lehre ist nüchtern: Unternehmen brauchen weniger Alarmismus und mehr Präzision. 66.000 CVEs in einem Jahr sind eine große Zahl. Sicherheitsrelevant wird sie aber erst durch Kontext. Welche Systeme sind erreichbar? Welche Schwachstellen werden aktiv ausgenutzt? Welche Produkte tragen kritische Geschäftsprozesse? Wo gibt es Kompensationsmaßnahmen? Und wer darf im Zweifel schnell patchen, isolieren oder abschalten?
Fazit: Die neue FIRST-Prognose markiert keinen Zusammenbruch des CVE-Systems, sondern seine nächste Belastungsprobe. KI macht Schwachstellen sichtbarer und erhöht den Druck auf die Prozesse dahinter. Wer weiterhin CVEs zählt, geht im Rauschen unter. Wer Exploitability, Asset-Kontext, klare Ownership und schnelle Remediation verbindet, kann die zusätzliche Sichtbarkeit nutzen — nicht als Paniksignal, sondern als besseren Input für belastbares Sicherheitsmanagement.
Quellen: FIRST, „Mid-Year Vulnerability Forecast“, 15. Juni 2026: ; GitHub-Report „CVE 2026 Half-Year Forecast Update“: ; Help Net Security, „AI vulnerability discovery is pushing 2026 CVEs toward 66,000“, 15. Juni 2026:
