针对AI幻觉生成的SQLite漏洞发布严重CVE

# SQLite 重大 CVE 还是 LLM 垃圾信息？| JFrog 来源：https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ 过去几天里，一个新创建的 GitHub 仓库（**programmervuln/cveadvisory-** (https://github.com/programmervuln/cveadvisory-)）发布了一批 SQLite 漏洞公告（作为其余 50+ 个 CVE 的一部分，我们认为除了其中一个之外，其他也都是 LLM 垃圾信息）。NVD 迅速将这些标记为“严重”，CISA 的 ADP 也表示同意。但当 JFrog 安全研究人员深入核实后，这些说法不攻自破： 1. 引用的代码在这些版本中根本不存在，或者引用的是无关逻辑。 2. 测试 PoC 载荷时它们并未生效（没有触发任何崩溃）。 3. 这些 CVE 均未出现在 SQLite 的官方公告页面上（该页面是追踪真实漏洞的黄金标准）。 4. 用 Gptzero (https://app.gptzero.me/) 测试时，该仓库中的所有公告似乎都是 AI 生成的。 *将所有公告合并到一个文件中会触发 AI 生成内容警告* 这让我们对这些 CVE 的可靠性产生了质疑，同时也意识到这些 CVE 可能是 LLM 垃圾信息。昨天在调查其中一个 CVE（CVE-2026-51302）时，我们看到 Red Hat 最初给出了 10.0 的严重性评分： 今天再次查看该 CVE 时，我们注意到评分已被降级为 7.6 高危。 | CVE | 报告缺陷 | CVSS | NVD 元数据 | 审计发现 | |------|----------|------|------------|----------| | **CVE-2026-51302** | `exprComputeOperands()` 中的 UAF | **9.8 严重** | 固定 CPE：3.41.0 | 公告提到了不存在的函数。 | | **CVE-2026-51303** | `ExprListDelete()` 中的 UAF 反向引用 | **9.8 严重** | 矛盾的元数据 | 公告声称存在不存在的修复。 | | **CVE-2026-51300** | `sqlite3ExprDelete()` 中的 UAF | **9.1 严重** | 不适用占位符 | 公告引用了与漏洞无关的代码行。 | | **CVE-2026-51297** | 通过 `jsonBlobEdit()` 的 UAF | **8.8 高危** | 固定 CPE：3.41.0 | 公告提到了不存在的函数。 | | **CVE-2026-51296** | `jsonRemoveFunc` 中的 UAF | **7.5 高危** | 已填充 CPE：3.41.0 | 公告引用了不存在的代码行。 | | **CVE-2026-51304** | 释放后通过 `pOrderBy->nExpr` 的 UAF | **7.5 高危** | 供应商/产品：不适用 | 公告展示了一个真实函数，但参数数量错误。 | 为了彻底验证这些报告，我们建立了一个隔离的测试工作流： - **源码检查：** 我们克隆了官方 sqlite/sqlite 仓库，并检出了目标标签（version-3.41.0、version-3.51.2 和 version-3.51.3）。我们将报告的漏洞机制与实际源代码进行了对比。 - **干净环境构建：** 直接在隔离的 Docker 容器中编译官方 SQLite 版本，以防止环境污染。 - **PoC 执行：** 将每个公告的 PoC SQL 语句原样输入到编译后的 SQLite 二进制文件中，并在 AddressSanitizer (ASan) 插桩下运行，以检测内存错误。 - **NVD 与元数据审计：** 评估了跨 NVD 和 GHSA 数据源的 CPE 模式与公告元数据，以交叉核对跟踪准确性。 **报告漏洞：** 公告声称，当 `sqlite3ReleaseTempReg()` 在 `regFree1` 中留下悬空指针，随后被 `exprComputeOperands()` 解引用时，会发生堆释放后使用。 **发现：** 这里最主要的问题是，`exprComputeOperands()` 在 SQLite 3.41 中并不存在。它是在 2025 年年中添加的（提交 e24f20a (https://github.com/sqlite/sqlite/commit/e24f20a)、280559b (https://github.com/sqlite/sqlite/commit/280559b)）。此外，`sqlite3ReleaseTempReg()` 的机制并不涉及堆释放。该函数只是将寄存器索引回收到一个数组中以便复用，因此设计上不可能发生 UAF。 ```c /* 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 测试：** 查询成功运行，未触发崩溃，因为该漏洞并不存在。 **报告漏洞：** 声称 `ExprListDelete()` 在释放子节点时未能清除父结构中的反向引用，并声称该问题已在 3.51.3 版本中修复。 **发现：** 在 `Expr`、`Select` 或 `Window` 结构中没有证据表明存在可能导致这种状态的反向引用指针。最明显的是，3.51.2 和 3.51.3 之间的差异显示 `src/expr.c` 完全没有变更。所谓的“补丁”完全是编造的。 **PoC 测试：** PoC 是无效 SQL，在解析阶段就失败，从未真正触及执行逻辑。 **报告漏洞：** 声称 `sqlite3ExprDelete()` 中存在 UAF，原因是左操作数表达式指针未被清除，并引用了 `expr.c` 中的具体行号。 **发现：** 所引用的行号（`1012` 和 `1026`）分别是一条注释和一次内存分配调用，两者都与 `pLeft` 或删除逻辑无关。虽然该函数在 OOM 错误处理期间会被调用，但它发生在指针不再被复用的作用域末尾，因此不可能出现 UAF。 ```c /* expr.c:1330, SQLite 3.41.0 */ void sqlite3ExprDelete(sqlite3 *db, Expr *p){ if( p ) sqlite3ExprDeleteNN(db, p); } ``` **PoC 测试：** 作为有效 SQL 查询成功执行，返回预期结果，零内存泄漏或错误。 **报告漏洞：** 声称 `jsonParseFree()` 留下了悬空引用，随后被 `jsonBlobEdit()` 访问。 **发现：** 与第一个案例类似，`jsonBlobEdit()` 在报告的目标版本（3.41.0）中并不存在。它是在后来作为 JSONB 实现的一部分才引入的。在目标版本中，`jsonParseFree()` 严格用于析构函数，而周围的构立即会被丢弃。 **PoC 测试：** PoC 立即触发畸形 JSON 错误，这意味着代码从未到达据称存在漏洞的 JSON 修改逻辑。 **报告漏洞：** 报告 `jsonRemoveFunc` 中存在 UAF，具体位置在 `json.c` 的第 `3555` 和 `3575` 行。 **发现：** 在 3.41.0 版本中，`src/json.c` 只有 `2706` 行。所引用的行号不存在。实际函数实现大约在 2000 行之前，对该代码的审计未发现任何内存管理缺陷。 **PoC 测试：** 载荷在 JSON 解析期间失败，内存完全未被触及。 **报告漏洞：** 声称 `sqlite3ExprListDelete(pOrderBy)` 释放排序列表，而后续代码读取 `pOrderBy->nExpr`。 **发现：** 公告中报告的单参数签名并不存在。实际签名需要指向数据库上下文的指针（`sqlite3 *db`）。此外，SQLite 会在删除后立即将指针显式置空： ```c /* select.c:3761, SQLite 3.41.0 */ sqlite3ExprListDelete(db, pPrior->pOrderBy); pPrior->pOrderBy = 0; /* 指针立即被清除；不可能被解引用 */ ``` **PoC 测试：** PoC 载荷在 20 列 ORDER BY 查询上执行，处理正常，返回排序结果，没有任何问题。 通过 MITRE 的公共表单提交 CVE 的流程缺乏任何真正的身份验证，这意味着几乎任何人都可以提交漏洞描述并给出 CVSS 评分。从历史上看，NIST 是该系统的可靠安全网，国家漏洞数据库（NVD）的专家会手动分析、验证和丰富传入的 CVE，然后才给予批准。但这条安全网在 2024 年 2 月 (https://nvd.nist.gov/general/news/nvd-program-transition-announcement) 破裂了。由于漏洞报告数量激增，NIST 实际上暂停了深度分析。CISA 和其他授权数据发布者（ADP）试图通过自己的丰富工作来介入，但全球管道现在已经碎片化，并且深陷海量积压之中。 由于当今流程中没有任何一步需要概念验证或漏洞复现，一份听起来合理的伪造公告就可以顺利通过管道，最终进入 GHSA、下游数据库和企业扫描器。这起事件表明自动化漏洞摄取存在系统性问题。对同一 GitHub 账户发布的 55 份公告进行的更广泛审计显示，54 份完全是被编造的，而其中一份包含了一个真实漏洞，但附带未经验证的 CVE 元数据。 **识别“垃圾 CVE”的危险信号：** - **缺少供应商证实：** 官方维护者安全页面上未提及该问题（例如，sqlite.org/cves.html (https://sqlite.org/cves.html)）。 - **缺少提交历史：** 参考字段中没有关联提交哈希或拉取请求。 - **元数据矛盾：** CPE 产品定义为空，或版本范围与公告叙述冲突。 - **不存在的代码引用：** 引用了在声称的目标版本中不存在的函数，或行号超过文件末尾。 这些 LLM 垃圾 CVE 可能会让组织浪费时间调查和修复实际上不存在的漏洞，同时也会污染漏洞数据库。在自动优先处理严重漏洞或根据漏洞评分自动开票的环境中，这类伪造 CVE 可能会变成真正的负担。在使用 AI 来自动化漏洞分类和修复的环境中，这种情况就更加令人担忧。AI 代理遇到伪造的 CVE 时，可能会尝试定位不存在的漏洞函数、生成补丁，或基于根本不存在代码提出变更建议。这不仅无法帮助安全团队修复真实漏洞，反而可能把他们引向完全错误的方向，引入不必要的更改并浪费时间。 为避免受此类漏洞噪音影响： - 不要盲目信任由未知/未经验证来源新发布的 CVE。 - 调查此类严重 CVE，了解评分是否与漏洞相符。 - 检查你的环境是否真的受该 CVE 影响。 - 在可能的情况下，于安全环境中使用提供的 PoC 复现所报告的问题。 我们还已经将这些发现正式报告给 GHSA、Red Hat 和 NVD，以协助修正这些记录。