Fabricated SQLite CVEs: The Rise of LLM-Generated Vulnerability Slop

A series of critical vulnerability advisories for SQLite were recently discovered to be "LLM slop"—fabricated reports generated by AI that cited non-existent code and provided non-functional Proof-of-Concept (PoC) payloads. Despite being fake, these CVEs were initially flagged as critical by the National Vulnerability Database (NVD) and CISA's Authorized Data Publishers (ADPs), highlighting a dangerous gap in the current vulnerability validation pipeline.

The Fabricated SQLite Vulnerabilities

JFrog security researchers investigated a batch of SQLite advisories published by a GitHub repository (programmervuln/cveadvisory-). Their audit revealed that 54 out of 55 advisories from this account were completely fabricated.

Analysis of Hallucinated CVEs

Researchers used an isolated testing workflow involving official SQLite source inspection, clean Docker builds, and AddressSanitizer (ASan) instrumentation to verify the claims. The results showed a consistent pattern of AI hallucinations:

CVE Reported Flaw Finding
CVE-2026-51302 UAF in exprComputeOperands() The function exprComputeOperands() did not exist in the target version (3.41.0).
CVE-2026-51303 UAF in ExprListDelete() The reported "patch" in version 3.51.3 was fabricated; no changes existed in src/expr.c between 3.51.2 and 3.51.3.
CVE-2026-51300 UAF in sqlite3ExprDelete() Cited line numbers referenced a comment and a memory allocation call, unrelated to the reported flaw.
CVE-2026-51297 UAF via jsonBlobEdit() The function jsonBlobEdit() was not present in the target version (3.41.0).
CVE-2026-51296 UAF in jsonRemoveFunc Cited line numbers exceeded the total length of the source file (src/json.c).
CVE-2026-51304 UAF via pOrderBy->nExpr The reported function signature was incorrect, and the code explicitly nulls pointers after deletion.

In every case, the provided PoC SQL statements either failed at the parser stage or executed successfully without triggering any memory errors.

Systemic Failures in CVE Validation

The ability of fabricated reports to receive critical severity scores (such as the 10.0 score initially assigned to CVE-2026-51302 by Red Hat) points to a breakdown in the vulnerability ingestion pipeline.

The Breakdown of the NVD Safety Net

Historically, the National Vulnerability Database (NVD) manually analyzed and validated incoming CVEs. However, in February 2024, NIST paused deep analysis due to a massive surge in reports. This has resulted in a fragmented pipeline where:

  • Lack of Verification: No step in the current submission process requires a functional proof-of-concept or bug reproduction.
  • Automated Ingestion: Plausible-sounding fake advisories can slide through to GHSA and enterprise scanners without human verification.
  • Identity Anonymity: The MITRE public submission form lacks rigorous identity verification, allowing anyone to propose a CVE and a CVSS score.

Impact on Security Operations

Fabricated CVEs create significant operational overhead and security risks for organizations and maintainers:

  • Resource Wastage: Security teams waste time investigating and patching non-existent vulnerabilities.
  • Polluted Databases: Vulnerability databases become saturated with "noise," making it harder to identify legitimate critical threats.
  • AI-Driven Misremediation: AI agents used for automated triage may attempt to patch non-existent functions, potentially introducing real bugs into production code.
  • Maintainer Burden: Open-source maintainers are forced to spend time debunking hallucinations rather than fixing real security flaws.

How to Identify "Slop" CVEs

To avoid being misled by fabricated advisories, security professionals should look for the following red flags:

  • Missing Vendor Corroboration: The issue is not mentioned on official maintainer security pages (e.g., sqlite.org/cves.html).
  • Absent Commit History: There are no linked commit hashes or pull requests in the reference fields.
  • Metadata Contradictions: CPE product definitions are empty or version ranges conflict with the advisory narrative.
  • Non-existent Code References: The advisory cites functions or line numbers that do not exist in the specified software version.

Community Perspectives

Industry observers have expressed concern over the decreasing signal-to-noise ratio in security reporting. Some contributors noted that while LLMs can find real bugs, the lack of validation creates an avenue for "massive attack" via false reports.

"LLMs are text-prediction engines. They are not Artificial Intelligence, and shouldn’t not be treated in any form or fashion as if they possess intelligence... Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity."

Others warned that the current trend of "output machines" being built before "verification machines" is unsustainable for software development.

Sources

Related