{"slug": "critical-cve-issued-for-hallucinated-sqlite-vulnerability", "title": "Critical CVE issued for hallucinated SQLite vulnerability", "summary": "JFrog security researchers found that a batch of SQLite vulnerability advisories published by GitHub user programmervuln in the repo cveadvisory- are AI-generated 'LLM slop' and do not describe real vulnerabilities. The advisories, including CVE-2026-51302 initially scored 10.0 Critical by Red Hat and later downgraded to 7.6 High, cited non-existent functions, incorrect line numbers, and PoC payloads that did not trigger crashes when tested against official SQLite builds. NVD and CISA's ADP had flagged these as critical, but SQLite's official advisory page does not list them, and the repo's content triggers AI-generated content warnings.", "body_md": "Over the past few days, a newly created GitHub repo ([ programmervuln/cveadvisory-](https://github.com/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:\n\n- The cited code didn't even exist in those versions or referenced unrelated logic.\n- When testing the PoC payloads they didn’t work (not triggering any crash).\n- None of these CVEs are listed on SQLite’s official advisory page (which is a gold standard for tracking actual vulnerabilities).\n- All advisories in this repo seem AI generated when testing them with\n[Gptzero](https://app.gptzero.me/)\n\n*Combining all advisories into one file triggers AI-generated content warnings*\n\nThis made us question the reliability of these CVEs as well as understanding that these CVEs may be LLM slop.\n\nWhile investigating one of the CVEs yesterday, CVE-2026-51302, we saw that Red Hat initially assigned it a 10.0 Critical severity score:\n\nLooking at the CVE again today, we noticed that the score has since been downgraded to 7.6 High.\n\n**Analysis Matrix**\n\n**Analysis Matrix**\n\n| CVE | Reported Flaw | CVSS | NVD Metadata | Audit Finding |\n|---|---|---|---|---|\nCVE-2026-51302 |\nUAF in `exprComputeOperands()` |\n9.8 CRITICAL |\nPinned CPE: 3.41.0 | The advisory mentions non-existing functions. |\nCVE-2026-51303 |\nUAF in `ExprListDelete()` back-refs |\n9.8 CRITICAL |\nContradictory metadata | The advisory said there are non-existent fixes. |\nCVE-2026-51300 |\nUAF in `sqlite3ExprDelete()` |\n9.1 CRITICAL |\nn/a placeholders | Advisory cited lines that are unrelated to the vulnerability. |\nCVE-2026-51297 |\nUAF via `jsonBlobEdit()` |\n8.8 HIGH |\nPinned CPE: 3.41.0 | The advisory mentions non-existing functions. |\nCVE-2026-51296 |\nUAF in `jsonRemoveFunc` |\n7.5 HIGH |\nPopulated CPE: 3.41.0 | Advisory cited lines that do not exist. |\nCVE-2026-51304 |\nUAF via `pOrderBy->nExpr` post-free |\n7.5 HIGH |\nVendor/Product: n/a | Advisory showed a real function with a wrong argument number. |\n\n**Investigation Methodology**\n\n**Investigation Methodology**\n\nTo verify these reports thoroughly, we established an isolated testing workflow:\n\n**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.\n\n**Detailed Technical Breakdown**\n\n**Detailed Technical Breakdown**\n\n**1. CVE-2026-51302: Non-Existent Logic (9.8 Critical)**\n\n**1. CVE-2026-51302: Non-Existent Logic (9.8 Critical)**\n\n**Reported Vulnerability:** The advisory claims a heap use-after-free occurs when `sqlite3ReleaseTempReg()`\n\nleaves a dangling pointer in `regFree1`\n\n, which is later dereferenced by `exprComputeOperands()`\n\n.\n\n**Finding:** The primary issue here is that `exprComputeOperands()`\n\ndidn't exist in SQLite 3.41. It was added in the middle of 2025 (commits [e24f20a](https://github.com/sqlite/sqlite/commit/e24f20a), [280559b](https://github.com/sqlite/sqlite/commit/280559b)). Furthermore, the mechanics of `sqlite3ReleaseTempReg()`\n\ndo not involve heap deallocation. The function simply recycles register indices into an array for reuse, making a UAF impossible by design.\n\n```\n/* expr.c:6562, SQLite 3.41.0 */\nvoid sqlite3ReleaseTempReg(Parse *pParse, int iReg){\n  if( iReg ){\n    sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);\n    if( pParse->nTempReg < ArraySize(pParse->aTempReg) ){\n      pParse->aTempReg[pParse->nTempReg++] = iReg;\n    }\n  }\n}\n```\n\n**PoC Testing:** The query ran successfully without triggering a crash because the bug does not exist.\n\n**2. CVE-2026-51303: Ghost Fixes (9.8 Critical)**\n\n**2. CVE-2026-51303: Ghost Fixes (9.8 Critical)**\n\n**Reported Vulnerability:** Claims that `ExprListDelete()`\n\nfails to clear back-references in parent structures when releasing child nodes, allegedly patched in version 3.51.3.\n\n**Finding:** There is no evidence of back-reference pointers in the `Expr`\n\n, `Select`\n\n, or `Window`\n\nstructures that could lead to such a state. Most tellingly, a diff between 3.51.2 and 3.51.3 shows absolutely no changes to `src/expr.c`\n\n. The \"patch\" was entirely fabricated.\n\n**PoC Testing:** The PoC is invalid SQL and fails at the parser stage, never actually hitting the execution logic.\n\n**3. CVE-2026-51300: Misdirected Call Sites (9.1 Critical)**\n\n**3. CVE-2026-51300: Misdirected Call Sites (9.1 Critical)**\n\n**Reported Vulnerability:** Claims a UAF occurs in `sqlite3ExprDelete()`\n\nbecause a left-hand expression pointer is not cleared, referencing specific line numbers in `expr.c`\n\n.\n\n**Finding:** The cited line numbers (`1012`\n\nand `1026`\n\n) are a comment and a memory allocation call respectively, neither has anything to do with `pLeft`\n\nor deletion logic. While the function is called during OOM error handling, it occurs at the end of a scope where the pointer is never reused, preventing any potential UAF.\n\n```\n/* expr.c:1330, SQLite 3.41.0 */\nvoid sqlite3ExprDelete(sqlite3 *db, Expr *p){\n  if( p ) sqlite3ExprDeleteNN(db, p);\n}\n```\n\n**PoC Testing:** Executed successfully as a valid SQL query, returning expected output with zero memory leaks or errors.\n\n**4. CVE-2026-51297 (8.8 High)**\n\n**4. CVE-2026-51297 (8.8 High)**\n\n**Reported Vulnerability:** Claims `jsonParseFree()`\n\nleaves dangling references that are later accessed by `jsonBlobEdit()`\n\n.\n\n**Finding:** Similar to the first case, `jsonBlobEdit()`\n\nwas not present in the reported target version (3.41.0). It was only introduced later as part of the JSONB implementation. In the target version, `jsonParseFree()`\n\nis used strictly in destructors where the surrounding structure is immediately discarded.\n\n**PoC Testing:** The PoC hits a malformed JSON error immediately, meaning the code never reaches the JSON modification logic where the vulnerability supposedly exists.\n\n**5. CVE-2026-51296: Impossible Line Numbers (7.5 High)**\n\n**5. CVE-2026-51296: Impossible Line Numbers (7.5 High)**\n\n**Reported Vulnerability:** Reports a UAF in `jsonRemoveFunc`\n\nspecifically at lines `3555`\n\nand `3575`\n\nof `json.c`\n\n.\n\n**Finding:** In version 3.41.0, `src/json.c`\n\nis only `2706`\n\nlines long. The cited line numbers don't exist. The actual implementation of the function was found roughly 2000 lines earlier, and an audit of that code showed no memory management flaws.\n\n**PoC Testing:** The payload fails during JSON parsing, leaving the memory untouched.\n\n**6. CVE-2026-51304 CVSS 7.5 (HIGH)**\n\n**6. CVE-2026-51304 CVSS 7.5 (HIGH)**\n\n**Reported Vulnerability:** Claims `sqlite3ExprListDelete(pOrderBy)`\n\nfrees the ordering list while subsequent code reads `pOrderBy->nExpr`\n\n.\n\n**Finding:** The single-argument signature reported in the advisory does not exist. the actual signature requires a pointer to the database context (`sqlite3 *db`\n\n). Furthermore, SQLite explicitly nulls pointers immediately after deletion:\n\n``` php\n/* select.c:3761, SQLite 3.41.0 */\nsqlite3ExprListDelete(db, pPrior->pOrderBy);\npPrior->pOrderBy = 0;   /* Pointer immediately cleared; impossible to dereference */\n```\n\n**PoC Testing:** The PoC payload executed against a 20-column ORDER BY query processed normally, returning sorted results with no issues.\n\n**How Can AI Slop CVEs Happen**\n\n**How Can AI Slop CVEs Happen**\n\nThe CVE submission process via MITRE's public form lacks any real identity verification, meaning virtually anyone can submit a vulnerability description and propose a CVSS score.\n\nHistorically, 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](https://nvd.nist.gov/general/news/nvd-program-transition-announcement).\n\nHit by a massive surge in vulnerability reports, NIST effectively hit pause 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 pipeline and end up in GHSA, downstream databases, and enterprise scanners.\n\n**Key Takeaways**\n\n**Key Takeaways**\n\nThis incident demonstrates a systemic issue with automated vulnerability ingestion. 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.\n\n**Red Flags to Spot Slop CVEs:**\n\n**Missing Vendor Corroboration:** No mention of the issue on official maintainer security pages (e.g.,[sqlite.org/cves.html](https://sqlite.org/cves.html)).**Absent Commit History:** No commit hash or pull request linked in reference fields.**Metadata Contradictions:** Empty CPE product definitions or version ranges that conflict with the advisory narrative.**Non-existent Code References:** Citing functions that do not exist in the claimed target version or line numbers past EOF.\n\nThese LLM slop CVEs can cause organizations to waste time investigating and patching vulnerabilities that do not actually exist, as well as polluting vulnerability databases. In environments where Critical vulnerabilities are automatically prioritized or tickets are opened based on vulnerability scores, such fabricated CVEs can turn into a real burden.\n\nIn environments where AI is used to automate vulnerability triage and remediation this becomes even more concerning. An AI agent that encounters a fabricated CVE may attempt to locate the vulnerable function, generate a patch, or recommend changes based on code that does not even exist. Instead of helping security teams remediate real vulnerabilities, it can lead them down a completely wrong path, potentially introducing unnecessary changes and wasting time.\n\nTo avoid being affected by this kind of vulnerability noise:\n\n- Don't blindly trust newly published CVEs by unknown/unvalidated sources.\n- Investigate such critical CVEs to understand whether the score matches the vulnerability.\n- Check if your environment is truly affected by the CVE.\n- Reproduce the reported issue with the provided PoC whenever possible in a safe environment.\n\n**Reported Findings**\n\n**Reported Findings**\n\nWe have also formally reported these findings to GHSA, Redhat and NVD to assist in the remediation of these records.", "url": "https://wpnews.pro/news/critical-cve-issued-for-hallucinated-sqlite-vulnerability", "canonical_source": "https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/", "published_at": "2026-08-03 11:28:54+00:00", "updated_at": "2026-08-03 11:49:06.410710+00:00", "lang": "en", "topics": ["ai-ethics", "ai-safety"], "entities": ["JFrog", "SQLite", "NVD", "CISA", "Red Hat", "programmervuln", "cveadvisory-", "CVE-2026-51302"], "alternates": {"html": "https://wpnews.pro/news/critical-cve-issued-for-hallucinated-sqlite-vulnerability", "markdown": "https://wpnews.pro/news/critical-cve-issued-for-hallucinated-sqlite-vulnerability.md", "text": "https://wpnews.pro/news/critical-cve-issued-for-hallucinated-sqlite-vulnerability.txt", "jsonld": "https://wpnews.pro/news/critical-cve-issued-for-hallucinated-sqlite-vulnerability.jsonld"}}