SQLite严重CVE还是LLM垃圾信息？

事件概述

JFrog安全研究团队近日发现，一个名为programmervuln/cveadvisory-的GitHub仓库批量发布了50多个SQLite漏洞公告，其中54个被确认为完全由AI生成的虚假漏洞。这些公告（如CVE-2026-51302、CVE-2026-51303等）被NVD标记为“严重”或“高危”，甚至CISA的ADP也一度认可。但JFrog团队通过源码审计、干净环境编译和PoC执行测试，发现所有漏洞根本不存在：引用的函数不存在于指定版本中，代码行号指向注释或无关逻辑，PoC SQL语句要么无法解析，要么正常执行不触发崩溃。SQLite官方漏洞页面也未列出任何相关CVE。

调查方法

研究人员采用了一套严格的验证流程：

• 从官方仓库克隆SQLite源代码，检出版本标签（3.41.0、3.51.2、3.51.3）。
• 在隔离的Docker容器中编译二进制文件，避免环境污染。
• 使用AddressSanitizer（ASan）工具运行每个PoC，检测内存错误。
• 交叉核对NVD、GHSA等元数据，检查CPE模式与版本范围是否一致。

结果所有PoC均未触发任何崩溃或内存泄漏，且元数据中存在大量矛盾（如引用不存在的函数、行号超出文件末尾、声称的补丁在版本差异中完全不存在）。

典型案例分析

CVE-2026-51302（9.8严重）

声称在exprComputeOperands()中发生use-after-free。但该函数在3.41.0版本中根本不存在，是2025年中才加入的。sqlite3ReleaseTempReg()仅回收寄存器索引，不涉及堆内存释放，不可能导致UAF。PoC运行正常。

CVE-2026-51303（9.8严重）

声称ExprListDelete()未清除父结构中的反向引用，并在3.51.3中修复。但3.51.2与3.51.3的diff显示src/expr.c完全没有变化。PoC本身是无效SQL，无法通过解析器。

CVE-2026-51300（9.1严重）

引用expr.c第1012和1026行，但这两行分别是注释和内存分配调用，与pLeft或删除逻辑无关。实际sqlite3ExprDelete()在作用域末尾调用，指针不会被重用。PoC执行成功。

CVE-2026-51297（8.8高危）

声称jsonParseFree()留下悬挂引用，由jsonBlobEdit()访问。但后者在3.41.0中不存在，是JSONB实现的一部分。PoC直接报JSON格式错误。

CVE-2026-51296（7.5高危）

引用的json.c第3555和3575行在3.41.0版本中不存在（文件仅2706行）。实际函数实现位置前移约2000行，且没有内存管理缺陷。PoC解析失败。

CVE-2026-51304（7.5高危）

声称sqlite3ExprListDelete(pOrderBy)释放后仍读取pOrderBy->nExpr。但该函数签名需要两个参数（sqlite3 *db），且SQLite在删除后立即将指针置零（pPrior->pOrderBy = 0），无法二次引用。PoC正常排序。

AI垃圾CVE如何产生

MITRE的CVE提交表单缺乏身份验证，任何人可提交漏洞描述并自拟CVSS分数。NIST曾在2024年2月因报告激增暂停深度分析，CISA等ADP的补充审核也因积压而碎片化。整个流程不要求PoC或复现，导致看似合理的虚假公告能直接进入GHSA和企业扫描器。

关键教训与建议

• 54个虚假公告中只有一个包含真实漏洞，但元数据未验证。
• 红队标识：官方维护者安全页面无提及、缺少提交哈希引用、元数据矛盾、引用不存在的代码行数。
• 虚假CVE浪费组织时间，尤其在自动优先级排序环境中可能触发不必要的补丁。AI代理若自动处理，可能根据不存在的代码生成补丁，引入新风险。
• 建议：不盲目信任未经验证的CVE，复现报告中的PoC，检查官方漏洞页面，交叉核对版本范围和代码行号。

JFrog已向GHSA、Red Hat和NVD正式报告这些发现，协助清理记录。

原标题：SQLite Critical CVEs or LLM Slop?。 HN 原始发布时间：2026年8月3日星期一。当前记录为 699 分、350 条评论。

阅读原文 · 查看 HN 讨论