54 Fake CVEs Reached the NVD: AI Slop Breaks the Vuln Pipeline

Vulnerability tracking infrastructure has a new problem. Not attackers finding real bugs at scale. The opposite: attackers (or researchers, or bots, nobody is certain yet) submitting AI-generated fake vulnerabilities that look real enough to pass through the CVE pipeline, reach the National Vulnerability Database, and get enriched by CISA before anyone notices they describe holes that don’t exist.

JFrog’s security research team published findings on August 1 detailing what they found in a GitHub repository run by a new account. In a matter of days, that account had submitted 55 vulnerability reports. JFrog tested them. Fifty-four were fabrications. One described a real bug, wrapped in bogus metadata.

What the Fakes Targeted

The fabricated advisories claimed to identify critical flaws in three software packages: SQLite, the widely deployed database engine; libraw, a library for processing raw image files; and ESP32-audioI2S, an Arduino audio decoding library.

Six of the SQLite reports carried CVSS scores between 7.5 and 9.8. Critical ratings on one of the most audited open-source codebases in existence, from an account that didn’t exist until recently. That alone should have triggered scrutiny. It didn’t, at least not fast enough.

JFrog’s technical analysis of the SQLite reports found problems that are now textbook signs of AI-generated security slop. One alleged use-after-free flaw cited a function that wasn’t present in the specified SQLite version. Another pointed to source lines that had nothing to do with the vulnerability it claimed to describe. The proof-of-concept code, when run, executed cleanly. No crash, no memory leak, no error — the opposite of what a memory corruption PoC should produce.

GPTZero and similar AI-detection tools flagged the advisory write-ups as machine-generated text. The formatting was plausible. The content, once tested, was fiction.

How They Got In

The path from a GitHub issue to the NVD is not supposed to be easy. In practice, it turns out it’s easier than it should be.

MITRE’s CVE program lets anyone submit a vulnerability report through its public form. CNAs (CVE Numbering Authorities) often review submissions from domains outside their own software scope, and they’re “frequently not in a position to verify the report themselves.” Once a CVE ID is issued, the report flows to NVD, where it receives severity ratings and enrichment from a CISA-managed team. NVD then propagates to GitHub Security Advisories, vulnerability scanner databases, and downstream tooling worldwide.

There’s no step in that chain that requires a working proof-of-concept. The system runs on the honour system.

NIST added to the problem. Its backlog of unprocessed CVE reports grew to more than 17,000 by late 2024, then over 27,000 by end of 2025, as AI-assisted vulnerability discovery drove a surge in submissions. Deep human review — the kind that would have caught these fabrications early — quietly stopped. The infrastructure wasn’t built for the current volume.

The Asymmetry Problem

The JFrog report articulates the core issue clearly. Generative AI has reduced the effort required to produce a plausible-looking vulnerability advisory to nearly zero. A convincing write-up, complete with CVE references, CVSS score justifications, code samples, and a detailed description of the supposed impact, takes minutes to generate.

Verifying that advisory against the actual codebase takes hours. You need to find the relevant code path, reproduce the claimed condition, confirm that the function cited actually exists in the specified version, and test whether the proof-of-concept behaves as described.

The gap between generating a fake advisory and detecting one is the attack surface. Security teams chasing 54 fabricated critical vulnerabilities in SQLite are not chasing real ones. Every hour spent on a phantom CVE is an hour not spent on a genuine threat.

The possible motivations are varied. Inflating a bug-bounty or research portfolio with AI-generated reports is one theory. Manipulating automated CVE-scanning tools to produce false positive alerts in targeted organisations is another — if you can inject a fake critical CVE for a library your target uses, their vulnerability management system flags it as urgent and creates noise. Neither is proven in this case.

What Happened After

MITRE rejected the entire repository of questioned CVE entries after JFrog’s disclosure. Red Hat and NVD flagged or removed the affected CVEs from their platforms. The GitHub account’s status was still unclear at publication.

What didn’t happen is a fix to the underlying pipeline. The CVE ecosystem has no mandatory verification step to add without also slowing down legitimate vulnerability disclosure significantly. NIST’s backlog problem is a resource and prioritisation issue, not a technical one.

JFrog’s detection guidance is practical in the meantime. Check whether the cited functions actually exist in the specified version. Test the proof-of-concept if one is provided. Look for vendor acknowledgement before treating a CVE as confirmed. If a brand-new account is producing dozens of critical advisories in a week, treat that with suspicion proportional to how unusual it is.

The CVE pipeline took decades to build. It may take less than a prompt to break it.

References

• JFrog Security Research — SQLite Critical CVEs or LLM Slop?
• The Register — AI slop pollutes the CVE pipeline with fake vulns
• The Next Web — AI slop is flooding the CVE pipeline with fake flaws
• SC Media — Bogus SQLite vulnerabilities highlight flaws in CVE pipeline
• MITRE — Rejects Fabricated SQLite CVEs Tied to Suspect AI-Generated Reports