JFrog 曝光：54 个虚假 CVE 建议通过审批流程

安全团队习惯把新出现的严重 CVE 当作火警来处理。JFrog 最近的一项调查揭示了这样一种情况：如果警报本身可能源于虚构，会发生什么？

JFrog 检查了一个新创建的 GitHub 仓库。该仓库发布了 50 多条漏洞公告，其中许多针对 SQLite。研究人员表示，在他们审查的 55 条公告中，有 54 条看起来是由 LLM 生成的虚假内容。

最有力的证据并非来自 AI 检测器，而是代码本身。

有些公告引用了受影响 SQLite 版本中根本不存在的函数。另一些公告指向无关代码行，声称存在从未提交过的修复，或者提供的概念验证（PoC）输入在执行到所谓的漏洞代码之前就已经失败。

然而，其中几份报告仍然获得了 CVE 标识符和高严重性元数据。有一项最初甚至被评为严重级别，之后才遭到降级。

因此，这不只是另一个关于模型产生幻觉的故事。

LLM 可以在几秒钟内编造出一份看似可信的漏洞报告。对于那些通过下游检查的报告，格式规范的结构被当成了证据：

• 仓库接受报告
• 分配标识符
• 严重性元数据向下游传播
• 扫描器向客户发出警报
• 安全团队耗费时间调查无法复现的报告

这种幻觉之所以造成影响，是因为下游系统只凭其形式就予以接受，却没有核实其内容。

对于开发者和安全团队来说，务实的应对方式并不是忽略 CVE，而是针对那些缺乏可信披露链路的报告，保留一道验证环节。检查受影响的版本，审阅所引用的代码，在隔离环境中复现 PoC，并将相关说法与厂商自己的历史安全公告进行比对。

令人不安的教训是：结构化数据依然可能只是合成噪声。一个长得像 CVE 的对象，并不会自动成为真实漏洞。

来源：JFrog Security Research，《SQLite Critical CVEs or LLM Slop?》

披露声明：AI 工具协助完成了初稿撰写和来源整理。文章发布前，所有事实性说法均已对照所引用的调查进行核验。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。