幻觉 SQLite CVEs：漏洞报告中 LLM Slop 的兴起

LLM 生成的虚假 CVEs 针对 SQLite

最近针对 SQLite 的安全公告被识别为“LLM slop”——由人工智能生成的虚假漏洞，但它们仍被国家漏洞数据库 (NVD) 和 CISA 的授权数据发布者 (ADP) 标记为关键级别。JFrog 安全研究人员发现，一个 GitHub 仓库 (programmervuln/cveadvisory-) 发布了一批超过 50 个 CVEs，其中绝大多数完全是虚假的，包括几个针对 SQLite 的高严重性报告。

造假证据

JFrog 通过严格的测试工作流验证了这些 CVEs 的虚假性，该工作流涉及对官方 SQLite 标签的源码检查、在 Docker 中的干净环境构建，以及在 AddressSanitizer (ASan) 下执行 PoC。调查揭示了四种主要的幻觉模式：

1. 不存在的代码引用

几个公告引用了在目标 SQLite 版本中并不存在的函数或行号。例如，CVE-2026-51302 声称在 exprComputeOperands() 中存在漏洞，但该函数直到 2025 年中期才被添加到 SQLite 中，远晚于报告中所述的 3.41.0 版本。同样，CVE-2026-51296 引用的 src/json.c 中的行号超过了文件的实际长度。

2. 伪造的补丁

CVE-2026-51303 声称在 3.51.3 版本中实施了修复。然而，3.51.2 与 3.51.3 版本之间的 diff 显示相关文件 (src/expr.c) 没有任何变化，证明该“补丁”完全是捏造的。

3. 无效的 PoC 有效载荷

公告中提供的概念验证 (PoC) SQL 语句无法触发崩溃或内存错误。在某些情况下，PoCs 是无效的 SQL，在解析阶段就失败了，从未达到它们声称要针对的执行逻辑。

4. 逻辑上的不可能

在 CVE-2026-51304 中，公告声称在列表释放后发生了使用后释放 (UAF) 错误。源码分析显示，SQLite 显式地在删除后立即将指针置为空 (pPrior->pOrderBy = 0)，使得后续的解引用在设计上是不可能的。

CVE 管道的系统性失效

此事件突显了全球漏洞报告基础设施中的一个关键漏洞。由于两个主要因素，当前系统允许听起来合理的虚假公告到达企业级扫描器：

• 缺乏身份验证： MITRE 公开提交表单不需要身份验证，允许任何人提出 CVE 和 CVSS 评分。
• “NVD 安全网”的崩溃： 从历史上看，NIST 专家会手动验证并丰富 CVEs。然而，自 2024 年 2 月以来，报告数量的大幅激增导致 NIST 暂停了深度分析，使得管道变得支离破碎，且缺乏强制性的概念验证或复现步骤。

对安全运营的影响

虚假的 CVEs 为安全团队和维护者带来了显著的运营负担：

• 浪费资源： 组织浪费时间调查和修复不存在的漏洞，尤其是在自动化系统根据 CVSS 评分触发高优先级工单时。
• 维护者倦怠： 项目维护者必须花费时间拆穿幻觉，而不是修复真正的漏洞。
• AI Triage 风险： 用于自动化修复的 AI agent 可能尝试“补丁”不存在的函数，从而可能将真正的漏洞引入代码库。

社区洞察与反驳观点

Hacker News 上的行业观察者指出，这股趋势降低了信噪比，使得识别真正的威胁变得更加困难。一些贡献者对这可能成为更具恶意攻击的前兆表示担忧：

"Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable."

其他人则指出了使用 AI 生成的内容来报告 AI 生成的 slop 的讽刺性，并指出这些工具的泛滥使得产生了一种“随机性”，即人类的专业知识正在被同质化、概率性的缺陷所取代。

如何识别“Slop” CVEs

为了避免在虚假漏洞上浪费资源，安全团队应寻找以下红旗信号：

• 没有供应商协同验证： 该问题在官方维护者安全页面（例如， sqlite.org/cves.html）中不存在。
• 缺失 Commit History： 在引用字段中没有链接的 commit hash 或 pull request。
• 元数据矛盾： CPE 产品定义为空，或者版本范围与公告叙述不符。
• 不可能的引用： 公告引用了在指定版本中不存在的函数或行号。