漏洞还没公开，攻击已经开始

我读到这篇文章时，脑子里一直停着一个时间点：十分钟。

OCaml 维护者 Anil Madhavapeddy 把 cohttp 的修复 PR 放到 GitHub 上，十分钟左右，线上日志里就出现了针对百分号编码路径穿越的探测。此前，他已经让自己的 agent 只根据“路径规范化可能有问题”这个方向，在不到一分钟内造出本地探测 exploit。完整补丁还没有走完审查，攻击动作已经先探头了。

这件事最让人不安的地方，不是 AI 会写 exploit。真正的变化是：攻击者可能不再需要一份完整报告，只要得到一个模糊的方向，剩下的代码阅读、资料检索和试探都可以交给 agent。安全流程里那段原本用来争取时间的空白，正在变薄。

十分钟，足以让传闻变成动作

传统的安全叙事里，补丁公开像是发令枪。补丁出来，攻击者才开始研究；在这之前，漏洞躲在一个小圈子里，维护者还有几天时间。

但这次事件把顺序倒了过来。漏洞报告经由 Jane Street 的 Slack 传给作者，而报告线索本身又来自 Claude Fable 的发现。作者让 Claude 检查受影响代码，却被安全限制拦住；DeepSeek V4 Pro 找到了相关问题；作者自己的 agent 很快构造了可以探测本地服务的 exploit。随后，公开 PR 只提供了一个更响亮的信号，自动观察者便开始试探。

所以“传闻”不是一句无害的闲话。它更像一枚搜索按钮：按下去，agent 会把问题类别翻译成代码路径、输入样本和网络请求。对攻击者来说，信息的价值不取决于它是否完整，而取决于它能不能减少下一步尝试的数量。

这也解释了为什么我不愿意把它简单概括成“AI 攻击速度变快了”。速度只是表面。底下发生的是，漏洞描述从一段供人阅读的文字，变成了机器可以继续执行的任务。描述一旦进入错误的观察范围，安全边界就从仓库和补丁，扩展到了聊天、提交记录、议题标题和构建日志。

embargo 守住补丁，却没守住方向

这让传统的 security embargo 暴露出一个容易忽略的前提：它默认“知道问题的人少”，并且从知道问题到写出 exploit 需要大量人工工作。

Fang 等人的实验给出了一个很直观的对照：在 15 个漏洞基准上，给 GPT-4 agent CVE 描述时，成功利用率是 87%；不给描述时是 7%。这不是现实世界的成功率预测，却足够说明描述本身就是加速器。它不需要包含完整 PoC，只要把搜索空间从整座城市缩到一条街，agent 就能继续走下去。相关实验见论文原文。

原文还引用了 M-Trends 2026 的“负七天”利用时间，以及 marimo、Langflow 从 advisory 到首次利用尝试只隔几个小时的案例。这里的数字不能拼成一条精确的预测曲线：实验基准、行业统计和单个漏洞的时间口径并不相同。但它们共同指向一个事实——等到公告发出再启动防御，已经不是稳妥的默认动作。

这就是我读完后最想补上的区分：补丁保密，不等于问题类别保密。

私下开发补丁当然仍有用，尤其是影响面还没厘清的时候。可在开源项目里，真正容易外泄的往往不是那几行修复代码，而是“哪个函数、哪类输入、哪种边界条件出了问题”。GitHub 的临时私有 fork 文档也侧面说明了这条路的代价：集成、CI、协作者和跨仓库协作都会变得不顺。

换句话说，embargo 不是失效了，而是它保护的对象需要重新命名。它能收窄信息流，却未必能把防御速度推到攻击速度之前。

守方真正缺的是一条快车道

我以前写过“发现漏洞很容易，难的是让人去修”，当时关注的是：报告数量可以爆发，维护者的修复能力却不会自动增加。这篇文章让我把这个判断再往前挪了一步——现在不只是“找”和“修”之间有落差，“修好”和“送到现场”之间也有一条常被忽略的路。

