LLM-generated CVE reports are polluting security databases

JFrog found something weird in the National Vulnerability Database: dozens of bogus SQLite CVEs that read like they were written by a language model told to invent security vulnerabilities. The reports claim critical bugs in SQLite that do not exist. They reference nonexistent versions, misquote changelogs, and hallucinate attack vectors. This is not just annoying spam. The NVD is the canonical source that every vulnerability scanner, dependency checker, and security team queries. If your CI pipeline flags a fake CVE, you waste hours proving it is fake. If you ignore it because you assume it is fake, you might miss a real one buried in the noise. The tell is the writing. Real CVE reports are terse and specific: version X.Y.Z, function name, crash condition, patch commit. These fake ones sound like an LLM was prompted with “write a critical security vulnerability” and no one checked if SQLite actually shipped that version or if the function exists. One report claims SQLite 3.999.0 has a heap overflow. SQLite is on 3.46 as of this year. Worse, some of these made it into CVSS scores and got severity ratings. Automated systems treated them as real. That means downstream tools like Dependabot or Snyk flagged them, which means developers wasted time on ghosts. The NVD accepts submissions from anyone. No barrier to entry. The assumption was that bad-faith reports would be rare because writing a plausible CVE takes effort. LLMs broke that assumption. Now someone can generate hundreds of fake reports in an afternoon, and the review process cannot keep up. I would treat any SQLite CVE from the past six months with suspicion until I see a commit in the SQLite repo or a statement from the maintainers. The security commons is being spammed, and the fix is not technical. It is moderation at scale, which no one has solved.

---

Source: SQLite Critical CVEs or LLM Slop?