发现两天，修两个月，你那台老服务器等不到

Hello，我是飞飞。

先问你个事：你手上有没有一台服务器，PHP 版本是几年前装上去、之后就没再动过的？我猜不少人得想一下才答得上来，还有一批人根本不知道去哪看。

这两天有个漏洞，把这个问题从「懒得查」变成了「最好今晚就查」。发现到能打通 WordPress，2 天；报给 PHP 官方到确认开始修，28 天；报上去到补丁发布，58 天。从发现到公开，63 天。发现变便宜了，修复没有，而修复这一侧最贵的一段，是没有人有义务修。这批机器，很可能就在你每天打开的网站里。

两天就打通了

8 月 19 号，Wiz 的研究团队在 PHP 引擎里挖到了头一个洞。一天之后，Drupal 被打通。两天之后，WordPress 被打通。不用登录，拿最新的容器镜像，默认配置就能进。

两个漏洞的编号是 CVE-2026-109618 和 CVE-2026-109619，CVSS 评分都是 9.2，满分 10。网上传的 10.0 出自泄露帖，不是官方口径。

位置才是关键。洞不在 WordPress 里，也不在 Drupal 里，在 PHP 本身。上面跑什么应用都一样，一句 Hello World 也可能中招。所以你把 WordPress 升到最新版，也补不上这个洞。Wiz 和 OpenAI 给的影响范围是同一个数：大约 70% 的网站。

其中一个洞像 2014 年的 Heartbleed。PHP 处理上传进度的代码，会把已经释放的进程内存塞进 PHPSESSID 这个 cookie 还给客户端。那块内存里可能有别的请求留下的密码、会话 token、API key，甚至 TLS 私钥。说白了就是，上一个访客登录时敲的密码，可能跟着这次响应一起发给了下一个人。

这里有个最容易写错的地方。不少标题写「AI 发现了这个漏洞」，不准确。Wiz 用自家的 Atlas 加 Gemini 4 Argon 和 GPT-5.6 Sol，独立发现了两个。另一拨是 OpenAI「Patch the Planet」项目里的 Calif，用 GPT-5.6 Sol 找到了其中一个。两拨人各自用 AI，独立拿到同一批问题。OpenAI 的原话也是这么分的。

AI 到底改了什么

「AI 又变强了」这个说法，我不太想用。

Wiz 自己的解释是：这些缺陷在代码里躺了几十年，但要证明它真能被利用，需要一串极其复杂的步骤，复杂到「处在人类研究员实际能做到的边界上」。前沿模型做的，是把这道门槛往下压了一大截。

从一片已知的不安全区域，到一条能跑通的利用链，中间隔着一长串步骤：环境要对，配置要对，应用的调用顺序也要对，错一环，链就断。AI 压掉的就是这一段。整条链它都干：找洞、写利用、做检测、验补丁。Wiz 原文里点名 Gemini 4 Argon 在这四步上都有贡献。

以前为什么没人做？Wiz 也解释了。内存漏洞的麻烦在于，PHP 版本、配置、应用行为稍有不同，利用链依赖的假设就会断。打穿一个部署的利用，换一个部署可能要重做分析、重测、重调。这种活一个人干不动，一个团队也铺不开。

Wiz 给了一个量级：一个研究员一周做完的事，过去要一个世界级团队做几个月。

这句话很容易被读成「AI 替代了安全研究员」。不是。Wiz 是独立发现的，人全程在场，AI 是工具。真要说变化，是同一个人的产能边界被推远了。

OpenAI 还有一句，「据我们所知，前沿 AI 比攻击者先找到这些漏洞」。「据我们所知」这四个字，他们自己保留着。同一篇里也承认，这套能力同样能帮攻击者更快做出利用工具。

OpenAI 还预告，这类发现未来几个月会明显变多。发现这一侧，只会更便宜。

报上去，等了 28 天

Wiz 8 月 24 号把报告交上去。按官方时间线，PHP 到 9 月 21 号才确认并开始修，中间隔了 28 天。补丁发布是 10 月 21 号，从报上去算，58 天。58 天里有一整条协调链，那 28 天里发生了什么，官方时间线没讲。

28 天。前面发现只用 2 天。

剩下的时间也不只是写代码。OpenAI 那篇说明提到，这条链上，PHP 维护者负责开发和发版，Automattic、Akamai、AWS、Cloudflare、Fastly、Google、Imperva、Microsoft、Vercel 一起对表。

发现快，是因为一双手就够。修复慢，是因为要一群人同时点头。