Pesoli 等人在 2026 年的 bugonomics 论文里，把瓶颈称为 defender remediation throughput。这个词听起来抽象，放回 cohttp 的场景就很具体：维护者要确认漏洞、写出不改变正常语义的修复、跑不同平台的测试、发布新版本，下游发行版和产品还要重新打包。攻击 agent 可以并行翻很多门，维护者却要逐扇门换锁，再把钥匙送到每户人家。

Chrome 的高频安全更新说明，快速把修复送到端点是可以被工程化的。但一个浏览器主要面对自己的发布渠道，OSS 库则会被发行版、框架和产品重新包装。维护者连最终代码嵌在哪里都未必知道，所谓“发布了”与“用户安全了”之间，隔着一张分散的依赖图。

我补查了近一个月的讨论，看到更多人围绕 agent 的权限、隔离和非人类身份争论，却没有找到足够稳定、可复核的“自动 exploit 规模”共识。这反而是个有用的刹车：具体日志和实验足以改变响应设计，但还不足以支撑“所有漏洞都会在几秒内被攻破”这种口号。

如果把这条链画完整，开源安全响应至少有三个相互咬住的瓶颈：线索能否被转成攻击动作，维护者能否完成验证，修复能否穿过下游拓扑。它们不是三项并列 KPI，而是一条流水线。第一段提速，后两段不动，用户只会更快地看到风险。

把安全响应改成两只钟

我现在更愿意用两只钟来想这件事。

第一只钟计“从传闻到临时防御”。它不要求立刻把完整语义修好，而是寻找一条足够窄、可观测、能回滚的边缘规则。cohttp 这次的问题，原文提出可以先规范化请求 URL 中百分号编码的路径分隔符；这类规则可以先挡住明显的攻击形状，再给完整补丁留出审查和跨平台测试的时间。Cloudflare 处理 Log4Shell 的 managed rule就是商业基础设施里的类似思路。

第二只钟计“从修复到长期稳定”。临时规则不懂全部业务语义，可能误伤合法请求，也可能只覆盖某一个入口。它必须被观测、撤回，最后由正确的代码修复接替。快的那一层负责争取分钟，慢的那一层负责把系统真正修好；把两者混成一个动作，结果要么是补丁来不及，要么是临时规则被误当成永久答案。

因此，维护者收到一条漏洞线索时，我会先问四个问题：

这个问题的攻击形状能不能被一条低风险规则先挡住？
谁可以在不扩大泄漏面的情况下完成验证和回归测试？
补丁发布后，哪些发行版、包管理器和产品会继续携带旧版本？
哪些判断必须由人签字，哪些机械检查可以交给 agent？

这四问比“什么时候发 advisory”更接近用户真正关心的结果。因为用户并不生活在公告里，用户生活在一个请求会不会被拦住、一个依赖会不会及时升级的现场。

原文最后谈到 antibotty 网络和互联网生态，我觉得它的价值不在于再造一个更大的安全平台，而在于补上 OSS 长期缺失的分发机制：某个项目听见漏洞后，怎样让相邻的部署点在几秒内得到一条可信、局部、可撤销的防御规则。这里当然需要身份、声誉和回滚，不是把所有规则都交给一个中心服务。

这也是“AI 会不会赢”的问题应该换成的样子。攻击侧的 agent 可能越来越会把线索变成动作，但安全的胜负不由谁先写出一段 exploit 决定，而由谁先把控制送到现场决定。我的判断是：如果开源生态不补上验证与传播这条快车道，模型越擅长搜索，维护者越会被迫把时间花在追赶已经发生的动作上。

如果你维护一个开源项目，今天收到一条模糊的漏洞传闻，你最先会启动哪一只钟：临时缓解，还是完整修复？为什么？

漏洞还没公开，攻击已经开始

十分钟，足以让传闻变成动作

embargo 守住补丁，却没守住方向

守方真正缺的是一条快车道

把安全响应改成两只钟

延伸阅读

参考资料