AI Slop Infiltrates CVE Pipeline as JFrog Uncovers 54 Fabricated Security Flaws

AI slop pollutes the CVE pipeline with fake vulns

Now 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. Software supply chain security outfit JFrog reported last week that six supposed SQLite vulnerabilities published in a larger batch 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. One, 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. The 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." A message posted to Openwall's OSS-Security mailing list on Friday indicated 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. "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." As 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. By late 2024, the backlog had grown to more than 17,000 unprocessed CVEs, despite NIST's plan 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 published in May 2026. To 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. In other words, the pipeline has no mandatory checkpoint at which every claimed vulnerability must be independently reproduced. "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." What 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. First 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. JFrog 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. As 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. "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." ®

AI slop is flooding the CVE pipeline with fake flaws

A batch of critical SQLite vulnerabilities turned out to be AI-generated fiction, yet they reached the US government's official database. The pipeline runs on trust no one is checking, and the systems most likely to be fooled are the AI agents now trusted to fix real bugs. The software industry runs on a shared list of known bugs. Someone is now seeding that list with breakage that no one ever found. Security firm JFrog found six critical SQLite flaws that were pure fiction, it reported. The advisories claimed severe memory bugs with scores up to 9.8. But the functions they blamed did not exist in the versions cited, and the proof-of-concept code ran without a crash. Fed through the detector GPTZero, the write-ups came back as machine-generated. They were AI slop. And not just six. One new GitHub account posted 55 vulnerability reports in a matter of days, and JFrog found 54 fabrications. Only one held a real bug, wrapped in bogus metadata. The rest invented holes in SQLite, the image library libraw and an Arduino audio decoder. Red Hat briefly rated one SQLite entry a perfect 10.0, then lowered it to 7.6. SQLite added the function it blamed in 2025, a year after the version it supposedly broke. How fiction became official The fakes did not stay on GitHub. They reached the National Vulnerability Database, the US government's authoritative record. There the NVD marked them critical, and a CISA team enriched them. Once a vulnerability lands there, scanners and defenders worldwide treat it as real. It works on trust. Anyone can submit a CVE through MITRE's public form, and the bodies that assign them largely take the submitter's word. "The CNA is often not in a position of being able to verify the report themselves," noted Oracle engineer Alan Coopersmith. NIST used to be the backstop. Its experts reviewed each record by hand. Then a flood of submissions forced them to pause deep analysis in early 2024. The backlog passed 27,000 unprocessed reports by the end of 2025. A federal watchdog said the agency wasted money failing to clear it. No step in the pipeline now requires anyone to reproduce a bug. The machines fool the machines The real danger is what reads these entries next. Security teams increasingly point AI coding agents at their code to fix reported flaws. Hand one a fabricated CVE and it may hunt for a vulnerable function nobody ever wrote. Then it changes working code to patch a problem that does not exist. The loop barely has a human in it. One AI writes a plausible advisory, a thinly staffed pipeline waves it through, and another AI tries to fix it. The same fluency without substance already dogs AI-written code. JFrog's Afek Berger framed it as an asymmetry. Generating a convincing fake now costs almost nothing, he said. Verifying one costs exactly what it always did: read the source, build the version, run the proof of concept. Even well-resourced defenders cannot check every report by hand. CISA and NIST are too far behind to help. The honour system never anticipated machines that can lie at scale.