JFrog Security Research untersuchte SQLite-Schwachstellenmeldungen eines neu erstellten GitHub-Kontos (programmervuln/cveadvisory-). NVD stufte sie als kritisch ein, CISAs ADP stimmte zu — doch bei der Verifikation zerfiel alles: Der zitierte Code existierte in den genannten Versionen nicht, die PoC-Payloads lösten keinen Absturz aus, keiner der CVEs steht auf SQLites offizieller Advisory-Seite, und GPTZero-Tests deuteten auf KI-generierte Texte hin.

Sechs CVEs wurden im Detail analysiert. CVE-2026-51302 (9,8 kritisch) behauptet einen Use-after-free über exprComputeOperands() — eine Funktion, die es in SQLite 3.41.0 nicht gab und erst Mitte 2025 hinzukam; sqlite3ReleaseTempReg() recycelt lediglich Registerindizes, ein UAF ist konstruktionsbedingt unmöglich. CVE-2026-51303 (9,8) verweist auf einen Fix in 3.51.3, doch der Diff zwischen 3.51.2 und 3.51.3 zeigt keinerlei Änderungen an src/expr.c; der PoC ist zudem ungültiges SQL. CVE-2026-51300 (9,1) zitiert Zeilen in expr.c, die einen Kommentar bzw. eine nicht zusammenhängende Allokation betreffen. CVE-2026-51297 (8,8) nennt jsonBlobEdit(), das in 3.41.0 nicht existierte. CVE-2026-51296 (7,5) zitiert die Zeilen 3555/3575 von json.c — in einer Datei mit nur 2706 Zeilen. CVE-2026-51304 (7,5) nutzt eine nicht existierende Funktionssignatur, während der echte Code den Zeiger sofort nach dem Löschen auf null setzt. Alle PoCs wurden in Docker-Containern unter AddressSanitizer gegen offizielle Builds der Versionen 3.41.0, 3.51.2 und 3.51.3 ausgeführt — ohne einen einzigen Speicherfehler. Red Hat bewertete CVE-2026-51302 zunächst mit 10,0 kritisch und stufte ihn später auf 7,6 hoch herab.

JFrog führt den Vorfall auf eine defekte Pipeline zurück: MITREs Einreichformular verlangt keine Identitätsprüfung, und seit NIST im Februar 2024 die Tiefenanalyse der NVD pausierte, können plausibel klingende Fake-Advisories ohne Bug-Reproduktion in GHSA, nachgelagerte Datenbanken und Enterprise-Scanner gelangen. Eine Prüfung von 55 Advisories desselben Kontos ergab: 54 komplett erfunden, nur eines enthielt einen echten Bug in unverifizierten CVE-Metadaten.

Als Warnsignale nennen die Forscher: keine Erwähnung auf offiziellen Security-Seiten der Maintainer, fehlende Commit- oder PR-Verweise, widersprüchliche CPE-Metadaten sowie Verweise auf nicht existierende Funktionen oder Zeilennummern. Gefälschte kritische CVEs verschwenden Triage- und Patch-Aufwand — und KI-Agenten in automatisierten Remediation-Workflows könnten versuchen, nicht existierenden Code zu patchen. Die Ergebnisse wurden an GHSA, Red Hat und NVD gemeldet.