PHP 8.5.12 等四个版本修复两个 RCE：内存损坏与陈旧全局状态，以及一次被提前的披露
PHP 项目发布了 8.5.12、8.4.27、8.3.36 和 8.2.35，修掉两个在特定条件下可被未认证攻击者利用的远程代码执行漏洞。官方公告在 php.net 上，包含技术细节、攻击向量和各系统的升级方式；变更日志见 PHP ChangeLog。
先做什么
- 查版本：
php -v，对照 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 四条分支的最低修复版本。 - 按发行版渠道升级，不要手工替换二进制；容器镜像直接拉取对应 tag 的新镜像后滚动重启。
- 优先级上，Apache + mod_php 的暴露面要先处理：这个组合下未认证请求可以在任何应用代码执行之前触发漏洞，默认配置即可复现完整 RCE。
两个漏洞
CVE-2026-109618 / GHSA-w8hw-w9fx-j79w：OOM 导致的内存损坏。 当请求正好在错误的时刻撞上 memory_limit，PHP 会把只初始化了一半的内部数据留在原地，之后又把它当成有效数据使用，进而破坏内存。在 Apache + mod_php 下，未认证请求在任何应用代码运行前就能触发，默认设置下已经演示出完整的远程代码执行。PHP-FPM 下也通过应用层代码路径确认了 RCE。
CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp：陈旧全局状态导致的 UAF。 致命错误发生在错误的时点，会让内部状态指向属于上一个请求的内存；同一 worker 处理的后续请求就会用到这块已释放内存。已确认 use-after-free 和 worker 崩溃，报告者还在一个跑在 Apache + mod_php 上的真实应用上演示了 RCE。
两个问题都落在几乎每个请求都会经过的部分：内存管理和错误处理。位置的核心性既是它们严重的原因，也是它们难以在不破坏兼容性、不拖累性能、不迫使大量第三方扩展改动的前提下修掉的原因。
从 2024 年审计到两次报告
2024 年 PHP 做了多年来的第一次外部安全审计。PHP 基金会从 Sovereign Tech Agency 拿到资金，通过 OSTIF 组织、由 Quarkslab 执行。在修 Quarkslab 报告的其中一个问题时，一位由基金会资助的 PHP 核心开发者发现了 CVE-2026-109618 背后 OOM 问题的最初迹象。2024 年当时已经推测出 OOM 问题可能存在利用方式，但没有找到具体向量，同时有其他影响明确的具体问题盖过了这些担忧。
为了修 OOM 问题，安全团队做了几套互相竞争的方案，每套都有各自的代价：破坏向后兼容、引入新的拒绝服务可能、或者要求大量第三方扩展改动而看起来根本无法协调。以共识方式运作的安全团队在这些方案之间难以取舍，也担心选错方向后发布的后果。加上当时没有已知的 RCE 路径，而具备引擎深层知识的核心开发者人数很少、又被其他职责占满，这个决策过程让修复工作在过去几个月里反复停滞、重启。这一点不需要粉饰：拖延是结构性失败，既来自安全团队的决策流程，也来自资源不足。安全团队此后已开始调整流程，改为多数表决、鼓励折中，这项工作还在继续。
安全组织的变化
过去几个月，PHP 安全工作的组织方式变化不小。2026 年 5 月，基金会成立了 Ecosystem Security Team，与 PHP 安全团队一起做分类、协调和加固。Volker Dusch 作为基金会的 AI Security Engineer in Residence，显著改善了安全团队与基金会之间的沟通协作。Alexandre Daubois 于 7 月加入基金会，协助安全团队做报告分类、处理和修复；Daniel Scherzer 于 9 月加入，负责加固工作。
今年早些时候，团队与 Alpha-Omega 合作，用 Anthropic 的 Claude Mythos 对 PHP 做了扫描。此后又加入了一批工具，包括用 OpenAI 的 Daybreak Red 验证报告和利用，以及覆盖 PHP 支持的所有平台、与 CI 一致的 sanitizer 构建和复现环境。
基金会把 PHP 项目带进了 Patch the Planet 计划，安全公司 Calif 于 2026 年 7 月 30 日开始对 PHP 做审计。8 月 11 日，Calif 的研究员 Ryan A 报告了一个无条件 RCE，根因与 2024 年发现的 OOM 问题相同。OpenAI 独立报告了同一根因，随后 OpenAI 在 9 月 18 日、Wiz 在 8 月 24 日又给出了更多攻击向量。再往后，Trail of Bits 也在审计 PHP。Calif、OpenAI 和 Wiz 的报告让 OOM 问题的完整影响变得清楚，从 8 月 11 日起，修复它成为基金会所有安全相关人员的最高优先级。没有基金会的资金，不可能有多人全职投入这个问题，并在后来连日带夜地协调和联络各方。
AI 辅助研究的增长也意味着安全团队收到的报告远多于从前。如 Alexandre Daubois 上周在上一篇中所述，团队自 7 月 1 日以来发布了 15 个 CVE，处理了 100 多份最终被判定为无效、重复或无法复现的报告。AI 帮助验证报告、把同根因的报告归类，但每个判断、每个补丁仍然由人来做。
泄露与被打乱的披露节奏
协调披露在目标发布日前两天之前都运转正常。
10 月 20 日星期二约 15:00 UTC，两个 CVE 编号开始在论坛和社交媒体上流传，附带错误的发布时间和错误的 10.0 CVSS 分数（实际是 9.2）。当时没有技术细节泄露。作为应对，PHP 项目把预公告提前到 19:30 UTC 发布，同时把发布日期从 10 月 22 日 14:00 UTC 提前到 10 月 21 日 14:00 UTC。各发行版当时还在打包修复，立刻发布会让很多用户没有便捷的升级路径；提前一天是在尽快行动、给人准备时间、保证披露时所有人都有简单升级方式三者之间的折中。
由于泄露和 20:00 UTC 左右的预公告，报告问题的安全公司之一 Calif 误发了一段视频，展示了他们的 PoC 对多个目标生效，并透露了少量额外细节。视频删除后副本很快在社交媒体上流传，也推动了各种 PoC 的加速开发，并在 10 月 21 日进一步扩散。团队从 10 月 20 日 23:00 UTC 左右开始向少数关键基础设施提供方给出的缓解建议，也可能一并泄露。安全团队在泄露后密切监控和检查了出现的 PoC，在发布/公开披露时点没有发现可用的利用。
10 月 21 日 07:41 UTC，比协调发布提前六个多小时，Chainguard 单方面打破禁令，发布了包含修复的构建镜像。与其他发行版一样，Chainguard 提前拿到了补丁，以便其用户能在漏洞公开的那一刻完成升级。结果是，在其他所有 PHP 用户还在等发布的时候，任何攻击者都可以直接研究二进制形式的修复。这无视了多方为协调披露投入的数周工作。
现状与缺口
这次发布体现了 PHP 安全处理方式上的进展：8 月理解 OOM 问题的完整影响之后，安全团队、基金会和发布经理在所有受支持分支上交付了修复，发行版和 LTS 厂商提前拿到补丁，用户能够快速升级。
现在可以更有把握地说，一个修复卡在艰难取舍上的严重漏洞，会更早地到达基金会管理层——流程正在调整，让管理层能介入并把局面推向及时解决。需要在同类复杂修复上提速的机制，也被列为后续优先事项。
PHP 承载了 Web 的很大一部分：政府服务、在线商店、银行、媒体站点，以及企业日常依赖的大量软件。但 PHP 自身的安全工作仍依赖一小批由基金会资助的开发者和少量志愿贡献。工具让发现 bug 的速度对攻防双方都前所未有地快，报告数量会继续增长。工具做不到的是：为引擎里一个由来已久的设计决策选定正确的修法、权衡兼容性代价、审阅补丁。这些判断需要了解整个 PHP 代码库的有经验工程师，而现在这样的人太少。基金会使命的核心部分，就是增加具备 PHP 代码库深层知识的工程师数量，并给安全团队提供所需资源。
原文：Today's PHP Security Release, and How We're Strengthening PHP Security
相关链接：