Gefälschte CVEs, KI-generierte Berichte und die Notwendigkeit der Überprüfung

Überzeugende Schwachstellenberichte lassen sich immer kostengünstiger erstellen. Das verschärft die Folgen für Softwareverantwortliche und Sicherheitsteams. Im Juli 2026 wurden sechs CVEs zu SQLite veröffentlicht; zwei davon erhielten einen Schweregrad von 9,8. Die Berichte wirkten glaubwürdig: Sie beschrieben Speicherfehler und enthielten technische Erläuterungen sowie Proof-of-Concept-Code.

Die Forschenden von JFrog stellten jedoch fest, dass einige der in den Berichten genannten Funktionen in den betroffenen Versionen gar nicht vorhanden waren. Darüber hinaus ließ sich keine der Proof-of-Concept-Implementierungen (PoCs) nutzen, um die behaupteten Schwachstellen nachzustellen. Auf der CVE-Seite von SQLite heißt es derzeit, dass es sich bei diesen sechs Meldungen nicht um Fehler handelt; die CVE-Einträge wurden später zurückgewiesen.

Das Problem beschränkt sich nicht auf SQLite. Daniel Stenberg, der Maintainer von curl, schätzte im vergangenen Jahr, dass rund 20 % der eingehenden Sicherheitsmeldungen das Ergebnis von KI-generiertem Schrott waren. Die CVE-Nummerierungsstelle (CNA) von GitHub erhielt im Mai 2026 fast 4.000 CVE-Anfragen – etwa zehnmal so viele wie im Vorjahreszeitraum. GitHub führte diesen Anstieg weder auf KI zurück noch stellte das Unternehmen eine sinkende Qualität der Einreichungen fest. Die massive Zunahme des Volumens verdeutlicht jedoch die Überlastung des Prozesses zur Offenlegung von Schwachstellen.

KI erleichtert es, detaillierte Behauptungen über Schwachstellen aufzustellen; festzustellen, ob diese Behauptungen zutreffen, ist jedoch zeitaufwendig. Und sobald eine CVE in Sicherheitsfeeds und öffentliche Datenbanken aufgenommen wurde, bedeutet die Korrektur des ursprünglichen Eintrags nicht automatisch, dass auch jede Kopie korrigiert wird. Daher wächst der Bedarf, zwischen einer gemeldeten und einer technisch verifizierten Schwachstelle zu unterscheiden.

Was ist eine „gefälschte“ CVE?

Der Begriff „gefälschte CVE“ wird häufig für eine CVE verwendet, die wahrscheinlich fälschlicherweise gemeldet wurde. „Gefälscht“ bedeutet jedoch nicht zwangsläufig, dass jemand absichtlich irreführen wollte. Die Meldung kann etwa auf einer statischen Analyse beruhen, die eine Validierungsprüfung übersieht oder Eingaben fälschlich als vom Angreifer kontrollierbar interpretiert. Ein Bericht kann eine tatsächlich vorhandene Funktion beschreiben, aber einen ungültigen Angriffsweg behaupten. Eine Kennung (CVE-ID) kann vergeben und später wieder verworfen werden, wenn die gemeldete Bedingung tatsächlich keine Schwachstelle darstellte. Das unterscheidet sich von einem absichtlich erfundenen Bericht.

Auch ein Streitfall ist keine gefälschte CVE. Ein Anbieter kann die Einschätzung eines Forschenden zur Ausnutzbarkeit, zu den Bedrohungsgrenzen oder dazu infrage stellen, ob eine Funktion für die Verarbeitung nicht vertrauenswürdiger Eingaben vorgesehen war. Ein solcher Streit beweist jedoch nicht, dass sich der oder die Forschende geirrt hat. Und die Zurückweisung einer CVE bedeutet nicht zwangsläufig, dass sie erfunden wurde; sie kann auch wegen eines Duplikats oder aus administrativen Gründen zurückgewiesen werden. Eine CVE-Kennung ist zwar keine unabhängige technische Verifizierung, dennoch muss die Branche echte Meldungen ernst nehmen.

Warum gefälschte CVEs problematisch sind

Eines der Probleme, die wir beobachten, ist, dass Menschen mithilfe von KI Schwachstellenberichte erstellen, ohne die Ergebnisse angemessen zu überprüfen. Diese Berichte können detaillierte technische Erläuterungen, Verweise auf Code und sogar PoCs enthalten, wodurch sie glaubwürdig wirken. Wie die CVEs zu SQLite jedoch gezeigt haben, existierten einige der erwähnten Funktionen in den betroffenen Versionen überhaupt nicht.

GitHub meldete 2026 einen deutlichen Anstieg der Schwachstellenmeldungen, führte diesen jedoch weder auf KI zurück noch berichtete das Unternehmen von einer sinkenden Qualität der Einreichungen. Die Sorge besteht darin, dass mit der Zahl der Berichte auch der Aufwand für ihre Untersuchung steigt – unabhängig davon, ob die Befunde zutreffen.

