一国首相连夜在社交平台喊国民打补丁，对象还是一个脚本语言。这事发生在 10 月 21 日晚，高市早苗的推文浏览量冲到 5700 万以上，措辞是”大至急”：确认站点是否跑 PHP，当晚 23:00 日本时间发布的补丁尽快适用，来不及就打就先把站点停掉。开源语言的漏洞惊动到这个层级，安全史上不多见。
先把结论摆前面：漏洞是真的，两个 RCE，影响 PHP 5、6、7、8 全系；官方补丁只覆盖 PHP 8；GitHub 上那几千个 PoC 绝大多数跑不起来。严重和易利用是两码事。
补丁只发给还活着的分支
研究员 Florian Roth 点出的现实很硬：PHP 5 和 PHP 7 多年前就 EOL 了，没有官方修复，跑这些版本的机器只能裸奔。互联网上老系统存量不小，这部分人没有”打补丁”这个选项，只有迁移或下线。
这里有个常被忽略的细节：不是所有 PHP 8 都算”有补丁”。8.1 的安全支持在 2025 年 12 月 31 日已经终止，8.2 的安全支持窗口到 2026 年底，8.3 和 8.4 才是当前活跃分支。也就是说，一台跑 8.1 的机器虽然版本号看着体面，同样拿不到这次修复。升级前先确认目标版本仍在安全支持期内，别把”升到 8″当成终点。
一个 OOM 问题拖了两年
时间线拉出来才看得清这不是普通 0Day。
2024 年 PHP 做了多年来第一次外部安全审计，Sovereign Tech Agency 出资、OSTIF 组织、Quarkslab 执行。修报告问题的过程中，核心开发者摸到了 OOM（内存耗尽）的苗头，这就是后来 CVE-2026-109618 的根。修复卡住了：几个方案各有代价，要么破坏向后兼容，要么引入新的 DoS 面，要么得改一大批协调不动的第三方扩展。共识制团队选不下去，一拖两年。
2026 年 7 月 30 日，Calif 通过 Patch the Planet 项目开始审计 PHP。8 月 11 日，研究员 Ryan A 报出无条件 RCE，根因和 2024 年那个 OOM 是同一个；OpenAI 同日独立报了同一根因。之后报告接连涌入。7 月以来 PHP 收了 15 个 CVE，还处理了 100 多个无效、重复、不可复现的报告。AI 在这里演了双面角色：Daybreak Red、Claude Mythos 这类工具帮团队验证报告，AI 辅助研究又让报告数量爆炸。
10 月 20 日，两个 CVE ID 在论坛和社交平台流传，时间错、CVSS 也错——传的是 10.0，实际 9.2。PHP 项目被迫提前发预公告。Calif 随后误发一段 PoC 视频，展示漏洞对多个目标有效，视频删了，副本已经传开。
10 月 21 日，Chainguard 在协调发布前 6 小时单方面打破 embargo，放出含修复的镜像。攻击者可以从二进制里反推修复点，其他 PHP 用户还在等补丁。当天 14:00 UTC，PHP 发布紧急版本，8.2.35 等在列。当晚 20:55，首相发推。
难修在哪：每个请求都经过的路径
PHP 基金会事后复盘说得很清楚：两个漏洞都藏在内存管理和错误处理里，而这两块几乎每个请求都会碰到。难点不在定位，在修法——不能破坏兼容性、不能伤性能、不能逼大量第三方扩展跟着改。这也是为什么补丁拖到协调发布才实现。
别被几千个 PoC 吓住
Elias Taylor 写了篇 noexploit 的分析，观点值得抄下来：这确实是个 bug，也确实重要，但远没有 Log4Shell、Heartbleed 那种易利用程度。GitHub 上几千个 PoC，没一个能在原生 PHP 实例上跑通；漏洞公开 10 小时、半个软件圈盯着，仍然没有可用的 exploit。”5 年前人们会理解这一点，现在被 LLM 骗了，以为手里有 exploit，其实没有。”
对管理员来说，升级仍然是对的。对围观的人来说，严重不等于好打。
打完补丁怎么确认生效
升级不是终点，得验证。先看版本：php -v 确认 CLI 侧版本号，Web 侧用 phpinfo() 或 php -i | grep memory_limit 核对 SAPI 实际加载的版本，别出现 CLI 升了、FPM 还跑老版本的情况。
再验证错误处理路径是否正常。用 php -r 构造一个触发内存分配失败的短脚本，观察是否按预期抛错而非静默崩溃；这一步在打补丁前后各跑一次，行为差异就是最直接的判据。
线上观测看两个指标：502/500 是否出现异常突增，error_log 里 OOM 相关关键字是否还在刷。补丁生效后这类日志应明显收敛。如果升级后错误率反而上升，优先怀疑第三方扩展与新版 ABI 不匹配，回滚到旧版本并单独排查扩展，而不是硬扛。
不同部署形态，打法不一样
共享主机用户基本没有自主权，能做的只有确认主机商是否已升级，必要时临时下线站点——首相推文里”暂时停止网站”那条建议，对这类场景最实用。
容器化部署要盯基础镜像。官方镜像 tag 更新有滞后，php:8.2-fpm 这类浮动 tag 拉到的未必是最新补丁版，生产环境应锁定到具体补丁号，重新构建而不是重启容器。Chainguard 提前放镜像这件事本身也提醒：镜像来源的可信度要纳入评估。
静态编译或自行打包的发行版最麻烦，补丁得自己回移植。这类环境建议直接跳到 8.3/8.4 活跃分支，减少后续重复移植的成本。
收尾
把碎片拼起来：一个根因拖了两年的内存漏洞，被 AI 辅助的安全研究加速挖出，被 AI 生成的假 PoC 淹没真实风险，最后升级到一国首相连夜喊话。补丁该打，版本该升，但别把”严重”读成”马上会被打穿”。先确认你的分支还在支持期内，再谈升级。
ID:6759
