不存在的SQLite漏洞拿下高危CVE

一个无法复现的漏洞，进入了正式安全情报链

**一个疑似由大模型编造的 SQLite 漏洞，最近不仅获得了正式 CVE 编号，还被标记为高风险。**截至 2026 年 8 月 3 日，JFrog Security Research 对相关漏洞公告完成核查后认为，包括 CVE-2026-51290 在内的 SQLite 漏洞描述存在明显的 AI 幻觉特征：公告引用的代码在声称受影响的版本中并不存在，给出的 PoC 无法触发崩溃，相关问题也没有出现在 SQLite 官方漏洞清单中。

**CVE 是用于唯一标识公开披露安全漏洞的编号体系，而不是漏洞真实性的担保书。**开发者和安全团队习惯把 CVE 编号视为一种已经完成技术背书的认证，但它本质上只是结构化标识；具体描述、影响版本、严重程度和修复建议，仍取决于提交者、CNA 与后续分析机构提供的信息质量。

**这起事件真正危险的地方，不是数据库里多了一条错误记录，而是错误记录已经可以被机器自动消费。**漏洞扫描器、软件成分分析平台、云安全产品和自动修复 Agent 通常不会逐行复现 PoC，而是读取 CVE、CVSS、受影响版本和包名，再据此生成告警、工单甚至补丁。当幻觉获得一个格式正确的 CVE 编号后，它就从一段低质量文本变成了供应链中的机器可读事实。

JFrog 找到了四个直接冲突

**JFrog 的判断并不是单纯依赖 AI 文本检测器，而是先做了代码和 PoC 层面的交叉验证。**研究人员列出的证据可以归纳为四点：

1. **公告引用的代码对不上版本。**部分描述指向的函数、代码路径或漏洞逻辑，在其声称受影响的 SQLite 版本中根本不存在；另一些引用虽然能找到对应名称，实际承担的却是无关逻辑。
2. **公告提供的 PoC 无法触发漏洞。**研究人员按照描述测试恶意数据库文件或输入载荷，没有观察到预期的崩溃、越界访问或内存破坏。
3. **SQLite 官方没有确认相关问题。**SQLite 维护着自己的 CVE 说明页面，并会明确指出哪些编号是真漏洞、哪些只是第三方应用错误，以及哪些描述夸大了影响。争议公告没有出现在官方确认范围内。
4. **同一仓库中的公告呈现批量生成痕迹。**JFrog 将这些安全公告合并后交给 GPTZero 检测，结果触发了 AI 生成内容警告。这项检测本身不能证明造假，但与代码不存在、PoC 失效等技术证据叠加后，指向性已经很强。

**PoC 是用于证明漏洞能够被触发的最小化验证程序或输入，而不是公告里可有可无的装饰。**一个内存破坏漏洞如果声称攻击者只需诱导应用打开特制 SQLite 文件，就应该能够给出明确的崩溃位置、调用栈、受影响提交以及 AddressSanitizer 等工具捕获的异常。只有一段听起来合理的攻击叙事，却没有可复现结果，不能支撑高危结论。

**GPTZero 的检测结果只能作为辅助信号，不能单独承担漏洞判定。**AI 文本检测器存在误报，技术文档本身又经常使用高度模板化的句式；如果仅凭检测器分数就认定公告由 AI 生成，实际上是在用另一个概率模型审判第一个概率模型。JFrog 这次较有价值的部分，是把文本特征放在了源码、版本历史和 PoC 复现之后。

它和真实的 SQLite 漏洞差在哪里

**真实漏洞与幻觉漏洞的差异，不在于描述是否足够吓人，而在于证据链是否闭合。**以 2022 年公开的 CVE-2022-35737 为例，该漏洞涉及 SQLite C API 在处理超大字符串参数时的数组边界问题，影响 1.0.12 至 3.39.2 之前的版本，CVSS 3.1 得分为 7.5，并在 SQLite 3.39.2 中完成修复。研究机构可以复现，受影响版本可以定位，补丁提交也能核对。

