AI Slo p Pollutes CVE Pipeline
The vulnerability ecosystem is under attack from an unexpected direction — generative AI is being used to fabricate convincing but entirely bogus CVE reports, clogging the pipeline with technical garbage that wastes defenders' time and exposes systemic weaknesses in how we track software flaws.
A batch of 54 supposedly critical and high-severity vulnerabilities recently flooded the National Vulnerability Database (NVD). The list included six SQLite CVEs carrying CVSS scores from 9.8 down to 7.5, along with claims against libraw and ESP32-audioI2S libraries. What security researchers discovered after testing them? They were all complete fabrications — AI hallucinations masquerading as real threats.
The JFrog Investigation: All Six SQLite CVEs Are Bogus
Software supply chain security company JFrog conducted a thorough investigation of the suspicious GitHub repository that had submitted these vulnerabilities. Their findings were unequivocal:
- Six alleged SQLite use-after-free vulnerabilities — all proven non-reproducible. One carried an initial CVSS 10.0 score from Red Hat before they lowered it; another claimed a 9.1 severity but cited source lines unrelated to the supposed flaw
- When JFrog tested the accompanying proof-of-concept code, it executed a perfectly valid query with no memory leaks or errors whatsoever
- The repository's metadata told additional stories of fabrication: missing CPE product definitions, absent commit hashes, and pull request references that pointed nowhere
JFrog security researcher Afek Berger summed it up bluntly: "Running the advisories through an AI checker suggested they were likely AI generated." Upon manual testing, none of the six SQLite reports described a reproducible vulnerability.
The remaining 49 CVEs in the repository targeted the open-source RAW image processing library libraw and Arduino's ESP32-audioI2S audio decoding library. JFrog tested these as extensively as the SQLite ones — they were just as fake, except for one that "contained a real bug wrapped in unverified CVE metadata."
MITRE Rejected the Entire Repository
Word posted to Openwall's OSS-Security mailing list confirmed what security teams had been suspecting: MITRE had rejected the entire repository's vulnerabilities. The rejection underscores a fundamental breakdown in the current system.
Engineer Alan Coopersmith of Oracle Solaris highlighted the core issue: "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. The CNA is often not in a position of being able to verify the report themselves."
In other words, the CVE assignment process relies entirely on the submitter's word, there's no mandatory checkpoint requiring independent reproduction or proof-of-concept validation.
How Fake Advisories Slip Through: A Systemic Failure
The incident reveals a dangerous asymmetry in today's vulnerability ecosystem. As Berger noted, "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."
That imbalance means even well-resourced defenders and maintainers cannot manually validate every incoming report. The pipeline has no gatekeeper.
The NVD used to provide a reliable backstop: NIST manually reviewed and enriched CVE records after they entered the database. But that process slowed dramatically in 2024. By late that year, the backlog had grown to more than 17,000 unprocessed CVEs, despite NIST's plan to clear it with contractor help. A Department of Commerce Inspector General report published in May 2026 revealed the backlog continued growing, reaching more than 27,000 by end of 2025.
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." The stack of unresolved issues keeps growing while verification checkpoints remain optional rather than mandatory.
Why Someone Would Do This: Boosting Stats or Gaming Tools?
JFrog speculates on possible motivations, perhaps someone trying to boost their research experience with fake reports, or attempting to influence what automated CVE identification tools flag as actual vulnerabilities. Berger called these "just speculation," but either scenario points to a problem the industry expects to see more of.
The asymmetry is stark: creating a convincing fake advisory now requires almost no effort, while verifying one demands substantial resources and access to build environments. That's a challenge the whole industry is facing in the AI era.
What Security Professionals Should Do: A Checklist for Verification
JFrog outlined practical checks defenders should run before acting on newly published CVEs:
- Vendor corroboration, If the vendor hasn't confirmed the issue (SQLite maintainers didn't list these fake CVEs, for instance), it's probably not legitimate
- Check commit hashes and PR references, A lack of these in the advisory's reference fields is indicative of AI slop
- Scrutinize metadata, Missing CPE product definitions are a red flag
- Verify code references match real functions, If the cited source lines don't involve the supposed issue or point to non-existent functions, it's an AI hallucination
JFrog reported its findings to GitHub Security Advisory team, Red Hat, and NVD. All three flagged or removed the CVEs. GitHub hasn't yet acted on them, though JFrog noted they had been reached out to without a response.
The Bigger Picture: We Need Better Gatekeepers
This incident should serve as an important lesson for the entire vulnerability ecosystem. The honor system isn't sufficient when AI can generate plausible-sounding technical reports in seconds. Some form of mandatory verification, whether through automated analysis, vendor confirmation requirements, or independent review checkpoints, needs to become part of the pipeline before unverified records reach enterprise scanners and security teams.
Until then, defenders should expect more noise and focus their energy on signals that actually come from verified sources. The signal-to-noise ratio is getting worse, and AI slop makes it worse still.
This article was originally published by Brandon Vigliarolo for The Register on August 3, 2026.
Related reading:
- The Timeline Vulnerability Management Was Built On Has Disappeared
- AI Accelerates Vulnerability Discovery: Record 206 CVEs on Patch Tuesday Signal New Normal