漏洞还没公开，AI 已经会顺着传闻找到利用方法

作者：韩启明｜OC 政策与安全编辑

据 OCaml 开发者 Anil Madhavapeddy 的技术记录，cohttp 修复一处路径规范化问题时，维护者在公开修复 PR 后几分钟，就在服务器日志里看到了符合漏洞模式的探测请求。作者随后只向自己的 Agent 提供大致方向，模型便独立发现相关问题，并在一分钟内生成针对本地服务器的探测代码。

一句话结论：AI 没有让漏洞凭空出现，却正在让“知道大概哪里有问题”迅速变成可运行的利用代码，公开修复和攻击之间的安全窗口接近消失。

传统协调披露依赖一个时间差：研究者先私下通知维护者，维护者准备补丁和公告，用户获得升级时间，最后再公开技术细节。它隐含的假设是，没有详细漏洞描述和概念验证代码，大多数攻击者很难快速重建漏洞。

代码 Agent 正在削弱这个假设。模型可以阅读提交历史、比较补丁前后的条件判断、寻找相似代码路径，再生成请求进行验证。即使补丁暂时保密，只要漏洞类别、受影响组件或大致位置已经泄漏，Agent 也可能自行完成剩下的调查。

原文引用的一项早期研究显示，获得 CVE 描述时，GPT-4 Agent 在 15 个漏洞基准中成功利用了 87%；没有描述时只有 7%。这不是对整个互联网的普遍测量，样本也很小，但它说明“方向提示”的价值可能远高于过去。

作者还引用行业数据称，漏洞平均遭利用时间已经出现“负七天”现象，即攻击活动可能早于公开补丁；并列举 2026 年一些项目从公告到首次探测只用了数小时。不同数据集对“首次利用”的定义可能不同，不能机械地把负数当作每个漏洞的命运，但防守方确实不能继续把公告后的几周当作正常升级期。

这也解释了为什么“永远秘密修补”不是解决方案。公开仓库的提交、软件行为变化、二进制差异和发布包都可能暴露线索，而长期维护私有分支会让开源项目承担更高测试成本。更现实的方向包括缩短发布周期、自动化回归测试、让包管理器更快传播安全更新，并在协议、反向代理和运行时层面准备临时缓解措施。

先别急着把问题归咎于某一个模型。真正变化的是攻击研究的边际成本：过去需要经验丰富的研究者花数天读代码，现在一个中等线索可以被许多 Agent 同时追踪。防守流程必须按“漏洞可能已经被理解”来设计，而不是按“没人知道细节”来争取时间。

关键事实

• 涉及项目：OCaml HTTP 库 cohttp
• 观察：修复 PR 公开后数分钟出现相关探测
• Agent 实验：只给出路径规范化方向即可发现问题并生成本地探测
• 主要变化：从漏洞线索到可利用代码的时间显著缩短

OC 判断

AI 把补丁差异分析从专业技能变成了可自动扩展的任务。安全团队需要把“补丁发布”视为攻击者获得高质量提示的时刻，甚至默认攻击者此前已经掌握线索。开源维护者最需要的不是更多保密压力，而是更可靠的测试、发布和升级基础设施。

为什么重要

• 对开发者：公开修复提交可能立即成为攻击线索，安全版本应尽量同步准备和发布。
• 对企业：漏洞扫描之外，还需要加快资产盘点、临时缓解和自动更新流程。
• 对用户：拖延升级的安全余量进一步缩小，长期停留旧版本会更危险。

参考来源

• Nowadays, the rumour of a vulnerability is enough｜Anil Madhavapeddy