PHP 末日漏洞：AI 把修不动的旧洞，盘成了 48 小时的火情

Thu, 22 Oct 2026 09:30:00 +0800

先说清楚信息来源，免得后面混淆。

漏洞的技术细节和发现经过，我读的是 PHP Foundation 10 月 21 日的官方博客全文，以及 php.net 的安全公告索引；两个 CVE 的技术描述以 PHP 官方仓库的 GHSA 安全通告为准。发现方一侧，TechCrunch 和 The Decoder 的报道相互印证，OpenAI 和 Wiz 各有官方博客，我都核了对不上号的地方，比如「自 PHP 5（2004 年）起所有版本受影响」这个说法出自 TechCrunch，Wiz 自己的措辞保守一些，写的是「追溯到十年以上」。NSA 的警告来自其 NSACyber X 账号原文，经 TechCrunch 转引。

两个洞，和一场 48 小时的赛跑

10 月 21 日，PHP 项目发布了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修复两个严重漏洞。PHP Foundation 的原话是：如果你的服务器跑着 PHP，「必须立即更新」。

两个洞都在 PHP 引擎几乎每个请求都要经过的部分：内存管理和错误处理。这也是它们麻烦的根源，后面会讲为什么修了两年。

第一个是 CVE-2026-109618，OOM 损坏导致的远程代码执行。如果一个请求恰好在错误的时刻碰到 PHP 的 memory_limit，PHP 可能留下一段只初始化了一半的内部数据，之后把它当作有效数据使用，造成内存损坏。官方安全通告写得很直白：在 Apache 配 mod_php 的环境下，一个未认证的请求就能在应用代码运行之前触发它，默认设置下已经演示了完整的远程代码执行；PHP-FPM 环境也通过应用层代码路径确认了同样的结果。

另一个，CVE-2026-109619，出在过期全局状态上，同样是远程代码执行。一个致命错误如果在错误的时点发生，内部状态会指向属于上一个请求的内存。同一个 worker 处理的下一个请求，就可能用上那段已经被释放的内存。use-after-free 和 worker 崩溃都已确认，报告者在跑真实应用的 Apache mod_php 环境上演示了 RCE。

规模这件事，TechCrunch 引 w3techs 的统计：PHP 驱动约 70% 的网站，有说法称超过 3300 万个。自 PHP 5（2004 年发布）以来的所有版本都被波及，而 8.1 及更早版本已无官方支持。NSA 的网络安全部门在 10 月 21 日发了警告，建议是：无法立即打补丁的网站，直接从网上摘下来。

WordPress 团队专门发了声明：漏洞不是 WordPress 特有的，但跑 WordPress 的站点必须修补服务器，并且要和托管商协作。Steam 商店在 10 月 21 日也出现了宕机，Reddit 上一个 13774 赞的帖子把它归因于 PHP 抢修潮，Steam 官方没有确认这个因果，我把「seemingly」原样保留。

洞不是 AI 发现的，2024 年就知道了

这事得从 2024 年说起。按官方博客的叙述，OOM 问题的最初迹象就出现在那一年。那一年 PHP Foundation 组织了 PHP 多年来的第一次外部安全审计（Sovereign Tech Agency 出资，OSTIF 协调，Quarkslab 执行），修复 Quarkslab 报告的某个问题时，一位基金会雇的内核开发者撞见了 CVE-2026-109618 背后的 OOM 问题的最初迹象。

2024 年，就有人理论化了这个问题可能被利用，但没人找到具体的攻击向量。加上当时其他有明确影响的漏洞更多，这件事就沉下去了。

修复为什么拖了两年？官方博客有一段罕见的坦诚：安全团队拿出过好几种修复方案，每一种都有代价：破坏向后兼容、引入新的拒绝服务风险、或者要求大量第三方扩展配合改动。安全团队按共识决策，谁也说服不了谁，怕选错方案带来反弹。再叠加两个现实：当时没有已知的 RCE 路径（没有实证的漏洞，优先级天然上不去），以及真正理解引擎深处的核心开发者极少且各有各的任务。官方的原话是，这个拖延是一个结构性失败，既怪决策流程，也怪资源不足。

换句话说：漏洞在那里，理论上的危险在那里，但「这东西真的能被打」这件事，两年来一直停留在纸面上。

AI 补上的那一段：从理论到实证只用了两周

