Six Fake SQLite CVEs and a 10x Surge Expose a Broken Pipeline

Six CVEs published against SQLite in July 2026 — two carrying severity scores of 9.8 — turned out not to describe real vulnerabilities at all, and the episode now stands as the clearest evidence yet that AI-generated security reports are overwhelming the vulnerability disclosure process. JFrog researchers found that some of the functions cited in the reports did not exist in the affected versions, and none of the included proofs of concept reproduced the claimed bugs. SQLite's own CVE page states the six reports are not bugs, and the CVE records were subsequently rejected.

The reports looked legitimate. They described memory-safety bugs and included technical explanations and proof-of-concept code. That is precisely the problem: it has become cheaper to produce convincing vulnerability reports, and the cost of disproving them has not fallen.

How widespread is the problem?

The SQLite case is not isolated. Daniel Stenberg, who maintains curl, estimated last year that roughly 20% of incoming security reports were the product of AI slop. GitHub's CVE Numbering Authority received almost 4,000 CVE requests in May 2026, a roughly 10-fold increase year over year. GitHub did not blame the increase on AI and did not report a decline in submission quality, but the volume growth alone underscores how strained the disclosure process has become.

The asymmetry drives the damage. An AI model can identify a suspicious API call, sketch an exploit scenario and produce a professional-looking write-up in minutes. Verifying that scenario may require checking the exact release, tracing control flow, learning how data reaches the function, building a test environment and running the alleged exploit. The work is identical whether the report is accurate or fabricated, and it is expensive either way.

Once a CVE enters security feeds and public databases, correcting the original record does not automatically correct every copy. Vendors can remain on the defensive with customers who saw the original announcement long after it was disputed or rejected.

What counts as a "fake" CVE?

The label is used loosely, and the distinction matters. A fake CVE in common usage is one that was likely reported incorrectly — but incorrect does not mean deliberately misleading.

Several failure modes produce them:

• Static analysis that overlooks a validation check or misinterprets input as attacker-controlled
• A report describing a real function but claiming an invalid attack path
• A CVE identifier assigned and later discarded because the reported condition was not a vulnerability
• A deliberately fictitious report, which is a separate category

A dispute is not a fake CVE either. A vendor may contest a researcher's claims about exploitability, threat boundaries or whether a function was meant to process untrusted input. A dispute does not prove the researcher erred. Rejection does not prove fabrication — records can be rejected as duplicates or for administrative reasons. Even though a CVE identifier is not independent technical verification, the industry still needs to take real reports seriously.

Why the flood costs real money

Every hour a maintainer or security team spends disproving a false positive is an hour not spent on an actual security issue. With limited resources, incorrect reports delay or push out genuine vulnerabilities. That is the core operational risk: not that fake CVEs are dangerous in themselves, but that they consume the triage capacity needed to find the ones that are.

Reputational damage compounds the cost. A vulnerability announcement spreads quickly across scanner feeds, security databases and search results. A correction rarely travels as far. A vendor can spend weeks answering customers who saw the original report and never saw the retraction.

Can automation verify claims?

Manual triage cannot absorb the current volume. Automation can verify a claim against the actual affected release and configuration, and the verification process reduces to five questions:

• Are the attack prerequisites credible, including configuration and permissions?
• Does the purported function exist in the affected version?
• Can an attacker reach the vulnerable code — can it execute under the affected conditions, and can attacker-supplied input reach it?
• Can testers reproduce the behavior in a controlled test or with a proof of concept?
• Does the observed behavior exhibit the security impact described in the advisory?

Agentic tools can create test environments, analyze code paths, generate proofs of concept and record execution evidence for review. They cannot automatically resolve every claim. A proof of concept can fail even when a vulnerability is authentic, if the environment is incomplete or the trigger is wrong. Testers can reproduce a crash without proving the claimed exploitability. Those caveats are why human judgment remains crucial. But the tools can get teams closer to a reproducible answer before a single report consumes time across engineering, vulnerability management and customer support.

What would fix the pipeline?

No single policy resolves the problem, but several changes would reduce the friction: stronger submission evidence requirements, clearer reproduction status, clearer treatment of disputed records and faster correction of downstream data. Researchers who use AI assistance should validate their findings before submission.

Security teams and vendors carry their own obligations. A critical CVE score does not disclose whether a vulnerable path is reachable in their environment. A failed proof of concept does not mean all is well. Receiving a CVE ID does not excuse the technical work required to understand an issue.

AI is enhancing the ability to discover vulnerabilities, and it is simultaneously enabling the creation of solid-looking but incorrect claims. As reports proliferate, the differentiating investment for organizations is verification itself: building tests, reproducing results, checking assumptions and making evidence easier to assess. Agentic security testing is positioned to carry much of that load.