An AI Hallucination Just Became a Critical SQLite CVE

On July 27, CVE-2026-51302 landed in the National Vulnerability Database: a use-after-free in SQLite's expression evaluation, exploitable by a remote attacker for denial of service, data leakage, or possibly code execution. GitHub's Advisory Database ingested it as Critical, CVSS 9.8. CISA's Authorized Data Publisher attached a severity vector. Four days later the record was withdrawn with a terse note: "Further investigation showed that it was not a security issue."

It wasn't merely overblown. It was fiction, generated by a language model, and it sailed through every checkpoint the CVE ecosystem has.

Fifty-four fakes and one real bug

JFrog's security research team dissected the batch — CVE-2026-51296 through -51304, all claiming use-after-free bugs across SQLite 3.41.0 to 3.51.3, scored between 7.5 and 9.8. The forensics didn't take long. CVE-2026-51302 names a function, exprComputeOperands(), that doesn't exist in SQLite 3.41. Another advisory cites lines 3555–3575 of src/json.c in a version where the file is 2,706 lines long. None of the proof-of-concept payloads crash anything. Run the advisory text through GPTZero and it flags as AI-generated.

The trail leads to a freshly created GitHub account whose repository held 55 advisories. By JFrog's count, 54 were fabricated. One described a real bug — which is almost worse, because it's exactly the ratio that makes blanket dismissal impossible.

SQLite's maintainers, who have spent years arguing that most CVEs filed against them are junk, added the batch to their official vulnerability page with a one-line verdict: unreproducible, "appear to be AI hallucinations."

The pipeline did what it was built to do

Here's the uncomfortable part: nothing malfunctioned. As JFrog notes, MITRE's public CVE request form has no real identity verification, and no stage of the process requires a working proof of concept. The system was designed in an era when writing a plausible vulnerability report cost a human hours of effort, and that cost was the spam filter. An LLM produces a convincing advisory — correct terminology, plausible function names, a CVSS vector, a PoC that looks runnable — for fractions of a cent. Refuting one took JFrog's researchers actual source-tree archaeology: checking out old versions, grepping for functions, counting lines, executing payloads. That asymmetry is the whole story. The cost of fabrication collapsed; the cost of verification didn't move.

Worse, corrections propagate slower than claims. Days after the CNA rejection, the GitHub advisory for CVE-2026-51302 was still live, still Critical 9.8, marked "unreviewed" and not withdrawn. Publication is push; retraction is pull. Every scanner that mirrored the advisory during its four-day lifetime got the poison, and there's no invalidation protocol forcing it back out.

The canary was chirping for two years

None of this should surprise anyone who's followed curl. Daniel Stenberg has been publicly fighting AI-generated slop in curl's bug bounty inbox since early 2024, and by 2025 was reporting that a meaningful share of incoming security reports were LLM-invented. And the CVE quality problem predates the AI angle entirely: CVE-2020-19909, the bogus 9.8 filed against a curl non-bug in 2023, is why curl became its own CVE Numbering Authority. The Linux kernel did the same in 2024, for the same reason — if you don't control CVE assignment for your project, strangers do.

What's changed is the blast radius. Slop in a HackerOne inbox wastes one maintainer's evening. Slop in the CVE database flows into Dependabot, Trivy, Grype, Snyk, and every compliance regime that keys remediation SLAs off CVSS scores. And the target here was maximally chosen: SQLite is plausibly the most widely deployed piece of software on earth — it's in every phone, browser, and language runtime. A critical SQLite CVE lights up dashboards at basically every company with a dependency scanner, which is to say every company.

What this means for your Tuesday

If your vulnerability management process auto-generates tickets or triggers patch SLAs from CVSS severity alone, you just learned that any stranger with an LLM can schedule work for your security team. That's not a hypothetical anymore; treat it as a design flaw. Concretely:

• Close the tickets. If scanners flagged SQLite against CVE-2026-51296 through -51304 last week, cite the NVD rejection and SQLite's advisory page and move on.
• Treat upstream as ground truth for foundational dependencies. For SQLite, the project's own cves.html is the record of what's real. Aggregators are convenience layers, not authorities.
• Weight "unreviewed" accordingly. A GHSA entry with no package mapping, no patched-version data, and no GitHub review is an unverified claim wearing a severity badge. Gate paging and SLAs on reviewed advisories plus reachability analysis, not raw feed matches.
• If you maintain anything significant, become a CNA. It's the one structural defense in the current system: CVE assignment for your scope routes through you instead of MITRE's open form. curl and the kernel already proved the model.

Self-correcting, but not self-scaling

The honest verdict cuts both ways. The system caught this in four days, which is genuinely fast — but only because a commercial research team donated skilled hours to disprove free-to-generate claims, and the retraction still hasn't fully propagated. That model doesn't survive a hundred accounts doing what one did. Expect MITRE to bolt on friction — identity checks, PoC attestation — and expect more projects to grab CNA status in self-defense. Until then, the CVE feed is an unauthenticated write path into your security tooling, and it deserves the same treatment as any other untrusted input.