SQLite 关键 CVE 竟是 LLM 幻觉产物
Critical CVE issued for hallucinated SQLite vulnerability
最近 GitHub 上出现一批针对 SQLite 的所谓关键漏洞报告，NVD 和 CISA 甚至将其标记为 Critical。但 JFrog 安全团队深入调查后发现，这些 CVE 大多是 LLM 生成的垃圾内容。报告中引用的函数在指定版本中根本不存在，行号也完全对不上，PoC 测试更是无法复现任何崩溃。更讽刺的是，部分漏洞评分从 10.0 被降级，因为所谓的修复补丁纯属虚构。这一事件暴露了当前 CVE 提交机制缺乏验证的漏洞，AI 生成的虚假报告正在污染漏洞数据库，让安全团队浪费大量精力去修补根本不存在的漏洞。
由于当前系统没有任何步骤要求提供概念验证或漏洞复现，一个听起来 plausible 的虚假公告就能顺利通过流程，最终进入 GHSA、下游数据库和企业扫描器中。
HN 评论区
370- gortok
我们可以把这归咎于又一个例子：人们认为 LLM 能做到的事情，与它们实际能做到的事情之间，存在着过度的狂热。
基于 LLM 的“人工智能”能够利用其庞大的输入语料库，计算在特定情境下统计概率最高的输出。它是概率性的，而当你处理的是概率问题，但实际情况却需要确定性时，如果你的基于 LLM 的“人工智能”在最乐观的情况下只是算错了概率，或者像这次一样，声称某行代码生成了漏洞，而实际上那只是一行代码注释，那么你的可信度就会遭到毁灭性打击。
LLM 是文本预测引擎。它们不是人工智能，也不应以任何形式或方式被当作拥有智能的实体来对待。让我对整个事件感到恼火的是，那些依赖基于 LLM 的“人工智能”来生成这些漏洞的人，按理说应该对他们的工具足够了解，知道这种情况会发生，但他们却没有。
现在，我们要为这一切付出代价，代价是数十万甚至数百万美元的生产力浪费，因为各个团队不得不处理这种“人工智能”使用方式带来的后续影响。
人类必须核实 LLM 呈现的每一个事实。每一个。如果你不这么做，我们所有人都会为此买单。LLM 并没有减轻人类的责任，如果有的话，它们反而加剧了这种责任，因为 LLM 能比人类更快地生成大量需要核实的输出。
- ChrisMarshallNY
这类问题的关键在于，它降低了信噪比（S/N），使得筛选出真正的 CVE 变得困难得多。
但另一方面，我也知道 LLM 确实发现了许多真正的 CVE，我敢打赌，黑客们正在最大限度地利用它们。
- Ekaros
不验证提交内容似乎是一个巨大的攻击途径。用无尽的虚假报告淹没整个系统，从而使其可靠性大大降低。
- linuxhansl
我几乎觉得我们迎来了新一代的“脚本小子”。这些缺乏（或完全没有）软件工程知识的人，利用外部工具去做他们自己无法完成的“事情”。
也许这不是一个完美的类比——在这个案例中，他们的意图似乎是值得称道的——但我们会看到更多此类情况，包括来自恶意行为者的情况。
- inigyou
对于那些被强制要求修补所有 CVE 的组织来说，这将会很有趣，不是吗？
- rib3ye
> 因为今天的系统中没有任何步骤实际上需要概念验证（PoC）或漏洞复现，一个听起来 plausible 的虚假公告就能顺利通过流程，最终进入 GHSA、下游数据库和企业扫描器。
我在安全领域没有任何经验，但为什么提交流程不像任何正常的软件公司（无论大小）那样，要求提供漏洞复现步骤呢？
- oxydite
天哪，不知道为什么我一直以为，如果某个东西获得了 CVE 编号，那就意味着某个权威机构已经复现并验证了它。
这难道不是 CNA（CVE 编号机构）的工作吗？如果未经过验证，为什么任何东西都能获得编号？
- Spide_r
- gste
> 引用的代码甚至不存在于那些版本中，或者引用了不相关的逻辑。
> 在测试 PoC 负载时，它们无法工作（没有触发任何崩溃）。
我认为未来已经很明显了，如果项目还没有这样做的话：你需要自动化这些检查并自动拒绝。
- BigTTYGothGF
他们甚至懒得用一张非 AI 生成的图片。