AI Hallucinated Dozens of SQLite Vulnerabilities — and They Reached the CVE Database Anyway

Over several days in late July, a single GitHub account published 55 security advisories against SQLite, one of the most widely deployed pieces of software on Earth. Fifty-four of them were fabricated. They described bugs in code that does not exist, carried official-looking CVE numbers and "critical" severity scores, and propagated into the databases that the security world treats as authoritative — before anyone caught them.

SQLite was never vulnerable to any of this. There was no attack, no exploit, no compromise. What the episode exposed was a gap in the vulnerability-reporting system itself — and for a few days, the fakes slipped through it. That is the actual story, and it is a more interesting one than "AI found bugs."

What JFrog found

The security firm JFrog, in a post by researcher Afek Berger published on 30 July, worked through the batch and found it did not survive contact with the source code. The clearest example is a filing numbered CVE-2026-51304. It described a use-after-free in a function call written as sqlite3ExprListDelete(pOrderBy) — a single argument. That function signature does not exist in SQLite. The real function takes two arguments, including a pointer to the database context. The advisory was describing code that was never written.

That pattern repeated. Cited functions didn't exist in the versions named; supplied proof-of-concept payloads reproduced no crash; the technical details pointed at nothing. JFrog also ran the advisories through an AI-text detector, which flagged them as machine-generated — but that is the weaker evidence, and worth being careful about, because AI-text detectors carry real false-positive rates. The dispositive part isn't a detector's verdict. It's that the reports describe a program that doesn't exist. Whatever produced them, they were not the work of someone who had read the code.

Of the 55, JFrog's audit found 54 completely fabricated and one that contained a real bug — wrapped in inflated, unverified metadata. So not quite 100% noise, but close, and even the real one was mis-dressed.

The part that should worry you: how far they got

A fabricated advisory should be harmless. This one wasn't, because of how the modern vulnerability pipeline works: you can publish a CVE without ever supplying a working proof that the bug is real. So these entries propagated. They reached the US government's National Vulnerability Database, complete with enrichment from CISA. They reached GitHub's own Advisory Database. They picked up CVSS severity scores ranging up to 9.8, and one was briefly scored a maximum 10.0 by Red Hat before being walked back.

To the credit of the humans in the loop, the correction machinery did eventually turn over. JFrog reported its findings; MITRE rejected the account's CVEs, their entries in the National Vulnerability Database were marked rejected, and Red Hat lowered its scores. But the cleanup is slower than the pollution: at the time of writing, at least one of the fabricated advisories still sits in GitHub's database with no withdrawal notice on it. The fake outlived the debunk.

The authoritative source saw through it — and had already warned you

There is one reference that never fell for it: SQLite's own maintainers. Their official vulnerability page is unusually blunt for a security document. It tells you plainly not to trust CVEs about SQLite at face value, warning that very few of them describe real, exploitable vulnerabilities — bugs that actually hand an attacker new capabilities. And it now lists the specific fabricated entries explicitly, labelled as unreproducible and, in the maintainers' assessment, AI hallucinations, with a pointer to JFrog's analysis.

That's the honest version of the "check the source" lesson. It isn't that SQLite's list failed to mention these bugs — it's that the people who actually know the code never treated them as real, and had told the world in advance that the CVE system around their project was noisy. The authoritative source was right. The automated databases downstream of it were the ones that got polluted.

This is a pattern, and the economics are the problem

SQLite is not being singled out; it's just a high-value, well-documented target where the fabrications are easy to disprove. The wider trend is already forcing changes on maintainers. In January, the curl project — run by Daniel Stenberg — shut down its bug-bounty program after a flood of AI-generated slop reports. Stenberg was blunt about why: the goal, he wrote, was "to remove the incentive for people to submit crap and non-well researched reports to us." His team was fielding waves of plausible-looking submissions that dissolved on inspection, each one costing hours to disprove.

That is the mechanism underneath all of it: generative AI has lowered the effort to produce a plausible-looking advisory to nearly zero, while the effort to verify one is unchanged. It's an asymmetry, and asymmetries are what break systems that assumed good faith. When manufacturing a convincing fake is free and refuting it is expensive, volume wins.

Why it matters beyond the noise

The immediate cost is wasted human time. The larger one is what happens as fewer humans are in the loop. Vulnerability feeds are increasingly consumed not by people but by automated triage systems and AI coding agents — the kind now trusted to read an advisory, find the flawed function, and propose a patch. Point one of those at a fabricated CVE and the failure mode isn't a false alarm a human shrugs off; it's an agent confidently hunting for a bug in code that doesn't exist, or "fixing" something that was never broken. JFrog frames that as a risk rather than a documented incident, and that's the right level to pitch it — but the pathway is no longer hypothetical, because the fakes demonstrably reached the feeds those systems read.

It rhymes with a theme we keep coming back to: AI systems that hallucinate confidently, and the way those hallucinations launder into something that looks like fact once they've passed through an official-looking format. We wrote earlier this week about a prompt injection that can copy itself between documents; this is the same story from the other side — not AI as the attacker, but AI as a firehose of plausible garbage that our verification systems weren't built to filter. The bugs were fake. The strain on the system that had to prove it was entirely real.