How a Batch of Fake SQLite CVEs Scored 9.8 Critical Before Anyone Checked the Code

A batch of six SQLite advisories citing functions that do not exist in the pinned source code was filed as new CVE numbers, auto-accepted into the National Vulnerability Database, and scored critical (CVSS 9.8 and 10.0) by NVD, CISA's ADP catalog, and Red Hat within hours of submission. The SQLite project's own advisory page, which only lists flaws the maintainers have verified, was never consulted. By the time independent researchers cloned the code at the cited tags, ran the proof-of-concept payloads in isolated builds, and confirmed the cited functions were never there, federal catalogs and at least one major Linux vendor had already propagated the false-critical scores to defenders.

This is what failure inside the public vulnerability-disclosure system looks like. The CVE system, the Common Vulnerabilities and Exposures database, is the public registry that security teams, software vendors, and federal agencies use to decide which software flaws to patch and how urgently. Each entry gets a unique identifier and a CVSS severity score from 0 to 10. Higher scores mean faster patch cycles, more alert volume, and more attention from incident-response teams. A 9.8 or 10.0 pushes a flaw to the top of every queue.

The batch came from a freshly created GitHub account publishing under a repo named cveadvisory-. The six entries, CVE-2026-51296, -51297, -51300, -51302, -51303, and -51304, all targeted SQLite, the widely embedded open-source database engine. JFrog's security research team investigated and concluded the advisories were LLM-generated slop. The audit was specific: the cited functions did not exist in the target SQLite versions (3.41.0, 3.51.2, and 3.51.3); the proof-of-concept payloads failed to crash; none of the CVEs appeared on SQLite's official advisory page; and the metadata carried placeholder contradictions typical of automated generation. A GPTZero classifier flagged the advisory bundle as AI-generated, a supporting signal, not a verdict.

The same repo held roughly fifty additional advisories that JFrog believes are also LLM slop, with one possible exception. The audit table is granular: non-existing functions, contradictory NVD metadata, advisories referencing code unrelated to the claimed flaw, and one advisory pointing at a real function with the wrong argument count. None survived a source-code diff at the pinned tag.

CVE-2026-51302 is the clearest case in the batch. NVD's entry originally carried a 9.8 critical, and Red Hat's advisory initially assigned it a 10.0. CISA's ADP enrichment initially concurred. After the audit, Red Hat downgraded the entry to 7.6 High. The CISA record still carries the contested critical score as of writing.

The auto-ingest path that pulled these advisories into the National Vulnerability Database accepted them on submission. Severity assignment propagated downstream to CISA's catalog and to Red Hat within hours. None of those steps required a maintainer check against the project's own advisory page, the gold standard that lists only flaws the SQLite team has verified. That page would have shown the entries were not real.

The Hacker News thread on the audit (item 49154332) captures the live community debate: whether LLM-generated CVEs are degrading the signal-to-noise ratio of the disclosure system, and whether the system already had a noise problem independent of LLMs. The strongest counterargument is that the system self-corrected once researchers published their findings. The falsifier is that a vendor-maintained advisory page was available at the moment of auto-acceptance, and the auto-ingest path did not consult it.

The structural fix on the table is a verification gate between acceptance and severity assignment: a step that checks a new advisory against the affected project's own published list of known flaws, or against a build of the cited source code at the pinned version, before a CVSS score propagates downstream. JFrog's audit already shows what that gate would look like in practice: clone the official repository at the cited tag, run the payload in an isolated container, and confirm the cited function exists at the call site. The same procedure would have caught all six entries in this batch.

Defenders can spend hours patching ghosts while real vulnerabilities get less attention than they should. A two-step gate at the ingest point would have kept the false-critical scores from ever leaving the building, and it is the same fix that would have caught the next batch regardless of who, or what, filed it.