10 月 21 日，PHP 发了四个紧急版本，修两个漏洞，CVSS v4.0 都是 9.2。攻击路径不需要登录：一个 HTTP 请求打到 Apache 的 mod_php 上，在应用代码执行之前，就已经能读到 worker 内存里的密码和 token，或者直接执行命令。

PHP 撑着大约 70% 的网站。这两条公告编号很朴素——CVE-2026-109618、CVE-2026-109619——但它们代表的事情一点都不朴素：从发现到补丁发布协调了两个月，补丁上线之前，攻击流量已经到了。

这件事容易被读成「AI 又挖出一个大洞」。不是。真正值得看的是另一组数字：截至 10 月 2 日，Anthropic 的漏洞披露看板记了 6,157 个已披露漏洞，覆盖 591 个开源项目，其中确认打上补丁的是 516 个。

6,157 对 516。这就是「草台班子」四个字的全部含义。不是 AI 太能干，是发现已经上机器了，修补还停在人的手上。

今年 AI 挖出来的洞，一张表

按时间倒序，以软件为粒度。颜色是严重程度：红是严重（9.0 以上），橙是高危（7.0–8.9），灰是未给评分或影响面待定。第三行写状态——已经出了后果的、还没修好的，单独标出来。

看完这张表会有一个错觉：AI 好像把行业的安全水平拉高了。恰恰相反，它把底裤掀开了。

拆开看，草台在哪

发现的量级和修的量级，不在一个数量级

Glasswing 第一个月，10,000 多个高危候选，1,726 个被外部安全公司复现确认为真，最后上游打上补丁的是 97 个。

到 10 月 2 日累计披露 6,157 个，516 个打上补丁，584 个拿到 CVE 或 GHSA 编号。大部分洞连编号都还没有，卡在「报给维护者了，但没人处理」这一段。维护者不是不想修，有几个项目直接跟 Anthropic 说，能不能慢点报。一个漏洞的修复不是改一行代码：找根因、设计不引入回归的修法、在各种配置和平台上测、协调披露时间、通知下游。这一整套是人的工作量，AI 帮不上。

补丁本身也是草稿

5 月那波 Linux 内核最说明问题。Dirty Frag 的补丁发出去一周，Fragnesia 就来了——它恰恰是那个补丁引入的。攻击者拿旧洞打不动了，转头打新洞，同一条页缓存写的路子。

curl 8.23.0 一次发了 24 个公告，其中 14 个的标题里带「连接复用」「凭据」「Cookie」「HSTS 状态」。翻译过来就是：上一次请求的状态漏到了下一次请求里。这不是某个人的失误，是一个二十多年历史的状态机，每加一个特性就多一组组合。

没人负责的代码，补丁发不出去

nginx 那个 18 年的堆溢出，上游 5 月 13 日就修了。但 Kubernetes 社区的 ingress-nginx 在 3 月 24 日已经归档，最后一次发布是 v1.15.1，里面编着同一份有洞的 C 代码。没有维护者，就没有 v1.15.2。F5 在 issue 里给的答案是「用我们的商业版控制器」——这不是打补丁，这是搬家。

FFmpeg 那个洞更好笑。JFrog 演示了在 Nextcloud 上用一张 50KB 的视频文件拿到 www-data 的 shell，Nextcloud 的回应是：这个洞不在我们的软件里。技术上没错，运营上是错的——用户装的是 Nextcloud，不是 libavcodec。

窗口给了，也没人用

Rejetto HFS 的时间线最扎人：补丁 7 月 10 日提交、7 月 13 日发版，然后整整十周什么都没发生。9 月 30 日 Horizon3 把攻击链写出来，第二天 VulnCheck 的蜜罐就看到了探测。80 天的提前量被浪费掉了，原因不复杂：这台机器不在任何人的资产清单上。

换个 AI 再扫一遍，还能扫出东西

curl 那 24 个公告里，18 个来自 AISLE 的审计。AISLE 自己点了一句：Codex Security、ZeroPath、Mythos 都在同一份代码上扫过，没再找到这些。这句话的意思是，「AI 已经看过了」正在变成一句废话。它只说明某一次扫描跑过了，不说明下一次扫不出东西。跟当年「这个模块跑过 fuzzer 了」一模一样的自我安慰。

