Interesting side effects of everyone going ham with LLM-based security scans.
Someone released security advisories for SQLite, which the NIST National Vulnerability Database (NVD) promptly registered as CVE with a “Critical” CVSS score, acknowledged by CISA as an Authorized Data Publisher, yet security researchers were not able to reproduce the issue. Turns out all those vulnerabilities were hallucination.
The cited code didn't even exist in those versions or referenced unrelated logic.
When testing the PoC payloads they didn’t work (not triggering any crash).
None of these CVEs are listed on SQLite’s official advisory page (which is a gold standard for tracking actual vulnerabilities).
All advisories in this repo seem AI generated when testing them with[Gptzero]
This wasn't an isolated mistake, the entire repo is filled with AI slop:
A broader audit of 55 advisories published by the same GitHub account revealed that 54 were completely fabricated, while one contained a real bug wrapped in unverified CVE metadata.
How come those advisories made it to the CVE system? Because the agencies maintaining it are being overwhelmed by advisories and can no longer thoroughly verify them. So when an alarming, plausible advisory appears, cautiousness prevails, and they raise the CVE to warn impacted users in a timely manner:
The CVE submission process via MITRE's public form lacks any real identity verification, meaning virtuallyanyone can submit a vulnerability description and propose a CVSS score.
Historically, NIST acted as a reliable safety net for this system, experts at the National Vulnerability Database (NVD) manually analyzed, validated, and enriched incoming CVEs before giving them a stamp of approval. But that safety net broke in[February 2024].Hit by a massive surge in vulnerability reports, NIST effectively hit on deep analysis. CISA and other Authorized Data Publishers (ADPs) tried to step in with their own enrichment efforts, but the global pipeline is now fragmented and drowning in a massive backlog. 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 pipelineand end up in GHSA, downstream databases, and enterprise scanners.
So what? You might think, better be safe than sorry, isn't it? The thing is, those CVE have a lot of cascading effects. They feed vulnerability management and other software component analysis that flag the impacted pieces of software for patching. Many organizations are already struggling to patch everything in a timely manner, even when focusing on highs and critical, as the volume of vulnerabilities has been raising exponentially over the years. We're already struggling to do contextual triaging based on exploitability and exposure, add fake CVEs into the mix, and you're at risk of exhausting goodwill and make the entire vulnerability management system explode.
Worse, one could imagine attackers to use this technique and amplify supply chain attacks. To poison the well, they would then raise a plausible CVE. This would urge organizations to patch to the latest version, now tainted with the malicious payload.
Ironically, the solace might come from LLMs as well, leveraging them to automate advisory verification by generating proof of concepts at scale. This is a trend I'm seeing all over the place with generative AI: first, break a functioning, human-based workflow by flooding it with AI generated content, then, implement generative AI in the workflow review or approval process to keep up the pace.