7 月 30 日，JFrog 安全研究员 Afek Berger 发布分析报告称，一个 GitHub 账号在几天内提交的 55 个 CVE 漏洞报告中，54 个是疑似由 AI 生成的虚假报告。其中 6 个涉及 SQLite，CVSS 严重性评分最高为 9.8；这些记录经过 MITRE、NVD 和 CISA 的处理流程，出现在企业漏洞扫描器里。
Red Hat 曾给其中一个 CVE（CVE-2026-51302）打出 10.0 满分，随后下调至 7.6。JFrog 的复现检查则发现，相关报告所描述的漏洞并不存在。
六条 SQLite 报告的函数、代码行或修复记录对不上
这 6 个 CVE 全部声称 SQLite 存在 use-after-free（UAF）类型的内存漏洞，每一个都附有代码行号、函数名和 PoC（概念验证）载荷。JFrog 安全团队搭建了隔离测试环境——克隆 SQLite 官方仓库、在指定版本编译、通过 AddressSanitizer 运行 PoC——逐条证伪。
**CVE-2026-51302（9.8 分）**声称 exprComputeOperands() 中存在 UAF。但这个函数在 SQLite 3.41.0 中不存在，它是在 2025 年年中才加入代码库的。报告中引用的 sqlite3ReleaseTempReg() 只做寄存器索引回收，不涉及堆内存释放——按设计就不可能产生 UAF。
**CVE-2026-51303（9.8 分）**声称 ExprListDelete() 存在反向引用清理缺陷，并在 3.51.3 版本中修复。JFrog 对 3.51.2 和 3.51.3 做了 diff，发现 src/expr.c 在两次发布之间没有任何修改。声称的"补丁"从未存在。
**CVE-2026-51300（9.1 分）**引用了 expr.c 的第 1012 行和第 1026 行——这两行分别是注释和内存分配调用，与被指控的 UAF 逻辑毫无关系。
**CVE-2026-51296（7.5 分）**将漏洞定位在 json.c 的第 3555 行和 3575 行。SQLite 3.41.0 的 src/json.c 总共只有 2706 行。这两行超出了文件末尾约 800 行。
**CVE-2026-51297（8.8 分）**和 **CVE-2026-51304（7.5 分）**也存在类似问题：前者引用了一个在目标版本中尚未引入的函数，后者声称的单参数函数签名在 SQLite 代码库中根本不存在。按 JFrog 的分析，相关代码在释放指针后立即将其置零，不支持报告所描述的 UAF 路径。
JFrog 用 GPTZero 检测了这些报告，结果全部触发 AI 生成内容警告。将 55 份报告合并成一个文件后，检测器直接将其判定为机器生成。
SQLite 官方团队在漏洞页面上将这一批 6 个 CVE 归入一类，评语只有一行："Not a bug in SQLite. These are unreproducible. They appear to be AI hallucinations."
分配编号和补充评分，没有发现报告无法复现
这些虚假记录通过多道处理流程，说明编号分配、数据库收录和补充评分，未必能替代对漏洞的实际验证。
CVE 的提交入口是 MITRE 的公开表单。任何人只需一个 Google 账号登录，就可以提交漏洞描述并自行提议 CVSS 分数。MITRE 的 CNA of Last Resort（CNA-LR）的角色是分配 CVE ID，而不是验证漏洞是否真实存在。
NIST 运营的 National Vulnerability Database（NVD）此前承担了人工分析工作。NVD 的分析师会手工审核进入数据库的 CVE，补充受影响的软件产品（CPE）、严重性评分（CVSS）和参考链接。但这项工作在 2024 年 2 月受到影响——NIST 在官网公告中承认，由于 CVE 提交量激增和"跨机构支持的变更"，NVD 将暂停对新提交漏洞的深度分析，优先处理"最重要的漏洞"。
此后，人员与资金问题继续影响分析进度。美国商务部监察长办公室的调查发现，NIST 在两年前就被告知需要更换 NVD 的承包商，但直到合同到期时仍未找到替代方案。CISA 在 2025 年也停止了对该项目的资金支持。到 2025 年底，NVD 积压了超过 27,000 条未经分析的 CVE 记录。根据 CSA 于 2026 年 4 月的报告，NIST 已正式放弃全面分析所有 CVE 的目标，转为"基于风险的分诊"模式。
落到这 6 个假 SQLite 漏洞的微观层面，结果是：MITRE 分配了 ID，这些记录在 NVD 中获得较高严重性评分，CISA 的 ADP（Authorized Data Publisher）程序又对这些记录进行了自动富化。最终，它们进入了 GHSA（GitHub 安全公告）和下游的企业漏洞扫描器。
这一批记录的流转，未能及时识别 PoC 无法复现、与厂商代码不符的问题。
自动修复若跳过验证，可能改坏原本正常的代码
虚假漏洞报告会消耗安全团队的排查时间。接入自动修复工具后，还需要防止未经验证的报告触发代码修改。
越来越多企业将 AI coding agent 接入漏洞管理流程：安全扫描器报告一个高危 CVE，AI 代理自动定位受影响的代码、生成补丁、提交 PR。如果输入的 CVE 本身就是 LLM 生成的幻觉——引用了不存在的函数、指向了虚构的代码路径——未经复现检查的 AI 代理可能沿着错误描述寻找问题，甚至修改原本正常的代码。这里描述的是自动修复流程需要防范的风险，并非本次事件已经发生的后果。
JFrog 的 Berger 用一个不对称性概括了这种困境：生成一份看似可信的虚假漏洞报告现在几乎零成本，验证一份报告的成本和过去完全一样——需要读懂源码、编译目标版本、运行 PoC。而能够做这件事的人，比能够用 LLM 生成报告的人少得多。
The Next Web 在报道中引述了 Oracle 工程师 Alan Coopersmith 的说法："CNA 通常不具备自行验证报告的能力。"CVE 系统建立在提交者诚实的假设之上，而这个假设从未考虑过"机器可以低成本大规模撒谎"。
另一个与此平行的事件强化了这个判断。2026 年 1 月，curl 维护者 Daniel Stenberg 宣布终止运行了 6 年的 bug bounty 项目——原因正是 AI 生成的虚假漏洞报告淹没了审阅管道。Stenberg 在公告中写道，AI 提交的"发现"几乎全是噪音，却占据了安全团队大量时间。与此相对，Stanislav Fort 团队使用 AI 在 OpenSSL 中找到了 12 个真实零日漏洞——其中 3 个潜伏了 25 年以上——但这依赖的是系统性的模糊测试和人工验证，不是让 LLM 输出一份漏洞报告然后直接提交。
先核对厂商说明、修复记录、版本和代码位置
JFrog 在报告中给出了识别 AI slop CVE 的四条检查标准，可以用于初步检查报告是否可信：
厂商确认缺失。 如果漏洞声称影响某个开源项目，该项目官方安全页面（如 sqlite.org/cves.html）上是否有对应条目？SQLite 团队维护着 CVE 状态的权威列表，相关条目的状态也应逐一核对。
提交历史不存在。 引用字段中是否包含具体的 commit hash 或 PR 链接？AI 生成的报告通常描述"已修复"但从不指向实际代码变更。
元数据矛盾。 CPE 产品定义是否为空？版本范围是否与报告描述冲突？这 6 个 CVE 中有多个将影响版本固定为 3.41.0，却引用了该版本不存在的函数。
代码引用不可定位。 报告中引用的行号是否落在文件长度之内？函数名是否能在目标版本的源码中找到？这类可直接核对的不一致，是进一步调查的线索。
对于已在使用 AI 代理进行漏洞分诊和自动修复的团队，还需要加上第五条：在将 CVE 描述喂给 AI 代理之前，先由人工确认漏洞是否可复现。这样可以减少错误报告引发不必要代码修改的风险。
JFrog 已向 GHSA、Red Hat 和 NVD 正式报告了这些虚假记录。撤销错误记录可以处理眼前的问题，后续仍需要关注报告验证能力能否跟上提交量。
MITRE 已于 7 月 31 日将这 6 个 CVE 全部标记为 REJECTED，理由是"进一步调查确定这不属于安全问题"。但在此之前，它们已经在 NVD 中存活了四天——足够被全球扫描器同步和告警。
