有人提前 71 天知道，你提前不到一天 (2026)

10 月 21 日 14:00 UTC，PHP 发布 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修掉两个不需要账号就能触发的远程代码执行漏洞，编号 CVE-2026-109618 与 CVE-2026-109619。同一天，Wiz、Calif、OpenAI、Cloudflare、Imperva、Fastly、Google Cloud 各自发出技术文，PHP 基金会的稿子把这次协调定性为「到目标发布日前两天都还顺利」的一次行动。1 2

这句话里真正值得读的是「前两天」。补丁是同时发的，提前量不是：有人比公众早 71 天知道，有人早 11 小时，有人早不到一天。这一期想弄清的就是这张分配表怎么来的，以及它为什么在最后一刻没守住。

漏洞在引擎里，不在你的应用里

这两个漏洞都在 PHP 解释器本身。一个出在内存耗尽的处理上：请求还没初始化完，内存就先耗尽，清理逻辑把半成品当成完整数据；另一个出在致命错误后的全局状态上：上一个请求留下的指针指向已经释放的内存，同一个 worker 接下个请求时还会用它。1

后果分两级。轻的一级是读内存：攻击者可以让 PHP 把 worker 内存里的内容编码进 PHPSESSID 响应 cookie 返回，里面可能有别的请求留下的密码、会话令牌和 API key。重的一级是执行代码：Wiz 在 WordPress、Drupal、Joomla 的最新容器镜像上做了预认证 RCE 演示，Calif 的清单还包含 MediaWiki、Roundcube、Magento、phpMyAdmin、Nextcloud、Laravel、Symfony 与 WHMCS。3 4

演示挑的是这几个应用，漏洞却不在应用里。两个团队都强调同一件事：应用代码写得再干净也没用，受影响的代码在 PHP 自己的请求启动与关闭路径上。按 W3Techs 的统计，PHP 被 69.3% 的「服务端语言可被识别的网站」使用。5 Wiz 在标题里写的是「70% 的网站」——两个分母不是一回事，前者限定在能识别出服务端语言的站点里。

二十二年，三次找到，两次没修

这个缺陷不是新出现的。Calif 的研究文把它往前追了二十二年：2004 年，Stefan Esser 公布了 PHP 第一个与 memory_limit 有关的远程漏洞，他没有公开利用代码；2020 年，bug #78876 报告了超长变量触发内存耗尽、临时文件没有清理；2024 年，OSTIF 与 Quarkslab 的审计又碰到同一处。4

2024 年那次没有修。Calif 写下的理由是：「可利用性未被证明，因此这个 bug 没有被修复。」PHP 基金会的说法略有不同：一位由基金会聘用、当时正在修 Quarkslab 报告问题的核心开发者，看到了 CVE-2026-109618 背后那个内存耗尽问题的「第一批迹象」。两种说法指向同一个事实——那一年他们知道这里有问题，也知道它大概有多深，但没有把它变成一次修补。2 4

今年 8 月 1 日，Calif 的 Ryan Austin 重走这条线，几天之内找到了第一个可用的中断点；8 月 11 日他报出第一处；8 月 14 日交出利用代码；8 月 15 日 PHP 确认代码「按预期工作」。从可复现到开始修补，用了四天。4

二十二年里真正的变量在这里：让事情卡住的不是危险程度，而是能不能把「可能被利用」变成「能复现」。AI 没有发明这个缺陷，它改的是这道证明题的价码。

两周里的三份报告

这次不是一个人的运气。8 月 11 日，Calif 报出第一处；同一天，OpenAI 独立报来同一个根因；9 月 18 日，OpenAI 又补来更多攻击向量；8 月 24 日，Wiz 报来它自己发现的那一组——Wiz 是 8 月 19 日才发现、8 月 20 日在 Drupal 上确认、8 月 21 日在 WordPress 上确认的。2 3

