SQLite Critical CVEs or LLM Slopes

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 slopes 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:

1. The cited code didn't even exist in those versions or referenced unrelated logic.
2. When testing the PoC payloads they didn’t work (not triggering any crash).
3. None of these CVEs are listed on SQLite’s official advisory page (which is a gold standard for tracking actual vulnerabilities).
4. 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 slops.

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

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 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.

Red Flags to Spot Slop CVEs:

• Missing Vendor Corroboration: No mention of the issue on official maintainer security pages (e.g., 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.

These 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.

In 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.

To avoid being affected by this kind of vulnerability noise:

• Don't blindly trust newly published CVEs by unknown/unvalidated sources.
• Investigate such critical CVEs to understand whether the score matches the vulnerability.
• Check if your environment is truly affected by the CVE.
• Reproduce the reported issue with the provided PoC whenever possible in a safe environment.

Reported Findings

We have also formally reported these findings to GHSA, Redhat and NVD to assist in the remediation of these records.