Critical CVE issued for hallucinated SQLite vulnerability

JFrog Security Research Model Threats Discover Follow JFrog Security Theme Home Model Threats Discover Follow JFrog Security SQLite Critical CVEs or LLM Slop?Afek Berger, JFrog Security Researcher | 30 Jul, 2026 Over the past few days, a newly created GitHub repo (programmervuln/cveadvisory-) published a batch of SQLite vulnerability advisories (as part of other 50+ CVEs which we believe are also LLM slop except from one). NVD quickly flagged these as critical, and CISA's ADP agreed. But when JFrog security researchers dug in to verify, the claims fell apart: 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 Combining all advisories into one file triggers AI-generated content warnings This made us question the reliability of these CVEs as well as understanding that these CVEs may be LLM slop. While investigating one of the CVEs yesterday, CVE-2026-51302, we saw that Red Hat initially assigned it a 10.0 Critical severity score: Looking at the CVE again today, we noticed that the score has since been downgraded to 7.6 High. Analysis Matrix CVE Reported Flaw CVSS NVD Metadata Audit Finding CVE-2026-51302 UAF in exprComputeOperands() 9.8 CRITICAL Pinned CPE: 3.41.0 The advisory mentions non-existing functions. CVE-2026-51303 UAF in ExprListDelete() back-refs 9.8 CRITICAL Contradictory metadata The advisory said there are non-existent fixes. CVE-2026-51300 UAF in sqlite3ExprDelete() 9.1 CRITICAL n/a placeholders Advisory cited lines that are unrelated to the vulnerability. CVE-2026-51297 UAF via jsonBlobEdit() 8.8 HIGH Pinned CPE: 3.41.0 The advisory mentions non-existing functions. CVE-2026-51296 UAF in jsonRemoveFunc 7.5 HIGH Populated CPE: 3.41.0 Advisory cited lines that do not exist. CVE-2026-51304 UAF via pOrderBy->nExpr post-free 7.5 HIGH Vendor/Product: n/a Advisory showed a real function with a wrong argument number. Investigation Methodology To verify these reports thoroughly, we established an isolated testing workflow: Source Inspection: We cloned the official sqlite/sqlite repository and checked out the target tags (version-3.41.0, version-3.51.2, and version-3.51.3). We compared the reported vulnerability mechanics against the actual source code. Clean Environment Build: Compiled the official SQLite releases directly inside isolated Docker containers to prevent environmental contamination. PoC Execution: Feed each advisory's PoC SQL statements verbatim into the compiled SQLite binaries under AddressSanitizer (ASan) instrumentation to detect memory bugs. NVD & Metadata Audit: Evaluated the CPE patterns and advisory metadata across NVD and GHSA feeds to cross-check tracking accuracy. Detailed Technical Breakdown 1. CVE-2026-51302: Non-Existent Logic (9.8 Critical) Reported Vulnerability: The advisory claims a heap use-after-free occurs when sqlite3ReleaseTempReg() leaves a dangling pointer in regFree1, which is later dereferenced by exprComputeOperands(). Finding: The primary issue here is that exprComputeOperands() didn't exist in SQLite 3.41. It was added in the middle of 2025 (commits e24f20a, 280559b). Furthermore, the mechanics of sqlite3ReleaseTempReg() do not involve heap deallocation. The function simply recycles register indices into an array for reuse, making a UAF impossible by design. /* expr.c:6562, SQLite 3.41.0 */ void sqlite3ReleaseTempReg(Parse *pParse, int iReg){ if( iReg ){ sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0); if( pParse->nTempReg < ArraySize(pParse->aTempReg) ){ pParse->aTempReg[pParse->nTempReg++] = iReg; } } } PoC Testing: The quer