SQLite Critical CVEs or LLM Slop?

SQLite Critical CVEs or LLM Slop?

• ID: 6e38ee0d
• 原文链接: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops
• 作者 / 日期: Afek Berger, JFrog Security Researcher | 30 Jul, 2026
• 分类: industry
• 来源类型: article
• 标签: ai-slop, security, cve, vulnerability-research
• 质量评分: 4/5
• 抓取时间: 2026-08-05T12:25:56.344927+00:00

中文导读

JFrog 对一批新建 GitHub repo 发布的 SQLite 高危 CVE 进行核查，发现引用代码不存在或与漏洞逻辑无关PoC 无法触发 crashSQLite 官方 advisory 未收录，并指出这些 advisory 很可能是 AI-generated CVE slop这个案例对自动化漏洞提交NVD/CISA 流程和安全情报污染都是直接警示

为什么值得关注

这篇文章把“AI 生成漏洞情报污染”从抽象风险落到具体 CVE 流程：新建 GitHub 仓库提交的 SQLite 高危 CVE 被 NVD/CISA ADP 采纳或富集，但源代码、PoC、官方公告和元数据核查均无法支撑多数结论。对使用 AI 做漏洞分诊、补丁生成或工单优先级排序的团队，这是一个直接的输入污染案例。

关键要点

• JFrog 核查了 programmervuln/cveadvisory- 仓库发布的一批 SQLite advisories，并认为 50+ CVE 中除一个外大多属于 LLM slop。
• 多条 advisory 引用不存在的函数、错误签名、超出文件长度的行号，或声称存在并未发生的修复 diff。
• PoC 在 ASan/隔离构建中未触发宣称的崩溃；SQLite 官方 CVE 页面也没有收录这些问题。
• 文章指出 MITRE 公共提交、NVD backlog 与 ADP 富集流程组合后， plausible-looking fake advisory 可能进入下游安全数据库。

English Summary

JFrog Security Research investigated a batch of SQLite vulnerability advisories from a newly created GitHub repository. The article reports that referenced code did not exist or pointed to unrelated logic, PoC payloads did not trigger crashes, SQLite official advisories did not list the issues, and the collected advisories looked AI-generated under GPTZero. The case illustrates how LLM-generated security claims can pollute CVE and vulnerability triage workflows.

OpenCLI Extract

SQLite Critical CVEs or LLM Slop?

原文链接: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops

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:

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

[内容截断] 原文较长，本页保留 OpenCLI 抽取的关键前半段；完整来源见原文链接。

Obsidian Notes

• 内容由 opencli web read --url "https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops" --stdout --download-images=false --wait 3 -f md 抽取。
• 中文导读和关键要点基于原文可见段落与条目既有摘要整理。