Picture this: a Critical CVE with a CVSS score of 10.0 hits SQLite, the most widely deployed embedded database engine on the planet. Your scanning tools flag the alert, your teams prioritize the patch. Except the vulnerability simply does not exist. That is the finding just published by JFrog Security Research: out of 55 recent CVEs targeting SQLite, submitted over the span of four days by a single GitHub repository, 54 were technically baseless. These fake AI-generated SQLite CVEs slipped through every layer of the net, landing in the National Vulnerability Database with CISA enrichment. Here is a look back at a story that shakes up operational vulnerability management.
The SQLite case: 54 fake CVEs out of 55 in four days
Between July 26 and July 30, 2026, a freshly created GitHub repository (programmervuln/cveadvisory) published 55 vulnerability advisories targeting SQLite. On the surface, everything checked out: technical descriptions, high CVSS scores, PoCs (proofs of concept), and references to specific source code versions.
The NVD quickly integrated them, with enrichment provided by CISA as an Authorized Data Publisher (ADP). One of them, CVE-2026-51302, was even assigned a CVSS score of 10.0 (Critical) by Red Hat, before being downgraded to 7.6 (High) after review.
The problem? When JFrog researchers attempted to reproduce these vulnerabilities, everything collapsed. The functions cited in the advisories did not exist in the targeted versions. The PoCs triggered no crashes. The fixes mentioned were entirely fabricated. And none of these 55 advisories appeared on SQLite’s official CVE page, widely recognized as a trusted reference by the community.
Diving into the technical details: phantom vulnerabilities
JFrog put together a rigorous verification methodology: cloning the official SQLite repository, compiling in an isolated Docker environment, running PoCs with AddressSanitizer (ASan) instrumentation, and cross-auditing NVD metadata. Here is what came out of it.
Functions that simply did not exist
CVE-2026-51302 (initial score 9.8) claimed to describe a use-after-free in the exprComputeOperands() function. Problem: this function did not exist in SQLite 3.41.0, the targeted version. It was only introduced in mid-2025, via commits e24f20a and 280559b. The described mechanics involved sqlite3ReleaseTempReg(), a function that recycles register indices in an array and performs no memory deallocation whatsoever. A use-after-free was structurally impossible.
The same pattern for CVE-2026-51297 (8.8): the jsonBlobEdit() function was absent from version 3.41.0. It only appeared later, as part of the JSONB implementation.
Phantom fixes and impossible line numbers
CVE-2026-51303 claimed that a fix had been applied in version 3.51.3 to address improper handling of back-references in ExprListDelete(). A diff between versions 3.51.2 and 3.51.3 showed no changes to the src/expr.c file. The patch was purely fabricated.
Even more striking: CVE-2026-51296 (7.5) pointed to lines 3555 and 3575 of json.c. In version 3.41.0, that file only had 2,706 lines. The cited numbers exceeded the end of the file.
CVE-2026-51304, for its part, described a single-argument function signature that never existed in SQLite’s source code. The real signature requires a pointer to the database context (sqlite3 *db), and the actual code immediately nullifies the pointer after deallocation, making any exploitation impossible.
How did these fake CVEs slip through the cracks?
The CVE submission process via MITRE’s public form requires no serious identity verification. Anyone can submit a vulnerability description and propose a CVSS score. Historically, NIST acted as a safety net: NVD experts analyzed, validated, and manually enriched incoming CVEs before giving them a stamp of approval.
That safety net broke in February 2024. Faced with an explosion in the volume of vulnerability reports, NIST paused its in-depth analyses. CISA and other ADPs attempted to compensate with their own enrichments, but the global pipeline is now fragmented and overwhelmed by a massive backlog.
The result: since no step in the current system requires a working proof of concept or bug reproduction, a well-written fraudulent advisory can travel through the entire pipeline and end up in GHSA databases, enterprise scanners, and automated prioritization tools.
Red flags to spot a slop CVE
The SQLite episode provides a valuable framework for security teams. Here are the red flags identified by JFrog to detect an AI-generated CVE:
- Lack of vendor corroboration: the vulnerability does not appear on the maintainer’s official security page. For SQLite, that is sqlite.org/cves.html, a reference JFrog describes as the “gold standard.”
- No commit hash or pull request: the reference fields point to no verifiable code change in the official repository.
- Contradictory metadata: empty CPE definitions, version ranges incompatible with the advisory’s narrative.
- References to non-existent code: functions absent from the targeted version, line numbers exceeding the file length, incorrect function signatures.
- Detection by anti-AI tools: grouping the advisories into a single file triggered AI-generated content alerts on tools like GPTZero.
These slop CVEs are not harmless. They force organizations to investigate phantom vulnerabilities, waste research time, and, in environments where Critical vulnerabilities automatically trigger tickets, generate very real operational overhead for a non-existent risk.
The risk is amplified even further in organizations that use AI to automate vulnerability triage and remediation. An AI agent facing a fake CVE may attempt to locate a function that does not exist, generate a useless patch, or recommend changes based on ghost code.
Key takeaways
- Out of 55 SQLite CVEs published in four days by a single GitHub repository, 54 were fabricated: non-existent functions, invented fixes, non-functional PoCs.
- These fake CVEs, likely generated by an LLM, reached the NVD with CISA enrichment, proving that the validation pipeline is now overwhelmed.
- CVSS score and presence in the NVD are no longer enough to guarantee a vulnerability’s legitimacy.
- Systematically validate the advisory, PoC, and source code before prioritizing or applying a fix, especially when the vendor has published nothing.
- The red flags are identifiable: missing commits, contradictory metadata, references to non-existent code.
This episode marks a turning point. Automated generation of fake CVEs by AI is no longer a hypothesis, it is a proven problem. If you manage infrastructure where patches are deployed based on CVSS scores, the time has come to strengthen your verification process.
Have you come across suspicious CVEs in your environments? The conversation is always open on the blog or on social media. Consider subscribing to receive the next deep dives.
Sources
- JFrog Security Research: original article “SQLite Critical CVEs or LLM Slop?” by Afek Berger (July 30, 2026), research.jfrog.com
- JFrog Security on X: public alert from July 29, 2026
- The Register: journalistic coverage confirming the arrival of fake CVEs in the NVD with CISA enrichment
- SQLite Advisory Page: official reference page sqlite.org/cves.html