Hallucinated SQLite CVEs: The Rise of LLM Slop in Vulnerability Reporting

LLM-Generated Fake CVEs Target SQLite

Recent security advisories for SQLite have been identified as "LLM slop"—fabricated vulnerabilities generated by artificial intelligence that were nonetheless flagged as critical by the National Vulnerability Database (NVD) and CISA's Authorized Data Publishers (ADP). JFrog security researchers discovered that a GitHub repository (programmervuln/cveadvisory-) published a batch of over 50 CVEs, the vast majority of which were entirely fake, including several high-severity reports targeting SQLite.

Evidence of Fabrication

JFrog verified the falsity of these CVEs through a rigorous testing workflow involving source inspection of official SQLite tags, clean environment builds in Docker, and PoC execution under AddressSanitizer (ASan). The investigation revealed four primary patterns of hallucination:

1. Non-existent Code References

Several advisories cited functions or line numbers that did not exist in the targeted versions of SQLite. For example, CVE-2026-51302 claimed a vulnerability in exprComputeOperands(), a function that was not added to SQLite until mid-2025, long after the reported version 3.41.0. Similarly, CVE-2026-51296 cited line numbers in src/json.c that exceeded the actual length of the file.

2. Fabricated Patches

CVE-2026-51303 claimed a fix was implemented in version 3.51.3. However, a diff between versions 3.51.2 and 3.51.3 showed zero changes to the relevant file (src/expr.c), proving the "patch" was entirely invented.

3. Invalid PoC Payloads

Proof-of-Concept (PoC) SQL statements provided in the advisories failed to trigger crashes or memory errors. In some cases, the PoCs were invalid SQL that failed at the parser stage, never reaching the execution logic they claimed to target.

4. Logical Impossibilities

In CVE-2026-51304, the advisory claimed a use-after-free (UAF) occurred after a list was freed. Source code analysis showed that SQLite explicitly nulls the pointer immediately after deletion (pPrior->pOrderBy = 0), making a subsequent dereference impossible by design.

Systemic Failure of the CVE Pipeline

This incident highlights a critical vulnerability in the global vulnerability reporting infrastructure. The current system allows plausible-sounding fake advisories to reach enterprise scanners due to two main factors:

  • Lack of Identity Verification: The MITRE public submission form does not require identity verification, allowing anyone to propose a CVE and a CVSS score.
  • The "NVD Safety Net" Collapse: Historically, NIST experts manually validated and enriched CVEs. However, since February 2024, a massive surge in reports led NIST to pause deep analysis, leaving the pipeline fragmented and lacking a mandatory proof-of-concept or reproduction step.

Impact on Security Operations

Fabricated CVEs create significant operational burdens for security teams and maintainers:

  • Wasted Resources: Organizations waste time investigating and patching non-existent bugs, especially when automated systems trigger high-priority tickets based on CVSS scores.
  • Maintainer Burnout: Project maintainers must spend time debunking hallucinations rather than fixing real bugs.
  • AI Triage Risks: AI agents used for automated remediation may attempt to "patch" non-existent functions, potentially introducing real bugs into a codebase.

Community Insights and Counterpoints

Industry observers on Hacker News noted that this trend reduces the signal-to-noise ratio, making it harder to identify legitimate threats. Some contributors expressed concern that this could be a precursor to more malicious attacks:

"Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable."

Others pointed out the irony of using AI-generated content to report on AI-generated slop, noting that the proliferation of these tools has created a "stochasticity" where human expertise is being replaced by homogenized, probabilistic flaws.

How to Identify "Slop" CVEs

To avoid wasting resources on fabricated vulnerabilities, security teams should look for these red flags:

  • No Vendor Corroboration: The issue is absent from official maintainer security pages (e.g., sqlite.org/cves.html).
  • Missing 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.
  • Impossible References: The advisory cites functions or line numbers that do not exist in the specified version.

Sources