Wer schon einmal Schwachstellenmeldungen bewertet hat, weiß, wie schwierig das in der Praxis sein kann. Ein KI-Modell kann einen verdächtigen API-Aufruf erkennen, ein mögliches Angriffsszenario skizzieren und schnell einen professionell wirkenden Bericht verfassen. Um festzustellen, ob dieses Szenario umsetzbar ist, muss man möglicherweise die genaue Version prüfen, den Kontrollfluss nachverfolgen, nachvollziehen, wie Daten die Funktion erreichen, eine Testumgebung einrichten und den angeblichen Exploit ausführen. Unabhängig davon, ob der Bericht zutrifft, ist derselbe Prozess erforderlich – und das kann teuer werden.

Gefälschte CVEs können auch den Ruf schädigen. Eine Ankündigung zu einer Schwachstelle kann sich rasch über Scanner-Feeds, Sicherheitsdatenbanken und Suchergebnisse verbreiten. Eine darauffolgende Korrektur erreicht jedoch womöglich nicht dieselbe Reichweite. Selbst wenn eine Meldung angefochten oder zurückgewiesen wurde, müssen sich Anbieter gegenüber Kundinnen und Kunden rechtfertigen, die den ursprünglichen Bericht gesehen haben.

Zudem besteht das Risiko, dass echte Schwachstellen übersehen oder verspätet untersucht werden, weil Teams Zeit mit der Prüfung fehlerhafter Meldungen verbringen. Wenn den Verantwortlichen und Sicherheitsteams nur begrenzte Ressourcen zur Verfügung stehen, ist jede Stunde, die für die Widerlegung eines Fehlalarms aufgewendet wird, eine Stunde, die für die Untersuchung eines tatsächlichen Sicherheitsproblems hätte genutzt werden können.

Mit Automatisierung gegensteuern

Viele Ermittlerinnen und Ermittler prüfen die neue Flut an Meldungen weiterhin manuell, doch das ist auf Dauer nicht tragbar. Automatisierung erweist sich als große Hilfe, um eine Behauptung über eine Schwachstelle anhand der tatsächlich betroffenen Version und Konfiguration zu überprüfen. Dabei sollten fünf Fragen gestellt werden:

• Sind die Voraussetzungen für den Angriff glaubwürdig, einschließlich Konfiguration und Berechtigungen?
• Gibt es die angebliche Funktion in der betroffenen Version?
• Kann ein Angreifer den anfälligen Code erreichen? Stellen Sie fest, ob der betreffende Code unter den betroffenen Bedingungen ausgeführt werden kann und ob ein Angreifer Eingaben bereitstellen kann, die ihn erreichen.
• Können Tester das Verhalten in einer kontrollierten Testumgebung oder mit einem PoC reproduzieren?
• Hat das beobachtete Verhalten die im Sicherheitshinweis beschriebene Auswirkung auf die Sicherheit?

Agentenbasierte Tools können Testumgebungen einrichten, Codepfade analysieren, PoCs erstellen und Ausführungsnachweise zur Überprüfung aufzeichnen. Sie können jedoch nicht automatisch jede Behauptung klären. Selbst wenn eine Schwachstelle echt ist, kann ein PoC scheitern, wenn die Umgebung unvollständig oder der Auslöser falsch ist. Tester können einen Absturz reproduzieren, ohne die behauptete Ausnutzbarkeit nachzuweisen. Deshalb bleibt menschliches Urteilsvermögen unverzichtbar. Diese Tools können Teams jedoch einer reproduzierbaren Antwort näherbringen, bevor ein Bericht noch mehr Zeit in den Bereichen Entwicklung, Schwachstellenmanagement und Kundensupport beansprucht.

Die Überforderung im CVE-Ökosystem bewältigen

Keine noch so knappe Richtlinie wird das Problem gefälschter CVEs wie durch Zauberhand lösen. Hilfreich wären jedoch strengere Anforderungen an die Nachweise bei der Einreichung und ein klarerer Status zur Reproduzierbarkeit. Auch ein transparenterer Umgang mit strittigen Einträgen und eine schnellere Korrektur nachgelagerter Daten wären hilfreich. Forschende sollten dazu angehalten werden, ihre KI-gestützten Ergebnisse vor der Einreichung zu überprüfen.

Sicherheitsteams und Anbieter müssen sich auf die Prüfung der Nachweise konzentrieren. Ein kritischer CVE-Wert sagt nicht aus, ob ein anfälliger Codepfad in ihrer Umgebung erreichbar ist. Nur weil ein PoC fehlschlägt, bedeutet das nicht, dass alles in Ordnung ist. Und eine CVE-ID zu erhalten, entbindet Teams nicht von der nötigen technischen Arbeit, um ein Problem zu verstehen.

KI verbessert die Fähigkeit, Schwachstellen aufzuspüren, ermöglicht aber auch die Erstellung überzeugend wirkender, jedoch falscher Behauptungen. Angesichts der stetig wachsenden Zahl von Berichten müssen Organisationen in deren Überprüfung investieren. Dazu gehört, Tests zu entwickeln, Ergebnisse zu reproduzieren, Annahmen zu überprüfen und Nachweise leichter bewertbar zu machen. In diesem Bereich könnten agentenbasierte Sicherheitstests eine wichtige Rolle spielen.