SQLite"漏洞"还是AI幻觉？JFrog安全剖析

Afek Berger，JFrog 安全研究员 | 2026 年 7 月 30 日

过去几天，一个新建的 GitHub 仓库（programmervuln/cveadvisory-）发布了一批 SQLite 漏洞通报（作为其他 50+ CVE 的一部分，我们认为除了其中一个外都是 LLM 生成的垃圾内容）。NVD 迅速将其标记为严重漏洞，CISA 的 ADP 也表示同意。但当 JFrog 安全研究人员深入调查验证时，相关主张全部站不住脚：

引用的代码在这些版本中甚至不存在或涉及无关逻辑。

测试 PoC 有效负载时它们不起作用（不会触发任何崩溃）。

这些 CVE 都没有列在 SQLite 的官方通报页面上（这是追踪实际漏洞的黄金标准）。

此仓库中所有通报在用 Gptzero 测试时似乎都是 AI 生成的

将所有通报合并到一个文件中会触发 AI 生成内容警告

这让我们质疑这些 CVE 的可靠性，同时也认识到这些 CVE 可能是 LLM 生成的垃圾内容。

在昨天调查其中一个 CVE（CVE-2026-51302）时，我们看到 Red Hat 最初为其分配了 10.0 严重等级的分数：

今天再看这个 CVE，我们注意到分数已经被降级为 7.6 高等级。

为了全面验证这些报告，我们建立了一套隔离的测试工作流：

源代码检查： 我们克隆了官方 sqlite/sqlite 仓库，并检出目标标签（版本 3.41.0、3.51.2 和 3.51.3）。我们将报告的漏洞机制与实际源代码进行了对比。

清洁环境构建： 在隔离的 Docker 容器内直接编译官方 SQLite 版本，以防止环境污染。

PoC 执行： 将每个通报的 PoC SQL 语句逐字输入到在 AddressSanitizer (ASan) 工具下编译的 SQLite 二进制文件中，以检测内存错误。

NVD 和元数据审计： 评估 NVD 和 GHSA 数据源中的 CPE 模式和通报元数据，以交叉验证追踪准确性。

1. CVE-2026-51302：不存在的逻辑（9.8 严重）

报告的漏洞： 通报声称当 sqlite3ReleaseTempReg() 在 regFree1 中留下一个悬垂指针时，会发生堆使用后释放 (UAF)，该指针随后被 exprComputeOperands() 解引用。

发现： 这里的主要问题是 exprComputeOperands() 在 SQLite 3.41 中根本不存在。它是在 2025 年中期添加的（提交 e24f20a、280559b）。此外，sqlite3ReleaseTempReg() 的机制不涉及堆释放。该函数只是将寄存器索引回收到数组中以供重用，根据设计这使 UAF 不可能发生。

/* 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 测试： 查询成功运行，未触发崩溃，因为该漏洞根本不存在。

2. CVE-2026-51303：虚幻的修复（9.8 严重）

报告的漏洞： 声称 ExprListDelete() 在释放子节点时未能清除父结构中的反向引用，据称在版本 3.51.3 中已修补。

发现： 没有证据表明 Expr、Select 或 Window 结构中存在可能导致此类状态的反向引用指针。最有说服力的是，3.51.2 和 3.51.3 之间的 diff 显示 src/expr.c 完全没有改动。该"修补"完全是杜撰的。

PoC 测试： PoC 是无效的 SQL，在解析器阶段失败，从未实际触及执行逻辑。

3. CVE-2026-51300：错误的调用位置（9.1 严重）

报告的漏洞： 声称在 sqlite3ExprDelete() 中发生 UAF，因为左手表达式指针未被清除，引用 expr.c 中的特定行号。

发现： 引用的行号（1012 和 1026）分别是一条注释和一个内存分配调用，两者都与 pLeft 或删除逻辑无关。虽然该函数在 OOM 错误处理期间被调用，但它发生在作用域末尾，指针在那里不会被重用，防止了任何潜在的 UAF。

/* expr.c:1330, SQLite 3.41.0 */
void sqlite3ExprDelete(sqlite3 *db, Expr *p){
  if( p ) sqlite3ExprDeleteNN(db, p);
}

PoC 测试： 作为有效的 SQL 查询执行成功，返回预期输出，零内存泄漏或错误。

4. CVE-2026-51297（8.8 高）