补丁只发到 8.2

真正要命的是补丁范围。

修复版本是四个：8.5.12、8.4.27、8.3.36、8.2.35。最低要 8.2。

可影响范围，按 Wiz 的说法是「过去十年发布的所有 PHP 版本」，一路追到 5.4，那是 2012 年。8.1 及更早的版本已经 EOL，官方不再维护，也不再发补丁。

发行版厂商有可能给自己维护的包回补。但那得看你的机器跑的是哪家的包，这件事你控制不了。

不是修不动。是修的人，和用的人，早就不是同一批了。

那 70% 里，有多少台跑的是这些版本，没有人给出准确数字。能确定的是它们还在跑，还在收表单、存密码、跑支付，只是主人可能早就忘了自己用的是哪个版本。

没人有义务修

一栋老楼的天花板在滴水。你抬头两分钟就看见了。报给物业，物业一个月后回一句「收到」，两个月后才带着工具来。这个节奏你已经觉得慢了。

可还有一批楼，压根没有物业。合同几年前就到期了，业委会散了，维修基金也没了。管子还在漏，漏得跟新楼一模一样，只是没有人有义务来修。

PHP 8.1 及更早的那些机器，就是这批楼。

技术上的修复，从来不算最难的一段。难的是「这件事归谁」。有新合同的人，28 天能等来一句确认。没有合同的人，等到机器报废也没人来看一眼。

OpenAI 这次拿出 10 亿美元的 Daybreak 额度，给缺资源的防守方。注意，给的是额度，不能直接当现金花。这笔钱能帮一部分人把补丁打上，但补丁打完，下一批机器还是没人认领。

这层责任还会往下掉。很多人用的是虚拟主机或者共享主机，PHP 版本是主机商定的，你自己既看不到也升不了。去问客服，客服让你提交工单。工单排到哪一天，没人告诉你。

所以「升不升级」这件事，落到不同人身上完全不是一回事。有人是点两下，有人是求人。

我在哪一层

我对 PHP 没有任何一手经验。这个漏洞我没跑过，也没复现过。我自己这个博客是 Hexo 搭的，跟 PHP 没关系。所以我不装「我测了」的姿态。

但我很清楚我站在哪一层。

我是依赖链末端那个普通开发者。天天 pip install，刷到个有意思的开源项目就 clone 下来让 agent 跑，npm install、跑 setup，说实话我不细看每一步执行了什么，报错了就一句「你看着修」。这话我六月写过一次，现在还是这样。

今年我写过好几篇 agent 安全的稿子，主角都是 AI 站在施害那一侧：骗它、偷它、让它越权。这篇反过来。前面问的是「agent 会不会咬人」，这篇问的是请它当保安，它翻出多少陈年旧账，而我们修不修得动。

我手上也有过一个小号的版本。一条全自动的发布流水线，一个 token 悄悄过期了。部署从那天开始失败，一连失败了一整天。没人盯着。我是第二天才发现。当时的结论是，自动化最贵的成本藏在没人看着的时候。

不完全一样。流水线那次，加个告警就能补上；这批机器不行，你连告警都没地方加。但底下是同一件事：没人看着的时候，坏掉的东西不会自己喊疼。

今天能查的三件事

先查版本。有 SSH 就敲 php -v，最上面那行就是。用 WordPress 的，后台进「工具」→「站点健康」→「信息」→「服务器」，PHP 版本写在里面。OpenAI 这次也放了个 PHP 版本检查器，做成 Codex 的一个 skill，愿意用就用。

命令行看到的版本，跟网站实际跑的可能不是同一个。有主机面板的，以面板里写的为准。

能升就升。目标是最低 8.2.35，往上 8.3.36、8.4.27、8.5.12 都行。共享主机升不了，就把这条当工单发给主机商，问他现在跑的是哪个版本、什么时候升。

实在升不了，先在前面挡一层。挂一层 WAF，说人话就是网站前面那道请求过滤，或者反向代理，把可疑请求拦掉。这个只能顶一阵，别把它当修复。具体规则跟着安全厂商的公告走，别自己拍脑袋写。

还有一条不是技术动作：别觉得「我的站小，没人盯」。这个洞不需要登录，也不需要专门针对你。谁先扫到，谁就能试。

回到开头那个问题。你手上那台服务器，PHP 是哪个版本？

查完回来留个数，我想看看有多少人跟我一样，得先翻一遍面板才知道。

发现两天，修复两个月。而有些机器，等不到那一天。你要是正好有一台，今晚就去查。别等有人来修。