"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," Alan Coopersmith wrote on the OSS-Security mailing list.
JFrog found six SQLite CVEs were technically bogus
Security vendor JFrog reported that six purported SQLite vulnerabilities published in a new, obscure GitHub repository were “complete garbage.” The advisories carried CVSS scores from 9.8 down to 7.5. After running the advisories through an AI checker and then testing them, JFrog concluded none of the six described a reproducible flaw.
JFrog detailed specific failures: one alleged use-after-free (UAF) vulnerability relied on a function that did not exist in the affected SQLite version; another UAF with a 9.1 CVSS score cited source lines unrelated to the claimed issue; and a proof-of-concept that JFrog executed simply ran a valid query with no memory leaks or errors. The other four SQLite CVEs the company tested were similarly fake.
Fifty-four suspect CVEs tied to libraw and ESP32-audioI2S
The GitHub repository contained 54 CVE claims in total. The remaining 49 records purported to be vulnerabilities in the RAW image processing library libraw and the Arduino audio decoding library ESP32-audioI2S. JFrog said it did not test those as exhaustively, but judged them “just as fake as the rest,” with the exception of one entry that "contained a real bug wrapped in unverified CVE metadata."
JFrog reported its findings to the GitHub Security Advisory team, Red Hat, and the National Vulnerability Database (NVD); the company said those parties have flagged or removed the CVEs. JFrog added, however, that GitHub "hasn't yet" removed the repository, and the company told reporters it had reached out to GitHub about why the repo remains live.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →NVD review slowed; backlog ballooned, DoC inspector general found
The episode exposed broader pipeline fragility tied to the U.S. National Institute of Standards and Technology (NIST), which manages the NVD. NIST historically provided a manual backstop—reviewing and enriching CVE records after they entered the database—but that process slowed dramatically in 2024 following a surge in submissions and operational challenges. By late 2024 the database backlog exceeded 17,000 unprocessed CVEs.
The backlog continued to grow, reaching more than 27,000 unprocessed CVEs by the end of 2025, according to a Department of Commerce Inspector General report published in May 2026. The DoC IG concluded NIST had been wasting money allocated to fix the backlog because of a "lack of strategic planning and decisive action" that allowed the unresolved stack to continue growing.
Automated ingestion, no required reproduction: how fake advisories slip through
JFrog summarized the systemic failure bluntly: "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." The company called the incident a demonstration of "a systemic issue with automated vulnerability ingestion."
JFrog's security researcher Afek Berger emphasized the asymmetry introduced by generative AI: it has drastically lowered the effort required to produce a plausible-looking advisory, while the effort to verify a report—review source code, build affected versions, reproduce the PoC—remains unchanged. That imbalance, Berger said, makes it infeasible for even well-resourced maintainers and defenders to manually validate every incoming report.
What this means for SQLite maintainers, enterprise defenders, and CNAs
- SQLite maintainers: the fake CVEs did not appear on the project’s own lists, and JFrog recommended vendors not corroborating an issue are a strong signal the record is likely illegitimate.
- Enterprise defenders and vulnerability scanners: JFrog warned that polluted databases can waste time chasing non-existent flaws and proposed verification steps—check vendor corroboration, look for commit hashes or pull requests in references, watch for missing CPE product definitions, and validate that cited code lines and function names match the actual repository.
- CNAs, NVD, and repository platforms (GitHub): the incident highlights the lack of a mandatory independent reproduction checkpoint and places pressure on these organizations to decide whether to require more rigorous verification before ingesting or publishing CVE metadata.
Responses and next steps already underway
MITRE reportedly rejected the repository’s batch of vulnerabilities, according to a message posted to the OSS-Security mailing list. JFrog said it notified the GitHub Security Advisory team, Red Hat, and NVD; the company reported that those entities have flagged or removed the bogus CVEs. The Department of Commerce Inspector General’s May 2026 report documenting NVD backlog problems underscores that resource and process shortfalls are already documented at the federal oversight level.
JFrog also suggested motives for the fake submissions—speculatively, someone might try to boost their research résumé with fabricated reports or to influence what automated CVE-identification tools learn—but the company labeled those scenarios as speculation rather than established fact.
The episode leaves a clear, documentable gap: a set of apparently AI-generated, high-scoring CVEs moved from a public GitHub repository into the shared vulnerability ecosystem with little independent reproduction required. Whether platforms and CNAs will add mandatory reproduction steps, tighten ingestion filters, or scale manual review remains to be seen; the May 2026 DoC IG report indicates the NVD’s capacity challenges are already known to federal overseers.
