A CVE Was Issued for a SQLite Vulnerability That Doesn't Exist

A CVE was assigned, published to the National Vulnerability Database, and circulated in security feeds for a vulnerability in SQLite that does not exist. The flaw was fabricated by an AI model, passed through the CVE submission process without being caught, and became part of the official record of known vulnerabilities. Security teams spent time triaging it. Downstream tools ingested it. Some vendor advisories referenced it.

The vulnerability was never real. The database it described as affected never contained the code path cited. SQLite's maintainers confirmed it. None of that happened before the CVE went public.

The immediate reaction is to file this under 'AI hallucination causes embarrassing incident.' That framing misses what's actually broken here.

What actually happened

From what's been reconstructed via public reporting: a researcher used an AI model to assist with vulnerability analysis, the model produced a plausible-sounding description of a vulnerability in SQLite's expression handling, the researcher submitted that description as a CVE without independently verifying the referenced code path, and a CVE Numbering Authority assigned it an identifier. The entry included specific version numbers, a CVSS score, and references to code that doesn't exist in SQLite's source tree, including functions cited at line numbers past the end of the relevant files.

SQLite is one of the most-deployed codebases in existence. It's in every Android device, every iOS device, every macOS installation, most browsers, and a substantial fraction of production server software. A high-severity CVE against SQLite generates immediate triage activity across a lot of organizations. Security teams pulled the CVE, checked their SQLite versions, started planning patch timelines, and in some cases opened tickets. All of that work was for a vulnerability that couldn't be patched because it wasn't there.

Why AI models hallucinate vulnerabilities specifically

Language models are good at producing text that looks like security research. CVE descriptions have a consistent structure: affected component, vulnerable version range, attack vector, impact description, sometimes a code reference. That structure is well-represented in training data. A model asked to analyze a codebase and identify vulnerabilities will produce outputs that follow the structure of real CVEs even when the underlying technical claim is fabricated.

The problem is worse for well-known codebases. SQLite has decades of public vulnerability history. Its architecture is extensively documented. Security researchers have published analyses of its memory handling, its expression parsing, its virtual machine. A model trained on that corpus has enough material to construct plausible-sounding vulnerability descriptions that reference real subsystems, real version numbers, and realistic-sounding code paths. The hallucination looks authoritative precisely because the surrounding context is accurate.

This is categorically different from a model hallucinating an obscure API method or getting a factual date wrong. A model that invents a SQLite vulnerability produces a technically coherent, structurally convincing artifact that will pass a surface-level plausibility check by anyone who isn't willing to pull the source tree and verify the specific claim. That's a forgery that looks like due diligence.

The CVE process wasn't built for this

CVE operates through a network of CVE Numbering Authorities: organizations authorized to assign CVE identifiers within their domain. Researchers submit vulnerability information, CNAs assign identifiers, and entries flow into the NVD where NIST enriches them with CVSS scores and additional metadata. The underlying assumption is that submissions describe real vulnerabilities someone has verified.

The process has always relied on submitter integrity. A researcher who fabricates a vulnerability to inflate their disclosure count, or submits a disputed finding without confirming it with the vendor, gets CVEs assigned anyway because the system isn't designed to independently verify technical claims before publication. This has created problems before the current AI context: disputed CVEs, duplicate assignments for the same issue, incomplete descriptions that vendors can't act on.

What AI-assisted research does is industrialize the failure mode. A determined bad actor could generate dozens of plausible-sounding but fabricated CVEs in an afternoon. A careless researcher using AI assistance as a primary source rather than a secondary tool will produce the same result accidentally. The submission volume that CNAs can process without deeper technical verification creates an opening that scales in proportion to how good AI models get at generating convincing security research prose.

The downstream damage is real even after retraction

CVEs don't disappear cleanly. The NVD entry can be disputed and eventually marked as rejected, but the identifier persists. Third-party vulnerability databases that ingest NVD data will have cached the entry. Vendor advisory systems that automatically trigger on new CVEs will have logged it. Security tools that ingested it will have records. Developers who saw the advisory and started triaging will remember the CVE number and may encounter it again in future searches, without remembering it was retracted.

There's also the organizational cost. Security teams at companies running SQLite, which is most companies running software, triaged something that required no action. Depending on how mature their vulnerability management process is, that triage cycle could involve multiple people, an internal ticket, a check of their SQLite deployment inventory, and a communication to whoever manages third-party dependencies.

That cost is invisible in any post-incident accounting. Nobody tallies the hours spent on a hallucinated CVE. It shows up as noise in the vulnerability management process and degrades trust in CVE feeds incrementally, which is exactly the wrong habit to build into a security team. Each spurious entry that gets through raises the prior that any given CVE might not be worth acting on immediately.

The same pattern that broke package management is now breaking vulnerability disclosure