转机出现在今年夏天。PHP Foundation 把 PHP 项目塞进了 OpenAI 的 Patch the Planet 计划，一个专门找开源软件安全缺陷的项目。安全公司 Calif 从 7 月 30 日开始审计 PHP。

真正的转折集中在 48 小时里。

8 月 11 日，Calif 的研究员 Ryan A 报告了一个无条件远程代码执行，根因与 2024 年发现的 OOM 问题相同。同一天，OpenAI 独立报告了同一个根因。8 月 24 日，Wiz 追加了更多攻击向量。9 月 18 日，OpenAI 又补充了新的向量。Trail of Bits 也在同期审计 PHP。

从 8 月 11 日起，修复这个洞成为 PHP Foundation 全体安全人员的最高优先级，周末和昼夜轮转都上了。官方说，没有基金会的资金支持，不可能让多个人全职扑在这一个问题上。

Calif 用的是 GPT-5.6 Sol，在 OpenAI 的 Patch the Planet 计划框架下工作。Wiz 用的是自家 Wiz Atlas 安全智能体，配合 Google 的 Gemini 4 Argon 和 GPT-5.6 Sol。按 Wiz 的说法，Gemini 4 Argon 在找漏洞、开发 exploit、构建攻击检测、验证补丁这四件事上都用上了。

值得单独说的是 PHP Foundation 自己的用法。这家基金会今年 5 月设立了「生态系统安全团队」，还设了一个职位叫 AI Security Engineer in Residence（驻场 AI 安全工程师）；今年早些时候和 Alpha-Omega 合作，用 Anthropic 的 Claude Mythos 扫描过 PHP 代码库，之后又加了 OpenAI 的 Daybreak Red 来验证报告和 exploit。自 7 月 1 日以来 PHP 安全团队发布了 15 个 CVE，同时处理掉 100 多份无效、重复或不可复现的报告。AI 负责验证和归类，官方强调每一个判断和每一个补丁都是人做的。

然后披露流程失控了

如果故事到这里结束，这是一次教科书式的负责任披露。它没有。

10 月 20 日 15:00 UTC，协调披露目标日期前两天，两个 CVE 编号开始在网上流传，带着错误的发布时间和一个错误的 CVSS 评分 10.0（实际是 9.2）。技术细节没有泄露，但 PHP 项目被迫在 19:30 UTC 抢先发了预公告，并把发布日期从 10 月 22 日提前到 10 月 21 日 14:00 UTC。

10 月 20 日 20:00 UTC 前后，参与报告的安全公司 Calif 误发了一段视频：他们的 PoC 打穿多个目标的演示，还带出了一些有限的额外细节。视频删了，但副本已经开始在社交媒体上流传。官方承认，这段视频加速了各类 PoC 的出现。

协调披露的窗口，从 48 小时缩到了不到一天。

10 月 21 日 07:41 UTC，协调发布前六个多小时，云服务商 Chainguard 单方面打破了 embargo，公开发布了包含修复的镜像。其他发行商提前拿到补丁，本来是为了在漏洞公开的那一刻用户就能更新；现在，攻击者可以对着二进制补丁研究修了什么，而其他所有 PHP 用户还在等官方发布。

PHP Foundation 把这三连击都写进了官方博客，用词不算克制：「这无视了多方数周的协调披露工作」。

截至正式发布时，官方监控到的 PoC 都不是功能完整的 exploit。但所有人都清楚窗口有多窄。

AI 同时给两边加了杠杆

Wiz 在博客里写了一段被 TechCrunch 和 The Decoder 反复引用的话，我认为它是整件事的技术结论：

With AI this is no longer a barrier. LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts.

（有了 AI，这不再是障碍。LLM 可以帮攻击者把 exploit 适配到不同的 PHP 版本、配置和内存布局。）

在 AI 之前，一个 exploit 只对某个特定的 PHP 安装有效，要适配到别的版本和配置，需要大量的手工逆向和调试。这种工程成本，就是那两个洞沉睡了多年的原因：大家都看得见它，但打穿它太费劲，费劲到不值得。

LLM 把这段适配工作变成了对话。Wiz 的结论有两半：曾经「看起来不可能被利用」的漏洞成为可行目标；跨部署环境规模化攻击的门槛被拉低了一大截。

TechCrunch 的总结比我的更干净：这是一个因为 AI 才被发现和预防，也只因 AI 才成为高风险的安全问题。

