虚假 CVE、AI 生成的报告与核实的必要性

制作看似可信的漏洞报告正变得越来越便宜，这也加大了软件维护人员和安全团队面临的影响。2026 年 7 月，针对 SQLite 发布了 6 项通用漏洞与暴露（CVE），其中两项的严重性评分达到 9.8。这些报告看起来合情合理，描述了内存安全漏洞，还附有技术说明和概念验证代码。

但 JFrog 的研究人员发现，这些报告提及的部分函数并不存在于受影响的版本中。更重要的是，没有任何概念验证（PoC）复现出报告声称的漏洞。SQLite 自己的 CVE 页面目前称，这 6 项报告所述问题并非漏洞；相关 CVE 记录随后也被驳回。

问题不只出现在 SQLite 上。curl 的维护者 Daniel Stenberg 去年估计，收到的安全报告中约有 20% 是 AI 垃圾内容。GitHub的 CVE 编号机构（CNA）在 2026 年 5 月收到近 4,000 项 CVE 申请；按年计算，数量约增长了 10 倍。GitHub 没有将这一增长归因于 AI，也没有指出提交质量有所下降，但数量的急剧增加凸显了漏洞披露流程不堪重负。

AI 让人们更容易提出详尽的漏洞指控，但核实这些说法是否属实仍然耗时。一旦某项 CVE 进入安全信息源和公共数据库，纠正原始记录并不意味着所有副本都会自动得到更正。因此，人们越来越需要区分报告所称的漏洞与经过技术核实的漏洞。

什么是“虚假”CVE？

人们经常用“虚假 CVE”来指称很可能被错误报告的 CVE。但“虚假”并不意味着有意误导。问题可能源于静态分析遗漏了某项验证检查，或误将输入理解为攻击者可以控制。报告可能描述了一个真实存在的函数，却声称存在一条无效的攻击路径。如果报告所述情况实际上并非漏洞，相关标识符（CVE ID）仍可能先被分配，随后再被撤销。这与蓄意捏造报告不同。

争议也不等于虚假 CVE。供应商可能会对研究人员关于可利用性、威胁边界或某个函数是否原本就用于处理不可信输入的判断提出异议。但存在争议并不能证明研究人员有误。驳回一项 CVE 也未必意味着它是捏造的；它可能因重复或行政原因而被驳回。尽管 CVE 标识符本身并不构成独立的技术核实，业界仍需要认真对待真实的报告。

虚假 CVE 为何会造成问题

我们看到的问题之一是，有人利用 AI 生成漏洞报告，却没有妥善核实调查结果。这些报告可能包含详尽的技术说明、代码引用，甚至 PoC，因此看起来十分可信。但正如 SQLite 的 CVE 案例所示，其中一些被引用的函数在受影响版本中根本不存在。

GitHub 报告称，2026 年漏洞提交数量显著增加，不过并未将这一增长归因于 AI，也没有报告提交质量下降。令人担忧的是，报告数量越多，调查这些报告所需的工作量也越大，无论报告中的发现是否属实。

曾经负责分流漏洞报告的人，很容易理解实际操作中的难处。AI 模型可以识别可疑的 API 调用，大致构想出利用情境，并迅速生成一份看起来很专业的报告。要判断这一情境是否可行，可能需要核对确切的发布版本、追踪控制流、了解数据如何传入该函数、搭建测试环境并运行所声称的攻击。无论报告是否准确，都要走完同样的流程，而这一过程可能成本高昂。

虚假 CVE 还可能损害声誉。漏洞公告可以迅速传播到扫描器信息源、安全数据库和搜索结果中。然而，随后发布的更正未必能传播得同样广泛。即使报告已遭质疑或被驳回，供应商仍可能不得不向看到原始报告的客户解释和辩护。

团队把时间花在调查错误报告上，也可能导致真正的漏洞被忽视或延误。当维护人员和安全团队资源有限时，每花一小时排除一个误报，就少了一小时可以用来调查实际安全问题。

借助自动化反击

许多调查人员仍在依靠人工分流来应对新近涌入的大量报告，但这种做法难以为继。自动化有助于根据实际受影响的发布版本和配置核实漏洞指控。以下是需要提出的五个问题：

• 包括配置和权限在内，攻击前提是否可信？
• 据称存在的函数是否确实存在于受影响版本中？
• 攻击者能否触及存在漏洞的代码？确定相关代码能否在受影响条件下执行，以及攻击者能否提供可触及该代码的输入。
• 测试人员能否在受控测试中或借助 PoC 重现这种行为？
• 观察到的行为是否体现了安全公告中所述的安全影响？

智能体工具可以创建测试环境、分析代码路径、生成 PoC，并记录执行证据以供审查。但它们无法自动核实每一项说法。即使漏洞确实存在，如果环境不完整或触发条件有误，PoC 也可能失败。测试人员可以重现崩溃，却无法证明所声称的可利用性。这些限制正是人工判断仍然至关重要的原因。不过，在一份报告耗费工程、漏洞管理和客户支持团队更多时间之前，这些工具可以帮助团队更接近可复现的结论。

应对 CVE 生态系统中的信息过载

没有哪一项简明政策能神奇地解决虚假 CVE 的问题。不过，要求提交时提供更有力的证据，并明确说明复现状态，会有所帮助。更清晰地处理有争议的记录，并更快地更正下游数据，也会有所帮助。应鼓励研究人员在提交前验证借助 AI 得出的发现。

安全团队和供应商必须着重审查证据。严重级别的 CVE 评分并不能说明存在漏洞的路径在其环境中是否可被触及。PoC 失败，并不意味着一切安然无恙。收到 CVE ID，也不能成为团队不开展必要技术工作的理由；团队仍需通过这些工作了解问题。

AI 正在提升发现漏洞的能力，同时也使人们能够炮制看似可信、实则错误的说法。在报告不断增多的环境下，组织需要投入资源进行验证。这包括构建测试、复现结果、核查假设，以及让证据更易于评估。智能体安全测试可能在这一领域发挥重要作用。