**2025 年由 Google 安全 Agent Big Sleep 发现的 CVE-2025-6965，则代表 AI 参与漏洞发现的另一面。**Big Sleep 是 Google 用于自动分析代码和寻找安全缺陷的 AI Agent，它发现的 SQLite 问题经过人工验证、厂商协作和正式披露，并因潜在现实攻击价值受到关注。AI 可以提高漏洞发现效率，但前提仍是让模型提出假设、让工具和人完成验证，而不是把模型输出直接升级为漏洞事实。

| 对比项 | CVE-2026-51290 等争议公告 | CVE-2022-35737 | CVE-2025-6965 | |---|---|---|---| | 当前性质 | JFrog 判定为无法验证、疑似 AI 幻觉 | 已确认的 SQLite 边界问题 | Big Sleep 发现并经验证的真实漏洞 | | 核心说法 | 特制数据库文件可能触发内存破坏或拒绝服务 | 超大字符串导致数组越界，可造成拒绝服务 | AI Agent 发现的 SQLite 安全缺陷 | | 代码定位 | 引用代码不存在或与漏洞逻辑无关 | 可定位受影响函数和版本 | 有厂商与研究团队验证流程 | | PoC 状态 | JFrog 测试未触发崩溃 | 已有技术细节与复现结果 | 经人工复核后披露 | | 官方确认 | 未进入 SQLite 官方确认清单 | 官方版本已修复 | 进入正式协调披露流程 | | 已知分值 | 被登记为高风险，但评分缺乏可靠技术支撑 | CVSS 3.1 为 7.5 | 应以正式记录的最新数据为准 | | 应对方式 | 暂停自动处置，等待撤回、修订或厂商确认 | 升级至 3.39.2 或更高版本 | 按官方公告升级对应版本 |

**SQLite 官方长期对 CVE 记录持谨慎甚至带有批判性的态度。**其漏洞说明页面列出了多条被错误归因给 SQLite 的记录：CVE-2021-28305 和 CVE-2022-24854 实际属于使用 SQLite 的第三方应用，CVE-2022-21227 位于第三方 Node.js 绑定，CVE-2021-20227 则被官方认为夸大了远程代码执行风险。这说明 CVE 误标并不是 AI 时代才出现的问题，但生成式 AI 把错误生产的成本压得更低、速度提得更高。

CVE 为什么会收下一条不存在的漏洞

**CNA 是被授权分配 CVE 编号并发布漏洞记录的组织，但不同 CNA 的验证深度并不完全一致。**CVE 生态追求的是让大量厂商、研究人员和协调机构及时登记漏洞，因此不可能要求每条记录都经过中心化实验室复现；在正常情况下，这种分布式机制能提高披露效率，在低质量自动生成内容面前，它也会暴露审核尺度不统一的问题。

**一条公告只要格式完整，就很容易表现得像真的。**大模型可以一次性生成漏洞名称、CWE 分类、影响版本、攻击向量、CVSS 向量、PoC 描述和修复建议，而且这些字段在语法上彼此一致。例如，把特制数据库文件、越界访问、远程攻击和拒绝服务串成一段描述，对模型并不困难；真正困难的是证明某个具体版本的具体代码确实存在可达的内存错误。

**CVSS 是量化漏洞潜在技术影响的评分体系，不负责判断漏洞是否真实存在。**如果输入条件被错误填写，一个虚构漏洞同样可以算出 8 分、9 分甚至更高分值。企业系统随后按照数字排序，就会出现一个荒诞结果：证据最薄弱的漏洞，反而因为描述最激进而最先进入紧急响应队列。

幻觉已经从聊天框进入软件供应链

**AI 幻觉是模型生成语法连贯但缺乏事实依据内容的现象。**在普通问答中，幻觉可能只是一个错误年份或不存在的论文；在安全情报中，幻觉会变成包名、版本范围、严重等级和机器可执行的处置建议，其外部成本明显更高。

**安全自动化越彻底，错误 CVE 的放大倍数就越高。**一个典型企业流程可能是：SCA 扫描器发现项目包含 SQLite，漏洞数据库返回高危 CVE，SOAR 平台自动创建 P1 工单，安全 Agent 搜索所谓问题函数并尝试生成补丁，CI 系统重新构建和回归测试，最终由工程师处理发布。即使漏洞最后被证伪，中间仍可能消耗多个团队数小时甚至数天。

