8月20日18点15分（UTC），OCaml生态里最常用的HTTP库cohttp发布6.3.0版本，修复了一个编号OSEC-2026-16、CVSS评分8.7的路径穿越漏洞。维护者Anil Madhavapeddy在自己的博客里讲了一个更让人不安的细节：他8月14日公开修复PR之后，大约十分钟，自己服务器的日志里就出现了与漏洞完全匹配的探测请求。他据此得出一个大判断——传统"先私下修复、再公开通报"的安全禁运期已经失效，因为只要一点"漏洞的传闻"，AI agent自己就能补全剩下的攻击代码。
这个说法值得警惕的地方，不在于AI攻击变快了多少，而在于支撑这个核心论点的证据本身经不起核查。同一时间发生的另外两个案例反而更值得细看：它们不光把"利用变快"这件事坐实了，还带出一个原文没提的麻烦——补丁修好了，不代表堵死了。
解码顺序错在哪，补丁到底改了什么
cohttp的问题出在处理顺序上：程序先对请求路径做了规范化，再做百分号解码，结果%2f这样编码后的斜杠没能被当成路径分隔符识别，绕开了对..的过滤，攻击者可以借此跳出预期目录。6.3.0的修复把顺序倒过来——先解码一次，再处理.和..路径段，并新增了一个Cohttp.Path.normalise函数供上层应用调用。用了eio模块的cohttp-eio因为走另一套沙箱化解析逻辑，没受影响。
十分钟警报，查无实据
关键问题是：这个"十分钟"的说法目前只有作者自己的叙述，没有公开的原始日志、来源IP或精确时间戳可以核对。文章里另一处更关键的引用——某研究给GPT-4类agent一段CVE描述后能攻破多数基准漏洞，平均利用时间已经变成负值——同样只是转引一手数字，没有看到独立复现或方法论审视。这个数字撑起了全篇最重要的论点，却缺乏能让人放心引用的底座。
这不是说AI没有加速攻击，只是说我们现在处在一个连"危机本身有多快"都来不及核实的阶段，这本身才是更值得警惕的事。
十分钟之说信而无征，补丁之效验而未足。
- 提醒.把一份未经核实的自述当成"禁运期已死"的证据，风险不比漏洞本身小。
9小时、20小时，比"探测变快"更麻烦的是补丁没堵死
同期两起有编号、有评分的案例反而更能说明问题。marimo的CVE-2026-39987，一个未授权的WebSocket终端能直接拿到预授权执行权限，评分9.8，公告到首次实际利用尝试只隔了9小时，修复落在0.23.0版本；Langflow的CVE-2026-33017，公开的flow端点能触发动态Python执行，首次利用发生在公告后20小时。更麻烦的是，Langflow第一版补丁（1.8.2）后来被证明依然能被绕过，得再修一次。
这说明危机不只是"打补丁太慢"，也可能是"补丁本身没堵死"。而验证一个补丁是否真的有效，目前几乎没有独立的第三方机制去核查——这正在变成一个新的、比"找漏洞变快"更实际的瓶颈。
真正卡住防御方的，是六道关卡，不是找洞的速度
有一份提出"bugonomics"概念的论文把问题拆得更细：瓶颈不是AI找漏洞的能力，而是防御者的"修复吞吐量"——验证、去重、排序、补丁设计、回归测试、发布，六个环节里任何一环跟不上，前面找漏洞的速度提升就是白搭。它讨论的核心其实不是前沿模型和开源工具谁更强，而是怎么把稀缺的人工验证和发布产能，导向能扛住的修复，而不是耗在机械化的搜索和报告撰写上。
这个瓶颈还叠加着一层结构性落差。像Project Glasswing这类受限的前沿AI访问计划，已经覆盖150家机构、15个国家，里面有关键基础设施运营商、云和金融服务商，还有Linux基金会，但像cohttp这样的小团队拿不到入场券。大公司能把修复直接推到用户设备上，小项目却连能不能用上同档次的AI去排查、验证都做不到。
- 结论.找漏洞变快不等于修复变快，能验证补丁真的管用，正在变成下一个稀缺资源。
接下来值得盯的不是"AI攻击又快了多少"，而是那个负七天的统计数字有没有第三方复现，协同披露这套跑了二十多年的流程会不会真的被替换，以及像Langflow那样"补丁打了但没打对"的情况，会不会变得比"补丁太慢"更常见。