SQLite Critical CVEs or LLM Slop? - JFrog Security Research

SQLite Critical CVEs or LLM Slop?<br>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<br>Reported Flaw<br>CVSS<br>NVD Metadata<br>Audit Finding

CVE-2026-51302<br>UAF in exprComputeOperands()<br>9.8 CRITICAL<br>Pinned CPE: 3.41.0<br>The advisory mentions non-existing functions.

CVE-2026-51303<br>UAF in ExprListDelete() back-refs<br>9.8 CRITICAL<br>Contradictory metadata<br>The advisory said there are non-existent fixes.

CVE-2026-51300<br>UAF in sqlite3ExprDelete()<br>9.1 CRITICAL<br>n/a placeholders<br>Advisory cited lines that are unrelated to the vulnerability.

CVE-2026-51297<br>UAF via jsonBlobEdit()<br>8.8 HIGH<br>Pinned CPE: 3.41.0<br>The advisory mentions non-existing functions.

CVE-2026-51296<br>UAF in jsonRemoveFunc<br>7.5 HIGH<br>Populated CPE: 3.41.0<br>Advisory cited lines that do not exist.

CVE-2026-51304<br>UAF via pOrderBy->nExpr post-free<br>7.5 HIGH<br>Vendor/Product: n/a<br>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 */<br>void sqlite3ReleaseTempReg(Parse *pParse, int iReg){<br>if( iReg ){<br>sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);<br>if( pParse->nTempReg aTempReg) ){<br>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...