Die Prüfung selbst ist unspektakulär und genau deshalb überzeugend: JFrog hat nachgesehen, ob es die behaupteten Stellen gibt. Für den schwersten Fall, CVE-2026-51302, war eine Use-after-free in der Funktion `exprComputeOperands()` gemeldet – die in der angegebenen Fassung SQLite 3.41.0 nicht existiert, weil sie erst Mitte 2025 hinzukam. Dasselbe Muster bei `jsonBlobEdit()`: in 3.41.0 nicht vorhanden. Dazu Zeilennummern, die über das Dateiende hinausgehen, und Verweise auf Behebungen, die nie erfolgt sind. Der mitgelieferte Beweiscode tat laut The Register nichts von dem, was er sollte – er „executed a valid query with no memory leaks or errors“. Betroffen waren angeblich die Fassungen 3.41.0, 3.51.2 und 3.51.3; die sechs Nummern lauten CVE-2026-51296, -51297, -51300, -51302, -51303 und -51304.
Die Bewertungen kamen trotzdem zustande. Red Hat stufte CVE-2026-51302 zunächst mit 10.0 als kritisch ein und korrigierte später auf 7.6; das National Vulnerability Database vergab für den Schwung Werte zwischen 9,8 („Critical“) und 7,5 („High“). Über die sechs SQLite-Meldungen hinaus lagen im selben Repository 49 weitere Advisories zu libraw und ESP32-audioI2S. Von den 55 Einreichungen dieses einen Kontos waren nach JFrogs Audit 54 „completely fabricated, while one contained a real bug wrapped in unverified CVE metadata“. Ein Textprüfer schlug bei allen an: „All advisories in this repo seem AI generated when testing them with Gptzero.“ MITRE hat den gesamten Schwung nach einem Beitrag auf der oss-security-Liste zurückgewiesen, Red Hat und das NVD haben die Einträge markiert beziehungsweise entfernt – das GitHub-Repository stand zum Zeitpunkt der Register-Berichterstattung noch.
Die Schwachstelle ist die Kette, nicht das Konto. JFrog beschreibt, dass das NIST nach Februar 2024 „effectively hit pause on deep analysis“ und die Anreicherung an CISA und andere autorisierte Stellen überging – „but the global pipeline is now fragmented and drowning in a massive backlog“. Die Größenordnung dazu liefert The Register: über 27.000 unbearbeitete CVEs zum Ende des Jahres 2025, dazu ein Prüfbericht des Inspector General des US-Handelsministeriums, der dem NIST „lack of strategic planning and decisive action“ bescheinigt. Ohne diese Prüfstufe entscheidet praktisch niemand mehr, ob die behauptete Codestelle überhaupt existiert.
Für den Betrieb folgt daraus zweierlei. Erstens die Asymmetrie, die JFrog-Forscher Afek Berger benennt: „generative AI has lowered the effort required to produce a plausible-looking advisory to close to zero“ – die Gegenprüfung dagegen bleibt Handarbeit von Fachleuten. Zweitens die automatische Weiterverarbeitung, und hier trifft es genau die Werkzeuge, über die wir sonst schreiben: „An AI agent that encounters a fabricated CVE may attempt to locate the vulnerable function, generate a patch, or recommend changes based on code that does not even exist.“ Wo Kritisch-Meldungen automatisch Tickets erzeugen oder ein Agent Behebungen vorschlägt, wird aus einer erfundenen Zeile echte Arbeit – und im schlechtesten Fall eine Änderung an Code, der nie kaputt war. Der praktische Rat aus der Rezeption ist entsprechend nüchtern: Bei einer kritischen Meldung zuerst auf die Sicherheitsseite des Herstellers sehen, nicht auf den Scanner-Score.
Zur Beleglage: Die Untersuchung ist die Primärquelle und zugleich die eines Anbieters, der Software-Composition-Analysis verkauft – ein Befund, der die Grenzen automatischer Schwachstellen-Datenbanken zeigt, liegt in seinem Geschäftsinteresse. Wir führen ihn trotzdem als tragfähig, weil er aus nachprüfbaren Einzelaussagen besteht (existiert die Funktion in dieser Fassung? liegt die Zeilennummer in der Datei?) und weil die unabhängige Rezeption die Kernpunkte samt Rückweisung durch MITRE bestätigt. Aufgefallen ist uns die Geschichte über ein Tier-C-Video (Better Stack, 09.08.), dessen Referat bis auf einen Punkt deckungsgleich mit der Quelle ist: Die dort genannte 9,8 stammt vom NVD, nicht von Red Hat – Red Hat vergab 10.0.