A Vulnerability That Doesn't Exist Just Got a Critical CVE

Every security team starts the morning the same way: scan the new CVE feed, look for anything you actually ship. See a familiar library name and the whole day gets rewritten. That workflow assumes one thing — that a CVE number means someone checked. A SQLite vulnerability that does not exist just picked up an official number and a Critical rating, and that assumption is now a liability.

How a Hallucination Gets an Official Number

The mechanics are depressingly simple. Someone dumps an open-source project’s source into an LLM and asks it to find vulnerabilities. The model produces a report. Function names check out. File paths check out. The prose is cleaner than most real advisories — no broken English, no rambling repro steps, proper CWE classification. The only thing missing is the bug.

That report gets submitted to a CVE Numbering Authority. It clears. A number is issued, a severity score is attached, and within hours every vulnerability scanner on the planet has ingested it as fact.

SQLite makes it sting more. It is the most widely deployed database in existence — in every smartphone, every browser, in avionics software. It is also famously paranoid about verification, with a test suite running hundreds of times larger than the codebase itself. If a fabricated bug can get permanently recorded against SQLite, it can get recorded against anything.

The Asymmetry That Breaks Everything

Vendors including JFrog have started calling this AI slop — machine-generated content produced fast, in volume, with no one checking.

In vulnerability reporting it is especially corrosive, and the reason is verification asymmetry. Generating a plausible vulnerability report takes minutes and costs pennies. Disproving one requires a human engineer to read the code, attempt reproduction, and then construct an argument for why the described path can never trigger. That is hours. Sometimes days.

Daniel Stenberg of curl has been shouting about this for a while now — AI-generated bug bounty submissions eating the time he needs for real vulnerabilities. He eventually started publicly posting the worst offenders. The structural problem underneath is that most open-source maintainers are unpaid volunteers, and this dynamic hands them an unbounded obligation to refute things a machine invented for free.

The System Was Designed for a World Where Reports Were Expensive

MITRE coordinates the CVE program from the US, delegating number assignment to hundreds of CNAs. NVD layers on severity scores and metadata.

That architecture was built in the late 1990s on an assumption that held for 25 years: submitting a vulnerability report costs something. It required skill and hours of work. So treating incoming reports as good-faith by default was not naivety — it was a reasonable read of the economics.

LLMs deleted that assumption. The marginal cost of a convincing vulnerability report is now approximately zero. And NVD was already drowning before this started — the backlog crisis that began in early 2024 left thousands of CVEs unanalyzed, with headcount and budget flat against exploding submission volume. A system that cannot keep up with legitimate reports has no capacity to catch sophisticated fakes.

What One Fake CVE Actually Costs

The blast radius is wider than it looks.

Scanners fire false positives. An internal tool alerts on a Critical finding, a team drops everything, and days burn before anyone establishes the bug was never there.

Compliance tangles up next. SBOM submission is now a contract requirement in a growing number of procurement processes, and US federal software attestation rules have pushed this well beyond voluntary. One unresolved Critical CVE on the manifest can stall a delivery. Contracts get delayed over vulnerabilities that do not exist.

Then alert fatigue, which is the genuinely dangerous one. Repeated false alarms train humans to discount the channel. The failure mode is not the fake alert. It is the real one that arrives after everyone stopped reading them.

And finally: this data becomes training material. Models trained on a polluted record generate more polluted reports. The loop closes.

What Actually Changes for You

The individual lever here is small, but one assumption is worth retiring outright. A CVE number is an identifier, not a verification. It always was. The distinction just never mattered before.

More teams are now adding a step before triage: check what upstream actually says. Well-run projects leave a trail — mailing list threads, commit messages, an advisory page. SQLite in particular does not go quiet about real bugs. If a Critical CVE has no corresponding upstream acknowledgment anywhere, treat that silence as information.

The structural fixes under discussion are the obvious ones: stronger reporter identity requirements, mandatory reproducible proof-of-concept code, audits of the CNAs themselves. None are free. Every barrier that stops a bot also stops an independent researcher who does not want to attach their legal name to a finding — the exact people the program was built to serve.

The Part That Lingers

This was never about whether SQLite has a bug. A system built to record facts has started absorbing things that are not facts. The CVE database has been the security industry’s shared reference point for nearly 30 years, and an enormous amount of automation is stacked on top of it — scanners, compliance pipelines, procurement gates, insurance underwriting. Shake the reference point and everything above it moves.

AI has made production nearly free. Verification has not gotten any cheaper. So far the difference has been absorbed almost entirely by unpaid maintainers, and there is no reason to assume that holds. Under the current arrangement, the side doing the checking runs out of patience first.