漏洞传闻即武器：AI 让漏洞利用快于补丁
Just the rumour of a bug is enough to find an exploit these days
今天我为 OCaml 的 cohttp 发布了安全修复，却惊恐地发现，仅仅在 GitHub 上公开修复的 PR 后几分钟，我的服务器就遭到了针对该漏洞的自动化探测。更令人不安的是，我利用自己的 AI 代理，仅凭对漏洞的大致描述，就能在不到一分钟内生成利用代码。这意味着传统的漏洞保密期（embargo）已彻底失效，攻击者无需完整细节，只需一个“传闻”就能让 AI 代理自行挖掘出 exploit。数据显示，漏洞利用的平均时间已变为负数，即利用先于补丁发布。面对 LLM 驱动的自动化攻击，开源维护者必须重新思考安全响应机制，从依赖保密转向快速持续交付和协议层的主动防御。
仅仅一个漏洞的传闻，就足以让攻击者获取足够的信息来找到新的利用方式。
HN 评论区
102- nickcw
这简直就是在描述我作为开源维护者当下的生活！
在 rclone 项目的前 10 年里，我们通过 GitHub 收到了大约 20 个安全漏洞披露。而在过去的一个月里，我们要处理的数量超过了 40 个！即便我利用 AI 工具来初步筛选并生成修复方案供审查，这也耗费了我大量时间。
这些安全披露的命中率相当高——大约 75% 的披露都包含了一些需要仔细检查的实质内容。rclone 的配置变得越来越离奇，所以我希望这种情况最终会平息。
我曾考虑直接将修复合并到 master 分支，以简化我的生活，而不是在分支上维护十几个独立的安全修复，等到发布点版本时再合并，并祈祷不要出现太多需要解决的冲突。但我决定暂时还是坚持现有的流程。
GitHub 会为这些公告分配 CVE 编号。在 AI 末日之前，分配通常需要 2-3 天，但现在却需要 3-4 周，所以我不得不在更新日志中以 CVE-PENDING 的状态发布点版本，这显然不是理想的做法。
我不确定解决方案是什么，但这对我们来说绝对是个问题。
- godelski
现在找漏洞、修漏洞更容易了，但修复的意愿却比以往任何时候都低。我的老板们只想要速度，他们会花 30 分钟给我上一课，告诉我为什么我不需要去修复一个 Claude 在 5 分钟内就解决了、我已经验证过、且已经提交到公开 PR 的漏洞。与此同时，我们推出漏洞的速度却越来越快。
无论 AI 在修复漏洞方面变得多么出色，如果没有修复的意愿，我们就永远无法修复它们。如果没有打造优质软件的意愿，软件就永远不会好。问题始终在于意愿。太多的产品都在追求更好。这简直疯了：在一个我们本可以在速度和质量上都做得更好的时代，我们却仍然选择速度，并告诉自己这叫“交付速度”。
- bri3d
我不认为这是大语言模型（LLM）带来的新现象（根据寥寥数语就找到漏洞一直是漏洞开发中有趣的一部分），但它被规模化并普及化了，导致低价值目标遭到大规模利用。从补丁、提交信息以及偶然听到或读到的只言片语中反向推导漏洞概念验证（PoC），这种做法在漏洞研究领域由来已久。与大语言模型的区别在于，具备“足够技能”（无论是否是人类）的参与者数量激增，使得那些原本无法做到的人也能进行粗糙的、低技能的“攻击整个互联网”的操作。
不过，我同意作者的观点；其中大多数事情本应更早实施，从某种意义上说，现在有一个强制推动因素也是好事。
- stephbook
我认为发布和部署才是更大的问题。谁能在 10 分钟内更新他们的软件栈？大多数 CI 运行验证业务逻辑是否仍然正常所需的时间都更长。
再加上供应链攻击的风险，你甚至根本不想开启自动更新。
- rndhouse
我开发了一个工具，用于监控提交并尝试检测静默的漏洞修复。借助 GPT-5.5 级别的模型，它可以相当可靠地识别出隐藏在看似常规提交中的修复。要想通过混淆代码变更来规避检测是非常困难的。
我听说至少有一个项目（c-lightning？）曾暂时发布闭源二进制文件作为权宜之计，直到用户可以安全更新为止。
- ChrisMarshallNY
遗憾的是，看来从中吸取的教训是：把你的仓库设为私有。
我并不喜欢这种做法，但我认为很多人会得出这个结论。
- jameshart
我确实很好奇，当用一条传闻提示 Claude，让它假设漏洞存在时，它找到成功漏洞的命中率到底是多少。
“我听说这个包里有个路径遍历漏洞。你能找到吗？”——即使这个传闻是你编造的，它找到漏洞的概率可能也相当高。
- janpeuker
我确实理解对新漏洞的焦虑，但老实说，我更担心的是，几年后，修复中高危安全漏洞的成本会变得如此低廉，以至于普通公民进行低调的黑客攻击或发现令人担忧的隐私违规行为将变得 prohibitively expensive（昂贵到无法承受）。