This incident is structurally identical to the package hallucination problem that's been documented over the past few years. AI models recommend dependencies that don't exist. Developers install them from package registries, potentially getting malicious packages that bad actors registered against the hallucinated names. The model invented a plausible artifact name; the ecosystem provided a place for the artifact to exist.

The CVE case is the same pattern applied to the vulnerability disclosure ecosystem. The model invented a plausible vulnerability description. The CVE process provided a mechanism to make it official. The NVD provided distribution. The hallucination gained institutional legitimacy and caused real downstream work before anyone caught it.

Both failure modes share a root cause: AI-generated artifacts being treated as primary sources rather than as outputs requiring independent verification. In the dependency case, the verification step is checking whether the package exists and was authored by the expected maintainer. In the CVE case, the verification step is reading the referenced source code and confirming the vulnerable code path exists. Both steps got skipped, and the consequences were proportional to what the ecosystem did with the fabricated output.

What good practice looks like now

Any vulnerability claim that references specific code needs independent verification against the actual source before submission. That means pulling the version, finding the specific file and function, and confirming the behavior described. A model output that says 'the vulnerability occurs in a specific function at a specific line' needs to be checked against that line in that version range. If that check takes ten minutes and the model output is wrong, the ten minutes was worth it. Submitting without checking is what created this incident.

This applies regardless of how confident the model sounds. Confident hallucinations in well-documented codebases are harder to catch on instinct than vague uncertain output. The model's confidence level is not a reliable signal for correctness, and nowhere is that more consequential than in vulnerability research where false positives carry real institutional costs.

For CNA programs and MITRE, the CVE process needs explicit guidance on AI-assisted submissions and what verification evidence is expected. Requiring a proof-of-concept demonstrating the vulnerability is exploitable, or requiring confirmation from the software vendor before assignment, would both raise the bar against hallucinated submissions. Neither is a new idea; both exist as best practices that CNAs can already choose to enforce. Making them requirements for commonly deployed open-source software like SQLite is a reasonable policy response to a predictable problem. There's also a case for a faster rejection and retraction workflow: the current process for disputing a CVE entry is slow enough that a fabricated CVE can circulate for weeks before the NVD record is updated. A parallel fast-track for vendor rejections, specifically where the named vendor explicitly states the described vulnerability does not exist, would reduce the window for downstream damage.

For security teams consuming CVE feeds: checking vendor status before triaging high-severity CVEs against widely deployed components is worth building into the process explicitly. For SQLite specifically, D. Richard Hipp and the SQLite team are responsive and maintain a clear history of security advisories at sqlite.org/cves.html. A CVE describing a high-severity SQLite vulnerability that the SQLite project hasn't acknowledged on their own vulnerabilities page is a reason to pause before routing work to your engineering team. The CVE feed has always been a starting point for triage, not a verified source of truth. What AI-assisted research changes is the rate at which plausible but incorrect entries can enter the feed.

The verification norm doesn't exist yet, and that's the actual problem

AI models used carefully can accelerate legitimate vulnerability research. The same workflows that produced this fabricated CVE, done with independent source-level verification at each step, could plausibly surface real issues faster than manual review alone. The technique is not the problem.

The problem is that the security research community hasn't established a norm about what verification is required before publishing AI-assisted findings. There are norms around coordinated disclosure, around responsible handling of zero-days, around vendor notification windows. There are no widely accepted norms about what a researcher's duty is when AI assistance contributed materially to a finding. Do you disclose that? Is confirming code-level behavior sufficient, or is independent reproduction required? Who bears responsibility when a hallucinated finding makes it into the public record? These questions have obvious answers at the individual level and no answers at the community level.

This doesn't seem likely to get resolved quickly. The norm-setting processes in security research are informal and slow relative to how quickly AI-assisted research is being adopted. The gap between what researchers are doing and what the infrastructure was designed to handle is already visible in this incident, and it will widen before anyone agrees on the right standards. The more constructive path is for MITRE to get ahead of it with explicit submission requirements rather than for the community to work backward from a worse incident than this one.

A hallucinated CVE for SQLite is a contained, recoverable incident. The entry gets rejected, the triage work gets written off, and people learn something uncomfortable about what happens when AI output enters the vulnerability disclosure pipeline without verification. The contained version of this problem is still worth taking seriously, because the uncontained version is a fabricated CVE for an actively exploited vulnerability class that triggers emergency patch cycles across major infrastructure before anyone confirms the issue exists.

The CVE process was not built for a world where generating technically plausible vulnerability descriptions is cheap and fast. Adjusting it is not optional at this point. The question is whether that adjustment happens before or after something more damaging than a triage waste of time.

If you've been on the receiving end of a fabricated or AI-hallucinated CVE submission, whether as a vendor, a CNA, or a security team that triaged it before catching the issue, I'd like to hear how it surfaced and what the catch was. Specifically whether vendor confirmation or a failed PoC reproduction is what finally closed it.