**自动修复 Agent 还可能为了修复不存在的问题而制造真实缺陷。**如果 Agent 找不到公告声称的函数，它可能搜索名称相近的代码并修改无关边界检查，也可能建议回退、替换数据库组件或关闭某项功能。原本不存在的内存破坏，可能因此变成性能回退、数据兼容性问题或新的安全漏洞。

**漏洞数据污染还会影响模型的下一轮训练和检索。**当 CVE 描述被多个漏洞网站、搜索引擎、博客和扫描器镜像后，后续大模型会把多站点重复出现误判为多来源证实。实际上，这些页面可能都来自同一条错误记录；信息数量增加了，独立证据却仍然是零。

安全团队现在不该只看编号和分数

**企业需要给高危 CVE 增加一层证据门槛，而不是取消自动化。**最实际的做法，是把是否存在厂商确认、可定位提交、可复现 PoC 和独立研究报告加入风险排序，让 CVSS 负责衡量影响，让证据等级负责衡量可信度。

可以采用下面这套分层策略：

• **一级证据：厂商确认。**检查 SQLite 官方公告、版本发布记录和修复提交，而不是只看聚合漏洞库。
• **二级证据：源码对应。**核对公告中的函数、文件和代码路径是否存在于声称受影响的版本。
• **三级证据：可控复现。**在隔离环境中运行 PoC，并保存崩溃日志、调用栈和内存检测结果。
• **四级证据：独立交叉验证。**确认是否有多个互不依赖的研究团队得到相同结果，避免把同一条记录的转载误认为多方确认。
• **五级处置：延迟破坏性修复。**对只有编号和评分、没有技术证据的记录，可以继续告警和观察，但不应让 Agent 自动修改生产代码。

**开发者暂时没有理由因为这条争议记录盲目替换 SQLite。**如果扫描器报出 CVE-2026-51290，正确动作是记录命中位置、核对组件版本、查询厂商确认状态，并要求情报供应商给出来源和复现证据；直接升级到一个不相关版本，或者接受 AI 自动生成的补丁，都可能增加而不是降低风险。

**漏洞平台则需要披露内容的生成与验证方式。**如果公告主体由大模型生成，应标注模型参与程度、人工审核者、复现环境、源码提交和原始崩溃信息；如果 PoC 未公开，也至少应向 CNA 提供可验证材料。AI 可以整理报告，但不能成为证据本身。

这不是 AI 找漏洞翻车，而是审核流程失守

**AI 生成漏洞假设并没有错，把未经验证的假设登记成高危事实才是问题。**模糊测试、静态分析和安全 Agent 本来就会产生大量候选结果，成熟流程的价值正是过滤误报。大模型让候选结果写得更完整、更像正式报告，也因此更容易绕过只检查格式、不检查技术内容的审核。

**这起 SQLite 事件给行业留下的警告是：安全情报需要来源证明，而不仅是内容摘要。**未来的漏洞记录至少应能追溯到受影响提交、复现环境、验证主体和厂商反馈；安全 Agent 也应该被设计成先验证记录，再建议修复，而不是看到高分 CVE 就开始改代码。

**一个不存在的漏洞不会直接攻破系统，但围绕它运行的自动化流程可能造成真实损失。**当 AI 同时参与漏洞撰写、情报聚合、风险排序和补丁生成时，任何一个未经验证的幻觉都有机会形成闭环。CVE-2026-51290 的价值或许不在于它发现了 SQLite 的问题，而在于它暴露了漏洞情报基础设施自己的漏洞。

参考来源

• CVEProject/cvelistV5：CVE List 的公开 JSON 5 数据仓库，可用于核对记录内容及后续修订状态。
• SQLite GitHub 镜像仓库：用于核对 SQLite 源码、文件路径和版本变更；正式发布信息仍应以 SQLite 项目维护方为准。
• iThome：Google 证实 AI Agent 可帮助发现安全漏洞：介绍 Big Sleep 发现 SQLite 漏洞 CVE-2025-6965 的背景，可与本次疑似 AI 幻觉公告形成对照。