我的判断

这一年的变化不是「漏洞变多了」。漏洞一直在那儿：OpenSSL 里 1998 年的栈溢出等了 28 年，nginx 里 2008 年的堆溢出等了 18 年，它们不需要 AI 来存在。

变的是漏洞的可见性从稀缺变成了过剩，而承接这个过剩的，是一套按稀缺设计的流程：90 天披露窗口、季度补丁日、按 CVSS 排优先级、维护者业余时间修。

所以「草台班子」不是说写代码的人不行。恰恰相反，这些项目里有这个行业最好的一批工程师。是流程承不住量：一套为「一年几十个洞」设计的分发系统，突然要处理「一个月一万个」。真正被证伪的，是那句流传了很多年的行业自辩——「这段代码被审了很多年，很成熟」。审了很多年，只证明它被看过很多次，不证明它是对的。五次不同 AI 审计在同一份 curl 代码上给出不同结果，就是最直接的证据：覆盖率不等于正确率，而且「看过了」这件事本身没有记忆。

泼一盆冷水

一，92.7% 不是模型的准确率。那个数字的分母是「送去外部公司人工复核的 6,123 个」，不是「模型报出来的 29,439 个候选」。真正的端到端漏斗是 29,439 → 6,123 → 5,674 确认。「AI 找洞很准」这句话，只在人工筛过一遍之后成立。

二，CVE 数量被同一个根因放大了。bc-csharp 一家 10 月 2 日就出了一批，OpenSSL 一轮 12 个。按软件数，一个库算一个；按 CVE 数，一个根因能裂成五条。两种数都有人用，混着用就会把规模说大。

三，在野利用仍然是少数。表里 13 行，明确有在野或已确认后果的是 5 行。绝大多数条目是实验室复现加公开 PoC。AI 把 PoC 的门槛打下来了，但从 PoC 到「有人在打你的机器」，中间还隔着资产发现和武器化两步。

四，「由 Claude 发现」这个归因是申报方自己写的。CVE 记录里的 credits 栏由 CNA 填，没有第三方去审「这个洞是不是只有 AI 能找到」。Copy Fail 那条写得很老实：人类研究员先提出了精确假设，AI 用大约一小时走完了代码路径。这个区分很重要，但大多数转述里被抹掉了。

怎么用

一，把「补丁可用」当成披露日，不是验证完成日。nginx 从披露到在野是 3 天，PHP 是补丁前就到了。你的 30 天 SLA 在这种节奏下，等于承诺「我会带着已知的武器化漏洞运行一个月」。

二，专门盘一遍没人维护的那部分。归档的 ingress controller、锁死的 vendor bundle、固件里的 TLS 库、容器镜像里的 libavcodec。特征很一致：漏洞有公告，补丁没发行版。它们不在你的依赖清单里，但一定在你的攻击面上。

三，别再问 AI 找得准不准，问资产清单全不全。这批漏洞的共同点不是难，是藏在你以为自己没有的东西里。Rejetto HFS 那 80 天没人用，不是因为难修，是因为那台机器不在任何表格上。

四，把 48 小时当成严重漏洞的新常态。Zero Day Clock 统计的 2026 年平均利用时间已经压到 20 小时以内。这个数字有争议——它测的是披露到确认利用，不是披露到大规模攻击——但方向没有争议。

最后说一句可能不太好听的：这一轮真正的收获，不是 AI 帮我们找到了多少洞，是它顺手证明了这个行业对「安全」两个字的自信，一直建立在「没人仔细看」之上。现在有人——或者说，有个东西——仔细看了。

参考资料

• Anthropic 协同漏洞披露看板，2026-10-02 快照
• PHP 官方安全公告与 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 发布说明，2026-10-21
• curl 安全公告 CVE-2026-92392，2026-10-14
• F5 安全公告 K000161019 与 NGINX 1.30.1 / 1.31.0，2026-05-13
• Cert-IST《Linux under pressure: the cascade of vulnerabilities in May 2026》
• JFrog 对 CVE-2026-8461（PixelSmash）的技术分析，2026-06-23
• Horizon3 对 CVE-2026-61500（Rejetto HFS）的攻击链分析，2026-09-30

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。