同一句话的两面，落在同一批人身上。防御侧，PHP Foundation 现在有驻场 AI 安全工程师，用 Claude 扫代码库、用 OpenAI 的工具验证报告，两周内把两年的僵局盘活了；攻击侧，任何人拿着同样的模型，对着泄露的 CVE 编号和误发的 PoC 视频，也能把适配工作跑起来。OpenAI 自己的预期是，这类规模的发现「将在未来几个月急剧增加」。

修补协调本身也成了一次 AI 协作的展示：The Decoder 报道，整个修复在两个月里分五个阶段协调，参与方包括 PHP 开发者、Wiz、Cloudflare，以及包括 CISA 和白宫在内的美国机构。OpenAI 想把这套流程包装成一个可复用的框架，给未来 AI 驱动的安全发现用。

OpenAI 还放了一个自查工具在 GitHub（openai/php2shell-checker），服务器运维可以查自己的 PHP 版本是否在受影响之列。

谁该更新，怎么更新

实操层面只有几条：

当前支持线直接升级：8.5.12、8.4.27、8.3.36、8.2.35 已发布，按 php.net 公告操作。
8.1 及更早版本没有官方补丁。还在跑这些版本的服务器，要么立刻迁移，要么认真考虑 NSA 的建议：下线。
mod_php 环境风险最高。两个洞的完整 RCE 演示都在 Apache mod_php 下完成；PHP-FPM 也确认了经应用层路径的利用，但 mod_php 是默认设置即可打穿的那种。
WordPress 站点：WordPress 官方声明漏洞不是它的问题，但站点照样需要升级服务器上的 PHP，并且和托管商确认。
用 OpenAI 的 php2shell-checker 自查一遍。

还有一个容易忽略的动作：如果你的基础设施用的是 Chainguard 10 月 21 日 07:41 UTC 之后构建的镜像，你已经拿到了修复；但如果你依赖其他发行商，注意它们的打包节奏可能落后官方发布几个小时到几天，这段时间窗口就是全部风险所在。

写在最后

这个事件最值得记的，我觉得是三个时间尺度被压到了同一周里。CVE 编号本身反而是最不重要的部分。

漏洞的潜伏以「年」计：2024 年审计发现苗头，决策流程和资源短缺让修复停了两年。AI 介入以「周」计：7 月 30 日开始审计，8 月 11 日无条件 RCE 实证落地。至于披露，它是按小时崩的：CVE 编号提前两天泄露，PoC 视频当晚流传，Chainguard 提前六小时打破封印。

官方博客里有一句话，我觉得比任何总结都准确。他们在承认修复拖延时写道，这是一个结构性失败。但同样这批人，在 AI 把问题从「纸面风险」变成「现实威胁」之后，用两周时间完成了过去两年做不到的事。

AI 没有制造这个漏洞，也没有修好它。它只是把所有人的表都拨快了。

接下来的观察指标有三个：第一，有没有功能性 exploit 在野出现（截至官方发布时尚无，但 PoC 在加速）；第二，8.1 及更早 EOL 版本的长尾站点要多久才能迁完，这部分站点没有补丁可用，是最大的存量风险；第三，OpenAI 那个「AI 驱动安全发现的可复用框架」会不会被别的开源项目采用。如果第二个指标恶化，NSA 那句「下线」的建议，可能会从极端选项变成常规操作。

参考来源

哪些内容尚未独立验证：「自 PHP 5（2004 年）起所有版本受影响」是 TechCrunch 的表述，Wiz 官方措辞是「追溯到十年以上」，PHP Foundation 公告未给具体年限；Steam 商店宕机与 PHP 抢修的因果关联来自 Reddit 社区归因（原帖用的是 seemingly），Steam 官方未确认；「超过 3300 万个网站」是 Medium 文章的说法，原始统计口径未查；NSA 警告经 TechCrunch 转引，我未直接核对 NSACyber 原帖全文；OpenAI 与 Wiz 博客为二手抓取核对，其中 Gemini 4 Argon 在四个环节的具体使用方式只有 Wiz 单方表述；修复协调「五阶段、白宫参与」出自 The Decoder，未见白宫方确认；Chainguard 破坏 embargo 的动机与其镜像的实际影响范围，以 PHP Foundation 单方叙述为准。本文对「AI 降低利用门槛」的判断引自 Wiz 与 TechCrunch 的分析，非本人独立评估。

漏洞分析 on 奇诺分享 | 重在分享