确认的钟点不一样。Calif 的报告四天就被确认；Wiz 的报告 8 月 24 日递上去，PHP 到 9 月 21 日才确认——那时修复工作已经进行了一个多月。Wiz 的通报里没有解释这段间隔，PHP 那边也没有。

三份公开文本对 AI 的位置写得并不一样。OpenAI 的稿子说，「Calif 用 GPT-5.6 Sol 找到了这个缺陷」。Wiz 说自己全程用了 Wiz Atlas、Gemini 4 Argon 与 GPT-5.6 Sol，其中 Argon「对发现、利用开发、攻击检测和补丁验证都有不可替代的贡献」。Calif 的写法最克制：「最初的漏洞发现没有使用特殊环境，也没有使用别人拿不到的模型。」3 4 6

还有一层背景值得放进来：PHP 基金会今年早些时候已经在 Alpha-Omega 的支持下，用 Anthropic 的 Claude Mythos 扫过一遍 PHP。这次的两个漏洞没有被那一遍扫出来。基金会现在的说法是，AI 帮团队验证报告、把同一根因的报告归组，「但每一次判断和每一个补丁都由人做」。2

所以，「前沿 AI 先于攻击者发现了这些漏洞」这句话，要看是谁在说。OpenAI 的原句带着限定：据其所知（to our knowledge）。三个发现方里，只有它这样写。

补丁沿一条链往下走

公开之后最先出现的一条事实，是补丁早就开始流动了。PHP 的公告写着：「Linux 发行版与 LTS 厂商提前收到了补丁，请检查你的供应商有没有更新包。」这句话没有给日期，也没有给名单，更没有人数的统计。1

下游的动作印证了这一点。Ubuntu 在公开发布后四十多分钟就挂出了覆盖 14.04 到 26.10 全部受支持发行版的修复包清单；Imperva 的博文写得更直接：「研究者在公开披露前把漏洞细节保密地交给了 Imperva，让 Imperva 能在公告之前验证防护、开始监控客户流量。」Cloudflare 说自己的 WAF 规则从 10 月初就在做，10 月 21 日 03:02 UTC 起对免费与付费用户默认生效，并自称「比公开披露早了约九小时」——这个说法与它自己给的时间戳之间有大约两小时的出入，没有解释。7 8 9

更早一格是「少数关键基础设施提供方」。PHP 基金会的原文是：他们从 10 月 20 日 23:00 UTC 前后开始向「少数关键基础设施提供方」提供缓解建议，而这些建议本身「也可能已经泄露」。2

把这几段放在一起，提前量就有了形状：维护者 71 天，发行版与 LTS 厂商「提前」但日期未公布，WAF 厂商 11 小时，少数关键设施 15 小时，网站所有者 18 小时。名单不在任何公告里，它由分发链的位置决定。

封条在公开前一天裂开

原定的公开时间是 10 月 22 日 14:00 UTC。Ubuntu 的博文把这件事说得最清楚：「由于一次公开泄露，披露日期被提前到了 10 月 21 日 14:00 UTC。」7

泄露是从 10 月 20 日下午开始的。PHP 基金会记下的顺序是：当天 15:00 UTC 前后，两个 CVE 编号开始在网上论坛与社交媒体流传，还带着一个错误的发布时间和一个错误的 10.0 分（实际是 9.2），「没有技术细节泄露」；PHP 项目于是把预告提前到 19:30 UTC 发出；大约 20:00，Calif 误发了一段视频；10 月 21 日 07:41 UTC，Chainguard 单方面解除禁运，发出了带修复的镜像，比协调发布早了六个多小时。2

社区的讨论比官方稿更早。Hacker News 上「Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming」在 10 月 20 日 15:20 UTC 发出，拿到 254 分；到 20:15 UTC，讨论已经转到 PHP 的预告上，那条帖子最终 1435 分、605 条评论——比 Wiz 的技术博文早了十七个小时。10 11

