剑桥计算机科学教授、OCaml核心维护者Anil Madhavapeddy最近在博客里写了一件让开源圈警觉的事:一个安全补丁刚拿到公开讨论区,十分钟内网站就开始收到percent-encoded路径穿越的探测请求。放在过去,这类漏洞从发现到有人真正动手利用,通常要等几天,发布补丁往往还有一到两周的缓冲期。
这不是孤例。rclone维护者Nick Craig-Wood在Hacker News评论区证实了同样的压力:项目头十年总共收到过约20次安全披露,而最近一个月收到的数量超过40次,其中约75%确实有值得跟进的问题。更麻烦的是,GitHub分配CVE编号的周期,从原来的2-3天拉长到3-4周,rclone只能在更新日志里先写上CVE-PENDING顶着发。
从轶事到时间线:rclone这一个月发生了什么
把rclone的抱怨还原成具体动作,能看得更清楚。7月8日,项目发布v1.74.4,修复了两个问题,其中一个serve restic在--private-repos模式下的跨租户路径穿越漏洞被分配了编号CVE-2026-59733。7月31日,rclone又发布v1.75.0,一次性放出十项以上的安全公告,涵盖serve restic的根目录逃逸(评级High)、本地编码路径穿越、未授权pprof信息泄露等问题。
这意味着不到一个月里,rclone连续打了两轮补丁,处理的漏洞类型从数据泄露到远程逃逸都有。审查、修复、测试、发布这几步,AI能帮着分诊、能帮着写修复建议,但最终要不要合并、要不要打标签发布,还得靠人。Craig-Wood说得直接:真正卡住他的不是"找不到漏洞",是"处理不完"。
这不是OCaml和rclone的个案
如果只看这两个项目,容易把它当成小众基础设施的孤例。但把镜头拉远,能看到同样的模式在更大规模上重复。Google威胁情报团队旗下的Mandiant报告过,他们的agentic审查系统在一次两天的调查里,从被盗源码中发现了超过100个关键漏洞。Anthropic自己运营的漏洞披露仪表盘显示,截至2026年8月26日,累计在392个开源项目里披露了2300项发现,其中421项已在上游修复,462项被正式分配了CVE或GitHub安全公告编号。
这些数字放在一起说明一件事:AI让"读代码找漏洞"这件事的成本降到接近于零,而且不分厂商、不分项目大小。剩下卡脖子的,全是靠人和机构运转的环节——CVE分配、代码审查、协同发布窗口。
漏洞发现在变得免费,响应流程还在按人手计价。
"补丁发布几分钟就被攻击"到底指什么
这句话本身值得拆开看,不能直接当结论用。Anil说的"十分钟",指的是探测请求出现——也就是有人(或者agent)开始尝试,不等于确认的在野利用已经得手。Cloud Security Alliance记录过一个更完整的实证案例:2026年Marimo的一次远程代码执行漏洞,从公开披露到确认的在野利用,间隔是9小时41分钟,而且当时并没有公开的PoC代码。
两个案例根本不在同一把尺子上——一个是"扫描器盯梢"的速度,一个是"确认攻击成功"的速度。把它们混为一谈,会把恐慌感放大到失真的程度。但即便用更严格的Marimo案例做基准,不到十小时的窗口,对照传统"几天到几周"的embargo惯例,依然快得离谱。这也是为什么Anthropic自己设定的协同披露政策,给出的是90天披露期、补丁发布后再等45天才公开完整技术细节——这个节奏在AI辅助分析补丁diff的速度面前,已经显得保守而奢侈。
谁先扛不住,接下来看什么
最先感到吃力的是像rclone这样由个人或小团队维护、但用户覆盖面很广的基础设施项目——漏洞分诊可以靠AI加速,但代码审查、测试、打标签发布这些环节,还是得由几个人肉身顶着。
- 风险.维护者的产能没有跟着AI提速,过劳和响应延迟会先在这类项目里爆出来。
- 结论.真正该盯的变量,是GitHub们会不会改CVE分配流程,以及会不会出现Anthropic式弹性披露窗口那样的新行业惯例。
大型商业软件公司有专职安全团队和商业化的SLA,暂时还能扛住这个剪刀差。但开源生态里大量依赖志愿劳动的基础设施项目,正站在这轮加速的第一排。