LLM-fabricated CVE advisory wave (programmervuln/cveadvisory-)

BSI and NCSC-NL withdraw SQLite advisories built on LLM-fabricated CVEs — and GitHub's advisory database was still serving one of them

Two European national CERTs pulled published SQLite advisories on 2026-08-03 for the same reason: the vulnerabilities are not real. NCSC-NL revised NCSC-2026-0268 to version 1.01, struck through its own description, and gave the reason in one line — "CVE is door een LLM gehallucineerd" ("the CVE was hallucinated by an LLM") — noting the retracted advisory had covered CVE-2026-51302 as affecting Red Hat's SQLite (NCSC-NL, 2026-08-03). BSI CERT-Bund retitled WID-SEC-2026-2604 and WID-SEC-2026-2581 to "MELDUNG ZURÜCKGEZOGEN" ("advisory withdrawn") and removed their CVE references (BSI CERT-Bund, 2026-08-03; BSI CERT-Bund, 2026-08-03).

The underlying work is a reproduction audit rather than an opinion. JFrog cloned sqlite/sqlite at the claimed tags, compiled the official releases in isolated containers, and fed each advisory's proof-of-concept SQL verbatim into the binaries under AddressSanitizer. Nothing reproduced, and the code references dissolve on inspection: CVE-2026-51302's claimed use-after-free runs through exprComputeOperands(), a function that did not exist in SQLite 3.41 and was added mid-2025, while the function it says does the freeing, sqlite3ReleaseTempReg(), only recycles register indices into an array and performs no heap deallocation at all. CVE-2026-51303 claims a fix in 3.51.3, but "a diff between 3.51.2 and 3.51.3 shows absolutely no changes to src/expr.c". CVE-2026-51296 cites lines 3555 and 3575 of src/json.c when, JFrog notes, "In version 3.41.0, src/json.c is only 2706 lines long". CVE-2026-51297 references jsonBlobEdit(), absent from the claimed release; CVE-2026-51304 gives a single-argument signature for a function that requires a database handle; CVE-2026-51300 cites a comment and a memory allocation as the vulnerable lines (JFrog Security Research, 2026-07-30). SQLite's maintainer reported the same wave independently on 2026-07-29 (SQLite User Forum, 2026-07-29).

The propagation path is the part that matters operationally, because every hop in it is one a defender's own tooling trusts. A newly created GitHub repository published the advisories; MITRE's public submission form performs no identity verification; NVD flagged them critical and CISA's Authorized Data Publisher enrichment agreed; Red Hat initially scored CVE-2026-51302 at 10.0 before downgrading it to 7.6; from there the records reached GHSA and the two national-CERT advisory streams that European public-sector vulnerability management actually reads. JFrog's diagnosis is structural: "Because no step in today's system actually requires a proof-of-concept or bug reproduction, a plausible-sounding fake advisory can slide right through the pipeline and end up in GHSA, downstream databases, and enterprise scanners." Retraction does not travel the same path in reverse — this run fetched GHSA-4r76-5xh9-qj36 — a use-after-free claim against SQLite 3.41 carrying CVE-2026-51294, from the same batch but not among the six JFrog reproduction-tested — and found it still live and marked "Unreviewed" on 2026-08-04, after both CERTs had withdrawn (GitHub Advisory Database, 2026-07-30).