AI 一周找到的漏洞，人类修了两个月
这周最忙的人，大概是全世界管 PHP 服务器的运维。
10 月 21 日，PHP 官方紧急发布了 8.5.12、8.4.27、8.3.36 和 8.2.35 四个版本，修复两个编号为 CVE-2026-109618 和 CVE-2026-109619 的漏洞，业内叫它 PHP2Shell。两个漏洞的 CVSS v4 评分都是 9.2，从 2012 年的 PHP 5.4 一直到最新的 8.5 都受影响，在 WordPress、Drupal 这类常见程序上，不用登录就能远程执行代码。按 W3Techs 的统计，在能识别出服务端语言的网站里，大约 69% 用的是 PHP。
接下来两天，芬兰政府把所有对外服务下线，法国内政部的网站全部关停，荷兰政府门户 Overheid.nl 也暂时下线，维基媒体关掉了一批服务。美国国家安全局给出的建议很直接：没法马上升级的，先把网站停掉。
我这个站是纯静态页面，nginx 直接返回 HTML，没有 PHP，那两天算是躲过去了。但这件事值得多看几眼。这是一个由 AI 协助挖出来、波及大半个互联网的漏洞，而且从发现到被利用的整条链路，都能看到 AI 的影子。
发现：从“理论上有问题”到“能打穿”
PHP2Shell 的根子不复杂。PHP 在处理一个请求时，如果遇到内存耗尽之类的致命错误，会直接跳出去结束请求，这时一些内部状态没有被清理干净。下一个请求进来，复用了这些残留的状态，就可能读到不该读的内存，或者改写它。
这个问题并不是今年才有人注意到。按维基百科整理的时间线，2024 年就有 PHP 核心开发者在审计中碰到过其中一处内存耗尽的处理问题，但团队对怎么修没有达成一致，当时也没人能写出可用的利用代码，事情就放下了。
今年 8 月，安全公司 Calif 在 OpenAI 的资助下审计 PHP 源码，借助 GPT-5.6 Sol 找到了第一个漏洞。几周后，Wiz 用自家的 Wiz Atlas，加上 Gemini 4 Argon 和 GPT-5.6 Sol，独立发现了同样的问题。Wiz 的时间线写得很细：8 月 19 日发现，20 日在 Drupal 上打通未授权远程执行，21 日在 WordPress 上打通。按他们的说法，一个研究员大约一周完成的工作，以前要一支顶尖团队花上几个月。
真正变化的地方在这里。找到一个“看起来可疑”的地方从来不难，难的是证明它能被利用：要针对不同的 PHP 版本、不同的配置、不同的内存布局反复调试，一次次失败再改。过去这一步要靠极少数高手熬出来，所以很多“理论上的问题”就一直停在理论上。现在模型可以接下大部分调试和迭代，证明成本一下子降了下来。
Calif 自己倒是很克制。他们说，用的都是公开可用的模型，没有特殊工具，真正起作用的是对 PHP 历史的了解：“没有哪个模型能靠几句简单的提示词挖出所有漏洞，至少现在还不能。”
修复：还是原来的速度
发现快了，修复没有跟着快。
按 Wiz 公布的时间线，他们 8 月 24 日把漏洞报告给 PHP 安全团队，9 月 21 日 PHP 确认并开始协同修复，中间隔了 28 天；从确认到补丁发布，又是 30 天。
我不觉得这是谁的失职。据《卫报》的报道，PHP 基金会一共只有 13 名全职和兼职员工，维护的却是大半个互联网的底座。修这种漏洞也急不得：要改的是十多年前定下的错误处理机制，要照顾多个版本分支，还要和 Cloudflare、AWS、微软、Google 这些厂商协调，在补丁发布前准备好防护规则。CISA 等美国政府机构也参与了协调。这套流程本来就是按“人的速度”设计的，一个漏洞从报告到修复，按月算是常态。
问题在于，它面对的已经不是“人的速度”了。
窗口：从按天算到按小时算
原定的计划是 10 月 21 日 14:00（UTC）发布补丁。计划没能走完。
AWS 在自家的 MadPot 蜜罐系统里，最早在 10 月 17 日就看到了针对这个漏洞的利用尝试，来自一个匿名网络的 IP，比公开披露早了四天。攻击者是怎么提前拿到漏洞信息的，到现在也不清楚。10 月 20 日，消息在 Hacker News 上泄露，watchTowr 在补丁出来之前就确认了漏洞，Calif 还不小心放出了一段演示利用的视频。安全公司 Sansec 预测，补丁一发布，“15 分钟之内就会出现大规模攻击”。
21 日凌晨 3 点（UTC），Cloudflare 给所有客户提前开了临时防护规则。下午补丁发布，几个小时之内就有多份利用代码在网上流传，AWS 的传感器几乎同时就收到了攻击。Palo Alto 的 Unit 42 统计，可能暴露在公网上的 PHP 实例超过 2260 万个。
AWS 在报告里把补丁到攻击的间隔越来越短，部分归因于 AI 辅助分析：现在有更多的人，能拿着补丁或公告，很快写出利用代码。他们给防守方的建议里有一句，我觉得是这次事件最该记住的：对于暴露在公网的高危漏洞，修复和缓解的时间要按小时算，不要按天算。
攻击者也有了 Agent
10 月 23 日，Unit 42 更新了一份细节，比漏洞本身更让我在意。
他们处理的一起事件中，受害方是一家欧洲政府机构。攻击者通过 PHP2Shell 进来以后，用的是一个 AI Agent 攻击平台做后续渗透。从最初入侵算起，两个小时之内，对方就拿到了密码哈希和多因素认证的密钥，接着搭了一条 NTLM 中继隧道进入 Active Directory，开始尝试提权到域管理员。
Unit 42 从命令记录里认出了 Agent 的痕迹。攻击者一批批执行命令，每段输出前面都插着 “==SHELLUSER==”、“==PASSWD==” 这样的分隔标记。这些标记不是给人看的，是方便模型解析结果用的。任务都很短，一个接一个排着执行，失败了马上换路子，不会停下来琢磨。
这让我想起以前做线上值班的日子。一次入侵从进门到拿下域控，过去往往要几天甚至几周，防守方总还有一段发现和反应的时间。如果这件事被压缩到几个小时，还不需要人守在键盘前面，那么“发现了再处理”这个默认假设，就不再成立了。
对做系统的人意味着什么
防守方当然也在用 AI。补丁发布当天，OpenAI 宣布了 “Patch the Planet” 计划，拿出 10 亿美元补贴资源不足的防守方使用它的 Daybreak 安全平台，并预计类似的发现会在接下来几个月“急剧增加”。Wiz 也在用 Gemini 做攻击检测和补丁验证。攻防双方用的是差不多的模型，差别还是落在系统上，看谁能更快把模型的能力接进自己的流程里。
结合这次的经过，我觉得有几件事是每个团队现在就可以做的：
- 把发布流水线当成安全设施。 能不能在几个小时内把一个补丁推到所有机器上，而且出了问题能一键回滚，取决于平时的构建和发布是不是自动化的。这件事平时看是效率问题，出事的那天就是安全问题。
- 知道自己有什么。 2260 万个暴露实例里，有多少是团队自己都忘了的老站、测试机、内部工具？没有资产清单，补丁再快也补不到它们身上。
- 能静态就静态。 一个页面如果不需要在服务器上跑代码，就别让它跑。攻击面最小的代码，是不存在的代码。
- 检测要看行为，不只看特征。 AWS 也强调了这一点：别只依赖针对某个 CVE 的签名。PHP 进程突然执行系统命令、工作进程异常地反复重启，这些行为不管是哪个漏洞引起的，都值得报警。从 Agent 的操作习惯里，也能提炼出新的检测信号。
- 排查从最早的时间点开始。 这次的利用尝试出现在披露前四天。查日志要从 10 月 17 日甚至更早查起，不能从补丁发布那天查起。
写在最后
以前我们默认，漏洞被发现、被证明、被利用，这几步之间都隔着一段时间，修复流程正是建立在这段时间上的。PHP2Shell 把这段时间压没了：AI 让证明一个漏洞能用变得便宜，也让把补丁变成武器变得便宜，修复那一侧却还是十几个人、按月推进。
OpenAI 说类似的发现会越来越多，我相信。接下来几年，开源基础设施的维护方式、漏洞的协同披露流程，大概都要按新的速度重新设计一遍。在那之前，每个团队能做的，是先让自己从“发现问题”到“修好上线”的那条路，尽可能地短。
参考资料
- Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 2026-10-21
- CJ Moses, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog, 2026-10-21
- Palo Alto Networks Unit 42, Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619, 2026-10-23 更新
- The Next Web, PHP rushes out emergency patches for two critical bugs AI found first, 2026-10
- Wikipedia, PHP2Shell（时间线及《卫报》关于 PHP 基金会人员规模的报道）