7 月 30 日，JFrog 安全研究员 Afek Berger 发布了一份分析报告，结论直白：一个 GitHub 账号在几天内提交的 55 个 CVE 漏洞报告中，54 个是 AI 生成的虚构产物。其中 6 个针对 SQLite 的"严重漏洞"获得了最高 9.8 分的 CVSS 评级，一度穿过 MITRE、NVD 和 CISA 三道防线，出现在全球企业的漏洞扫描器里。
Red Hat 曾给其中一个 CVE（CVE-2026-51302）打出 10.0 满分，随后下调至 7.6。但分数高低此时不是重点——重点是这些漏洞根本不存在。
同一个剧本：六个漏洞，六次穿帮
这 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 代码库中根本不存在——SQLite 在释放指针后立即将其置零，让 UAF 不可能发生。
JFrog 用 GPTZero 检测了这些报告，结果全部触发 AI 生成内容警告。将 55 份报告合并成一个文件后，检测器直接将其判定为机器生成。
SQLite 官方团队在漏洞页面上将这一批 6 个 CVE 归入一类，评语只有一行："Not a bug in SQLite. These are unreproducible. They appear to be AI hallucinations."
一道接一道失守的防线
这些虚构漏洞一路绿灯的经历，暴露的不是某个提交者的恶意，而是整个 CVE 管道在设计上就缺少验证环节。
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 在没有人工核查的情况下将它们标记为 CRITICAL，CISA 的 ADP（Authorized Data Publisher）程序又对这些记录进行了自动富化。最终，它们进入了 GHSA（GitHub 安全公告）和下游的企业漏洞扫描器。
这一步之后，没有任何环节要求提供可复现的 PoC 或厂商确认。
当 AI 修复不存在的漏洞
这个事件最让人不安的后果，不在安全团队浪费时间排查——这是显而易见的代价——而在于它暴露了一个仍在形成的恶性循环。
越来越多企业将 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 状态的权威列表，6 个假漏洞全部缺席。
提交历史不存在。 引用字段中是否包含具体的 commit hash 或 PR 链接？AI 生成的报告通常描述"已修复"但从不指向实际代码变更。
元数据矛盾。 CPE 产品定义是否为空？版本范围是否与报告描述冲突？这 6 个 CVE 中有多个将影响版本固定为 3.41.0，却引用了该版本不存在的函数。
代码引用不可定位。 报告中引用的行号是否落在文件长度之内？函数名是否能在目标版本的源码中找到？这是最直接的红旗，也无需安全专业知识即可判断。
对于已在使用 AI 代理进行漏洞分诊和自动修复的团队，还需要加上第五条：在将 CVE 描述喂给 AI 代理之前，先由人工确认漏洞是否可复现。否则，AI 修复 AI 生成的漏洞的循环一旦启动，浪费的就不只是时间，而是代码的完整性。
JFrog 已向 GHSA、Red Hat 和 NVD 正式报告了这些虚假记录。但修复数据只是一次性的补救。只要 CVE 管道对零成本 AI 生成保持开放，而验证门槛保持不变，这种事件不是"是否还会发生"的问题，而是频率和多快的迭代问题。
MITRE 已于 7 月 31 日将这 6 个 CVE 全部标记为 REJECTED，理由是"进一步调查确定这不属于安全问题"。但在此之前，它们已经在 NVD 中存活了四天——足够被全球扫描器同步和告警。