SQLite 심각한 취약점, 사실은 AI가 만든 가짜였다?

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 query ran successfully without triggering a crash because the bug does not exist. 2. CVE-2026-51303: Ghost Fixes (9.8 Critical) Reported Vulnerability: Claims that ExprListDelete() fails to clear back-references in parent structures when releasing child nodes, allegedly patched in version 3.51.3. Finding: There is no evidence of back-reference pointers in the Expr , Select , or Window structures 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 . The "patch" was entirely fabricated. PoC Testing: The PoC is invalid SQL and fails at the parser stage, never actually hitting the execution logic. 3. CVE-2026-51300: Misdirected Call Sites (9.1 Critical) Reported Vulnerability: Claims a UAF occurs in sqlite3ExprDelete() because a left-hand expression pointer is not cleared, referencing specific line numbers in expr.c . Finding: The cited line numbers ( 1012 and 1026 ) are a comment and a memory allocation call respectively, neither has anything to do with pLeft or 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. /* expr.c:1330, SQLite 3.41.0 */ void sqlite3ExprDelete(sqlite3 *db, Expr *p){ if( p ) sqlite3ExprDeleteNN(db, p); } PoC Testing: Executed successfully as a valid SQL query, returning expected output with zero memory leaks or errors. 4. CVE-2026-51297 (8.8 High) Reported Vulnerability: Claims jsonParseFree() leaves dangling references that are later accessed by jsonBlobEdit() . Finding: Similar to the first case, jsonBlobEdit() was 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() is used strictly in destructors where the surrounding structure is immediately discarded. PoC Testing: The PoC hits a malformed JSON error immediately, meaning the code never reaches the JSON modification logic where the vulnerability supposedly exists. 5. CVE-2026-51296: Impossible Line Numbers (7.5 High) Reported Vulnerability: Reports a UAF in jsonRemoveFunc specifically at lines 3555 and 3575 of json.c . Finding: In version 3.41.0, src/json.c is only 2706 lines 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. PoC Testing: The payload fails during JSON parsing, leaving the memory untouched. 6. CVE-2026-51304 CVSS 7.5 (HIGH) Reported Vulnerability: Claims sqlite3ExprListDelete(pOrderBy) frees the ordering list while subsequent code reads pOrderBy->nExpr . Finding: The single-argument signature reported in the advisory does not exist. the actual signature requires a pointer to the database context ( sqlite3 *db ). Furthermore, SQLite explicitly nulls pointers immediately after deletion: /* select.c:3761, SQLite 3.41.0 */ sqlite3ExprListDelete(db, pPrior->pOrderBy); pPrior->pOrderBy = 0; /* Pointer immediately cleared; impossible to dereference */ PoC Testing: The PoC payload executed against a 20-column ORDER BY query processed normally, returning sorted results with no issues. How Can AI Slop CVEs Happen The 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. 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 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. Key Takeaways This incident demonstrates a sy