Halluzinierte CVE-Einträge sind keine Theorie mehr: Sechs angebliche SQLite-Lücken standen mit dem Schweregrad 9,8 in der offiziellen Datenbank, obwohl der beschriebene Code nie existierte. Unternehmen mit vertraglicher Patch-Pflicht bezahlen diesen Fehlalarm mit echter Arbeitszeit.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Am 27. Juli 2026 erschienen sechs neue SQLite-Einträge in der CVE-Datenbank, der schwerste mit einem CVSS-Wert von 9,8. Vier Tage später trugen alle sechs den Vermerk „Rejected“. Dazwischen lag die Arbeit von Sicherheitsforschern, die belegen mussten, dass keine dieser Lücken je existierte.
Das Wichtigste in Kürze
- Sechs SQLite-Meldungen mit CVSS-Werten zwischen 7,5 und 9,8 wurden am 31. Juli 2026 zurückgezogen.
- JFrog kompilierte die angeblich verwundbaren Versionen und fand die beschriebenen Funktionen und Codezeilen dort nicht.
- Im selben GitHub-Konto lagen 55 Sicherheitshinweise, von denen 54 keinen belegbaren Fehler beschrieben.
- Ab dem 11. September 2026 verlangt der Cyber Resilience Act eine Erstmeldung binnen 24 Stunden.
Wie rutscht eine erfundene Lücke in die CVE-Datenbank?
Das öffentliche Meldeformular von MITRE kennt keine Identitätsprüfung, eine Schwachstellenbeschreibung darf jeder einreichen. Eine Vergabestelle setzt daraufhin die Nummer, und beim US-Institut NIST ruht seit Februar 2024 ein großer Teil der manuellen Nachbewertung wegen der schieren Menge. Eine plausibel klingende Erfindung passiert diese Kette ohne Widerstand.
JFrog kompilierte darum die genannten Versionen im Container und ließ die mitgelieferten Angriffsbeispiele laufen.[1] Die Funktion exprComputeOperands, angeblich verwundbar in Version 3.41.0, kam erst 2025 in den Code. Eine weitere Meldung verwies auf Zeile 3555 einer Datei mit 2706 Zeilen.
Wie viele Meldungen aus dem Konto waren erfunden?
Dasselbe Konto stellte insgesamt 55 Sicherheitshinweise online, und nur ein einziger beschrieb einen echten Bug, dessen Angaben allerdings niemand geprüft hatte. Red Hat stufte den schwersten Eintrag zunächst auf 10,0 ein und korrigierte später auf 7,6, bevor das amerikanische Schwachstellenregister alle sechs Nummern verwarf.[2]
Das SQLite-Projekt führt die sechs Nummern inzwischen mit dem Vermerk, dass niemand die Fehler reproduzieren konnte und alle nach KI-Halluzinationen aussehen.[3] Umgekehrt taugen Sprachmodelle durchaus zur Fehlersuche: Ein Forscher fand im Juli eine kritische WordPress-Lücke für 22 Euro Rechenkosten, und Microsofts Rückstau von 300 offenen Meldungen geht ebenfalls auf maschinelle Funde zurück.
Die Bilanz der sechs Meldungen
am 27. Juli 2026 vergeben, am 31. Juli 2026 auf „Rejected“ gesetzt
Red Hat vergab zunächst 10,0 und korrigierte später auf 7,6
ohne belegbaren Fehler im Quellcode
Behauptung und Befund
So klang die MeldungUse-after-free in der Funktion exprComputeOperands, angeblich in SQLite 3.41.0, mit Verweis auf Zeile 3555 einer Quelldatei.
So endete der TestDie Funktion kam erst 2025 in den Code, die Datei hat 2706 Zeilen, und die Angriffsbeispiele liefen ohne Absturz durch.
Ab 11. September 2026: Der Cyber Resilience Act verlangt von Herstellern eine Erstmeldung binnen 24 Stunden an eine zentrale ENISA-Plattform, sobald eine Schwachstelle aktiv ausgenutzt wird. Prüfen Sie Datenbankeinträge deshalb, bevor Sie eine Meldekette auslösen.
Was bedeutet der CVE-Müll für deutsche Unternehmen?
In vielen Häusern hängt der Patch-Zwang an ISO 27001, an Kundenverträgen oder an einer Cyberversicherung, deren Klauseln bei ungepatchten kritischen Lücken die Leistung kürzen. Ein erfundener Eintrag mit CVSS 9,8 löst deshalb denselben Ausnahmeantrag aus wie eine echte Lücke, und in den Sicherheitsteams läuft dieselbe Kette aus Prüfung und Freigabe.
Eine erfundene Lücke kostet ein Unternehmen dieselben Stunden wie eine echte, nur ohne den Sicherheitsgewinn am Ende. Solange eine CVE-Nummer ohne Prüfung vergeben wird, bleibt die Verifikation am Anwender hängen.
— Markus Seyfferth, Chefredakteur Dr. Web
Ab dem 11. September 2026 verlangt der Cyber Resilience Act von Herstellern eine Erstmeldung binnen 24 Stunden an eine zentrale ENISA-Plattform, sobald jemand eine Schwachstelle aktiv ausnutzt.[4] Meldeketten, die ungeprüfte Datenbankeinträge weiterreichen, produzieren unter dieser Frist Fehlalarme bei der Aufsicht.
Das curl-Projekt hat den eigenen Bug-Bounty zum 31. Januar 2026 eingestellt, nachdem die Quote bestätigter Meldungen von über 15 auf unter 5 Prozent gefallen war.[5] Große Projekte werden inzwischen lieber selbst zur Vergabestelle, und in der Praxis verlieren Schwachstellenmeldungen ihren Sonderstatus.
Für Ihre Praxis heißt das: Lesen Sie vor jedem Notfall-Patch die Advisory-Seite des Herstellers gegen und verlangen Sie einen Commit-Hash oder einen Pull-Request als Beleg. Ohne diesen Nachweis wandert ein Eintrag in die Warteschleife, nicht ins Wartungsfenster.
Quellen
[1] JFrog Security Research: „SQLite Critical CVEs or LLM Slop?“
[2] National Vulnerability Database: CVE-2026-51302, Status „Rejected“
[3] SQLite: Übersicht der CVEs zu SQLite
[4] BSI: Cyber Resilience Act, Meldepflichten ab 11. September 2026
[5] Daniel Stenberg: „The end of the curl bug-bounty“
Mehr Newshunger?
- GitLab-Exploit ohne CVE: Warum der entscheidende Patch als Routine-Update durchging
- MAI-Cyber-1-Flash: Microsofts KI-Modell findet Sicherheitslücken und schreibt den Patch
- Debian stimmt über KI-generierten Code ab: Verbot oder Auflagen?
- 570 Sicherheitslücken an einem Tag: KI treibt Microsofts Patchday auf Rekordniveau
- NIS2: Die Produktionshalle wird zur Haftungsfalle
- Technische Themen mit KI recherchieren, ohne auf erfundene Quellen hereinzufallen