Cloudflare 的说法补上了另一半：「在漏洞于正式发布日前被泄露、并且我们观察到针对客户的攻击流量的同时，Cloudflare 成功为所有客户部署了多重缓解。」它还写，攻击者在改载荷试探绕过规则。Fastly 的措辞更直接：「有证据显示公开前就已经出现在野攻击，这些不是理论问题。」9 12

这就是「防御者的窗口」这句话的另一面。窗口不是被 AI 打开的，是被人守住的；这一次，它在最后一天被三件事先后推开。

OpenAI 那份稿子里，四件事要分开看

第一件，发现。「据其所知」四个字，是 OpenAI 自己给这句话加的限定。

第二件，10 亿美元。10 月 21 日的稿子写「我们已承诺 10 亿美元的补贴 Daybreak 使用权」。这句话不是新的：9 月 3 日的公告标题就叫《Daybreak for Frontline Defenders: $1B to protect essential services》，并且写明这是「补贴的使用权、培训、技术支持与合作」，计划在六个月内用完。6 13 14

第三件，政府协调。OpenAI 写自己「与伙伴一起」接触了美国政府多个部门，包括白宫的 Super Intelligence Force、国家网络总监办公室（ONCD）与 CISA（网络安全和基础设施安全局），以及国际伙伴。截至 10 月 21 日 15:56 UTC，这三家的公开页面里没有一条 PHP 相关的内容：CISA 的新闻 feed 最新一条是关于 SafePay 勒索软件的，安全公告列表首屏覆盖到 10 月 20 日，白宫三类发布面的最新条目停在 10 月 19 至 20 日。6 15 政府一侧当天单独发公告的是英国的国家网络安全中心（NCSC），它的措辞是「鼓励英国组织立即采取行动」。16

第四件，那份五阶段框架。它把一次披露拆成验证与修复上游、给受影响组织时间、与政府伙伴协调、准备跨产品更新、发布指引与支持部署五步；它明确说，谁需要提前知道，由维护者决定（maintainers decide whom to involve），标准是对方的防护角色、行动所需时间与处理敏感信息的能力。它还写了一句平常不会写进公告的话：每个参与者拿到的东西不同，从带入侵指标的日志，到更敏感的可运行利用代码。6

框架末尾向公众征求四个问题的意见，其中一个就是提前告知：谁需要提前得到警告，什么时候分批通知比一次性通知更多人更有效，覆盖面和泄露风险怎么权衡。这次事件本身，就是这个问题的一份现场材料。

还有一处容易被忽略的对照。Patch the Planet 6 月 22 日启动时，首批九个项目里没有 PHP——是 cURL、NATS Server、pyca/cryptography、Sigstore、aiohttp、Go、freenginx、Python 与 python.org。PHP 是 7 月 30 日才被基金会拉进来的。17

今天能做什么

四个版本号是唯一完整的解法。PHP 在发布公告里写得很直白：「没有完整的缓解措施，升级是唯一安全的选择。」18

升不了的地方有三处边界。

一是分支。8.1 及更早不再由官方更新；PHP 为 7.4、8.0、8.1 提供了源码级的最小 backport，但要自己编，或者等发行版回填。8.2 这条分支也会在 12 月 31 日停止维护。1

二是临时措施。关掉会话上传进度，只封住已经确认的那条路径，公告的原话是「挡不住其他变体」；把 memory_limit 设成 -1，只是去掉了可控的那次失败，「底层的分配失败仍然可能走到有漏洞的路径」。1

三是部署形态。Red Hat 给 CVE-2026-109618 的自评是「Important」、CVSS v3 8.1，理由是企业版 Linux 默认用 PHP-FPM 而不是 mod_php，FPM 在早期初始化失败时会直接退出 worker，远程利用在实践上更难；它同时写着，缓解「要么没有，要么不满足 Red Hat 的产品安全标准」。19

按 W3Techs 10 月 21 日的版本分布，跑 PHP 的站点里约 48.5% 还在 8.1 或更早的分支上。对这些站点，「今天有没有补丁」的答案不在 PHP 官网，而在它背后的发行版、面板或商业支持商手里。