{"slug": "ai-slop-pollutes-the-cve-pipeline-with-fake-vulns", "title": "AI slop pollutes the CVE pipeline with fake vulns", "summary": "JFrog reported that six SQLite CVEs published by a new GitHub repository were fake, likely AI-generated, with CVSS scores ranging from 9.8 to 7.5, and none described a reproducible vulnerability. The bogus reports entered the NVD with CISA-supplied enrichment, highlighting weaknesses in the CVE pipeline as NIST's backlog of unprocessed CVEs exceeded 27,000 by the end of 2025, according to a Department of Commerce Inspector General report.", "body_md": "security\n\n# AI slop pollutes the CVE pipeline with fake vulns\n\nWith NIST still buried under its backlog, expect AI-generated bogus reports to continue\n\nNow AI is making fake vulnerabilities and polluting the ecosystem. A batch of critical- and high-rated SQLite CVEs that appeared in the NVD with CISA-supplied enrichment last week turned out to be technically bogus, according to security researchers, and their path into widely used databases exposes weaknesses in the CVE pipeline.\n\nSoftware supply chain security outfit JFrog [reported](https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/) last week that six supposed SQLite vulnerabilities published in a [larger batch](https://github.com/programmervuln/cveadvisory-) by a new, obscure GitHub repository were all complete garbage. Running the advisories through an AI checker suggested they were likely AI generated, JFrog said, and, upon testing, it found that none of the six SQLite reports, which carried CVSS scores ranging from 9.8 to 7.5, described a reproducible vulnerability.\n\nOne, an alleged use-after-free vulnerability in the open source database that Red Hat initially assigned a maximum 10.0 CVSS score to before lowering it, relied on a function that didn't exist in the affected SQLite version. Another UAF vulnerability with a 9.1 CVSS score cited source lines that weren't even related to the supposed flaw. When JFrog tested the accompanying proof-of-concept, it executed a valid query with no memory leaks or errors. The other four SQLite CVEs from the repo that JFrog tested were similarly fake.\n\nThe other 49 CVEs in the questionable GitHub repo claimed to be security vulnerabilities in the open-source RAW image processing library libraw and Arduino audio decoding library ESP32-audioI2S. While JFrog didn't test those as extensively, it said all are just as fake as the rest, aside from one which “contained a real bug wrapped in unverified CVE metadata.”\n\nA message posted to Openwall’s OSS-Security mailing list on Friday [indicated](https://www.openwall.com/lists/oss-security/2026/08/01/2) that MITRE had rejected the whole repo’s worth of vaporous vulnerabilities, but the whole thing should serve as an important lesson, poster and Oracle Solaris engineer Alan Coopersmith pointed out.\n\n“MITRE and most other CNAs which assign CVEs for code they don't produce themselves operate on the honor system, and trust CVE requesters to have verified the information they provide,” Coopersmith noted in the OSS-Security post. “The CNA is often not in a position of being able to verify the report themselves.”\n\nAs JFrog points out, the US National Institute of Standards and Technology (NIST), which manages the US National Vulnerability Database (NVD), used to provide a reliable backstop by manually reviewing and enriching CVE records after they entered the database. That process slowed dramatically in 2024 after a surge in vulnerability submissions, coupled with operational challenges, left the agency with a growing backlog of records it was unable to process.\n\nBy late 2024, the backlog had grown to [more than 17,000](https://www.theregister.com/security/2024/10/02/nvd-still-backlogged-with-17k-unprocessed-bugs/675161) unprocessed CVEs, despite NIST's [plan](https://www.theregister.com/security/2024/06/03/nist-turns-to-it-consultants-to-help-clear-nvd-backlog/1291393) to clear it by the end of fiscal year 2024 with contractor help. It continued to grow, reaching more than 27,000 by the end of 2025, according to a Department of Commerce Inspector General [report](https://www.oig.doc.gov/reports/?entry=70787) published in May 2026.\n\nTo make matters worse, the DoC IG concluded that NIST had been wasting money allocated to fixing the backlog due to a “lack of strategic planning and decisive action” that has led to the stack of unresolved issues continuing to grow.\n\nIn other words, the pipeline has no mandatory checkpoint at which every claimed vulnerability must be independently reproduced.\n\n“Because no step in today's system actually requires a proof-of-concept or bug reproduction, a plausible-sounding fake advisory can slide right through the pipeline and end up in GitHub Security Advisories, downstream databases, and enterprise scanners,” JFrog said. “This incident demonstrates a systemic issue with automated vulnerability ingestion.”\n\nWhat that means for security professionals, aside from having to deal with polluted vulnerability databases, is that bad advisories could waste time better spent chasing real issues. Because reputable databases can ingest unverified records, JFrog recommended several checks before defenders act on a newly published CVE.\n\nFirst off, if the vendor hasn’t corroborated the issue (SQLite maintainers don’t list the fake CVEs, for instance) it’s probably not legitimate. A lack of commit hash or pull request in the reference fields of a repo is also indicative of AI slop, as is suspicious metadata (i.e., missing CPE product definitions). Lastly, if the code references don’t appear to match real functions or point to parts of the code that don’t involve the supposed issue, that’s a good sign it’s just an AI hallucination.\n\nJFrog reported its findings to the GitHub Security Advisory team, Red Hat, and NVD, all of whom the company told us have flagged or removed the CVEs. GitHub hasn't yet, JFrog told us. We reached out to GitHub to inquire why the repo is still up, but didn’t hear back.\n\nAs for why someone might do this, JFrog speculates that it could be an attempt for someone to boost their research experience with fake reports, or to influence what automated CVE identification tools flag as actual vulnerabilities. In both cases, JFrog told us, that's just speculation. Either way, these 54 apparently bogus CVEs, JFrog security researcher Afek Berger said, are just one example of a problem they expect to see more often.\n\n\"Generative AI has lowered the effort required to produce a plausible-looking advisory to close to zero, while the effort required to verify one, review the source code, build the affected version, reproduce the PoC, is unchanged,\" Berger told us in an email. \"That asymmetry means that even well-resourced defenders and maintainers cannot manually validate every incoming report … this is a challenge the whole industry is facing in the AI era.\" ®", "url": "https://wpnews.pro/news/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns", "canonical_source": "https://www.theregister.com/security/2026/08/03/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns/5282462", "published_at": "2026-08-03 18:24:09+00:00", "updated_at": "2026-08-03 18:52:38.539149+00:00", "lang": "en", "topics": ["ai-ethics", "ai-policy"], "entities": ["JFrog", "NIST", "NVD", "CISA", "MITRE", "Red Hat", "SQLite", "Alan Coopersmith"], "alternates": {"html": "https://wpnews.pro/news/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns", "markdown": "https://wpnews.pro/news/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns.md", "text": "https://wpnews.pro/news/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns.txt", "jsonld": "https://wpnews.pro/news/ai-slop-pollutes-the-cve-pipeline-with-fake-vulns.jsonld"}}