报告的漏洞： 声称 jsonParseFree() 留下悬垂引用，随后被 jsonBlobEdit() 访问。

发现： 类似于第一种情况，jsonBlobEdit() 在报告的目标版本（3.41.0）中并不存在。它仅在后来作为 JSONB 实现的一部分引入。在目标版本中，jsonParseFree() 仅在析构函数中使用，其中周围的结构立即被丢弃。

PoC 测试： PoC 立即遇到格式错误的 JSON，意味着代码从未到达假设存在漏洞的 JSON 修改逻辑。

5. CVE-2026-51296：不可能的行号（7.5 高）

报告的漏洞： 报告 json.c 第 3555 和 3575 行的 jsonRemoveFunc 中存在 UAF。

发现： 在版本 3.41.0 中，src/json.c 仅有 2706 行。引用的行号不存在。函数的实际实现大约在 2000 行之前，对该代码的审计显示没有内存管理缺陷。

PoC 测试： 有效负载在 JSON 解析期间失败，使内存保持不变。

6. CVE-2026-51304 CVSS 7.5（高）

报告的漏洞： 声称 sqlite3ExprListDelete(pOrderBy) 释放排序列表，而后续代码读取 pOrderBy->nExpr。

发现： 通报中报告的单参数签名不存在。实际签名需要一个指向数据库上下文的指针 (sqlite3 *db)。此外，SQLite 在删除后明确地将指针设为空：

/* select.c:3761, SQLite 3.41.0 */
sqlite3ExprListDelete(db, pPrior->pOrderBy);
pPrior->pOrderBy = 0;   /* Pointer immediately cleared; impossible to dereference */

PoC 测试： PoC 有效负载针对 20 列的 ORDER BY 查询执行，正常处理并返回排序结果，无任何问题。

漏洞提交流程中的缺陷

通过 MITRE 的公共表格进行 CVE 提交的过程缺乏任何真正的身份验证，这意味着几乎任何人都可以提交漏洞描述并提议 CVSS 分数。

从历史上看，NIST 一直是该系统的可靠安全网。国家漏洞数据库 (NVD) 的专家手动分析、验证和丰富传入的 CVE，然后给予批准。但这个安全网在 2024 年 2 月被打破了。

由于漏洞报告激增，NIST 实际上暂停了深入分析。CISA 和其他授权数据发布者 (ADP) 试图通过自己的丰富工作介入，但全球管道现已分散且淹没在巨大的积压中。因为当今系统中没有任何步骤实际上要求提供概念验证或漏洞复现，听起来很有道理的虚假通报可以直接通过管道滑过，最终出现在 GHSA、下游数据库和企业扫描工具中。

这个事件暴露了自动化漏洞摄取的系统性问题。对同一 GitHub 账户发布的 55 个通报进行的更广泛审计显示，54 个完全是虚构的，而一个包含用未验证的 CVE 元数据包装的真实漏洞。

识别 LLM 垃圾内容 CVE 的警告信号：

缺少供应商证实： 官方维护者安全页面上没有提及该问题（例如 sqlite.org/cves.html）。

缺少提交历史： 在参考字段中没有链接提交哈希或拉取请求。

元数据矛盾： 空的 CPE 产品定义或与通报描述冲突的版本范围。

代码引用不存在： 引用在声称的目标版本中不存在的函数或超出 EOF 的行号。

影响和建议

这些 LLM 生成的垃圾 CVE 可能导致组织浪费时间调查和修补实际上不存在的漏洞，以及污染漏洞数据库。在严重漏洞被自动优先处理或基于漏洞分数开票的环境中，此类虚构的 CVE 可能成为真正的负担。

在使用 AI 自动化漏洞分类和修复的环境中，这变得更加令人担忧。遇到虚构 CVE 的 AI agent 可能会尝试定位易受攻击的函数、生成修补或建议对甚至不存在的代码进行更改。与其帮助安全团队修复真实漏洞，它可能引导他们走上完全错误的道路，可能引入不必要的更改并浪费时间。

避免受到这类漏洞噪音影响的方法：

不要盲目相信来自未知/未验证来源的新发布 CVE。

调查此类严重 CVE 以了解分数是否与漏洞相符。

检查你的环境是否真的受到 CVE 影响。

尽可能在安全的环境中用提供的 PoC 复现报告的问题。

我们也已正式向 GHSA、Redhat 和 NVD 报告了这些发现，以协助这些记录的修复。