六条不存在的 SQLite 漏洞，如何穿过 CVE 收录链条

7月30日，JFrog Security Research 发布对六条 SQLite 漏洞记录的复核。六个编号分别是 CVE-2026-51302、CVE-2026-51303、CVE-2026-51300、CVE-2026-51297、CVE-2026-51296 和 CVE-2026-51304，公告把它们描述为释放后使用等内存安全问题，初始 CVSS 评分从7.5到9.8不等。记录已经出现在 NVD、GHSA 等下游数据中，CVE-2026-51302 的 Red Hat 评分还曾从10.0调至7.6。这些编号和分数给出了高风险外观，但没有替代对代码和复现结果的核查。

JFrog 的检查从版本源码开始。研究人员检出 SQLite 官方仓库的3.41.0、3.51.2和3.51.3标签，在隔离的 Docker 容器内重新编译，并用 AddressSanitizer 运行各公告提供的 SQL 载荷，同时比对 NVD 与 GHSA 的元数据。结果并非同一种失败：有的查询正常执行，有的在解析阶段报错，有的根本到不了公告所称的代码路径，六条记录都没有触发其描述的崩溃或内存错误。

代码细节进一步暴露了矛盾。CVE-2026-51302 指向的 `exprComputeOperands()` 在所称受影响的 SQLite 3.41.0 中并不存在，公告还把临时寄存器编号的回收解释成堆内存释放。CVE-2026-51303 声称问题在3.51.3修复，但3.51.2与3.51.3之间的 `src/expr.c` 没有相应改动，其 PoC 本身也是无效 SQL。CVE-2026-51296 引用 `json.c` 第3555和3575行，而3.41.0版本的该文件只有2706行。其余记录也出现函数尚未加入目标版本、行号指向无关代码或函数参数数量错误等问题。

SQLite 官方漏洞页现已把这六个编号列为“不是 SQLite 的缺陷”，称它们无法复现并疑似 AI 幻觉，同时链接到 JFrog 的技术分析。这一点比初稿所写的“官方页面没有收录”更明确，也让结论不再只依赖安全厂商的一方判断。SQLite 同一页面还提醒，项目核心开发者并不编写 CVE，第三方记录常在没有开发团队参与的情况下生成，编号不应被当成权威技术结论。

JFrog 又审查了同一 GitHub 账户发布的55条公告，判断其中54条完全虚构，剩余一条包含真实缺陷线索，但 CVE 元数据仍未验证。这一统计仍是 JFrog 的审计结论，不能外推为所有 AI 辅助漏洞报告都不可信。SQLite 7月24日的3.53.4版本说明恰好给出另一面：该维护版本修复的问题多数由 AI 发现，说明模型可以帮助寻找真实错误；关键差别在于报告能否对应实际版本、代码路径、可运行载荷和修复记录。

JFrog 表示已把结果报告给 GHSA、Red Hat 和 NVD，以协助修正记录。现阶段可以确认的是 SQLite 与 JFrog 均否定了这六条记录所称的缺陷，不能据此假定所有下游数据库和企业扫描器都已同步更新。事件暴露的不是“使用 AI 就必然出错”，而是结构完整的公告一旦获得编号和评分，可能在缺少维护者确认与有效复现的情况下继续进入漏洞情报和自动工单流程。

六个错误编号抬高漏洞核验成本

对企业安全运营和开源维护团队，短期影响主要是成本而非新增风险。若扫描器只按 CVE 编号、版本范围和分数开单，团队仍要检查函数是否存在、版本是否匹配、PoC 能否复现以及维护者是否确认；错误记录传播越广，人工复核、工单撤销和跨团队解释所占用的时间越多。反过来，若下游平台及时同步 SQLite 的“不是缺陷”标记，额外成本会随记录修正而下降。

漏洞验证、软件成分分析和安全测试服务可能获得更明确的需求：客户需要的不只是收录速度，还包括来源评级、源码对应、复现状态和撤回同步。JFrog（NASDAQ：FROG）直接完成并公开了本次核验，但一次研究事件并不能证明相关需求会转化为付费收入；中期经营影响仍取决于企业是否把复现能力纳入采购，以及平台能否在不明显拖慢响应的前提下降低误报。

自动化漏洞管理平台面临双向约束。更快摄取新记录有助于覆盖风险，却也会把错误元数据更快送入扫描器和工程工单。平台若增加人工复核，成本和时效可能承压；若不增加验证，误报率和客户信任又可能受损。可观察的证据包括六个编号在 NVD、GHSA 与厂商数据库中的状态变化、扫描器同步速度，以及企业对无效告警的撤单情况。