PHP 发布 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两项 RCE 漏洞

PHP 项目今天早些时候发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。这些版本修复了两个严重漏洞；在特定条件下，未经身份验证的攻击者可以在运行 PHP 的服务器上执行代码。如果你使用 PHP，必须立即更新。php.net 上的公告包含有关这些漏洞、攻击向量以及如何更新不同系统的技术详情和说明，并提供相关参考。

本文不是讲如何更新，而是讲这些漏洞是如何被发现和修复的、过去两年 PHP 安全处理方式发生了哪些变化，以及我们需要依赖 PHP 的组织提供什么支持，才能让 PHP 的安全工作持续进行。

CVE-2026-109618 / GHSA-w8hw-w9fx-j79w：通过 OOM 内存损坏实现 RCE（内存耗尽）：如果请求恰好在不恰当的时刻达到 PHP 的 memory_limit，PHP 可能会留下部分初始化的内部数据，并随后将其视为有效数据，从而导致内存损坏。在使用 mod_php 的 Apache 上，未经身份验证的请求可以在任何应用代码运行之前触发此问题，并且已证明在默认设置下可以实现完整的远程代码执行。也已确认，可以通过应用层面的代码路径在 PHP-FPM 上实现远程代码执行。
CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp：通过陈旧状态实现 RCE：如果致命错误发生在不恰当的时刻，内部状态可能会指向属于上一个请求的内存。随后由同一工作进程处理的请求就可能使用那块已释放的内存。研究人员确认了释放后使用漏洞和工作进程崩溃，报告者还针对一个运行于使用 mod_php 的 Apache 上的真实应用演示了远程代码执行。

这两个问题都位于 PHP 中几乎每个请求都会触及的部分：内存管理和错误处理。它们在 PHP 中所处的核心位置使这两个漏洞都具有严重危害，也使其修复非常困难；如果不破坏兼容性、损害性能或迫使庞大的第三方扩展生态系统进行更改，就很难完成修复。

首次外部审计与加强安全关注

2024 年，PHP 进行了多年来首次外部安全审计。PHP Foundation 从 Sovereign Tech Agency 获得资金，通过 OSTIF组织了此次审计，审计工作由 Quarkslab完成。在修复 Quarkslab 报告的其中一个问题时，一名受 PHP Foundation 聘用的 PHP 核心开发者发现了 CVE-2026-109618 背后的 OOM 问题的最初迹象。2024 年曾有人从理论层面推演出一种利用 OOM 问题的可能方法，但并未找到具体的攻击向量，其他影响明确的具体问题掩盖了这些担忧。

为了解决 OOM 问题，PHP 安全团队提出了几种相互竞争的方案，但每种方案都有自己的权衡：破坏向后兼容性、引入新的拒绝服务风险，或者要求更改许多第三方扩展——而协调这些更改似乎是不可能的。PHP 安全团队按照共识机制运作，难以在这些方案中做出选择，并担心发布错误方案的后果。再加上缺乏已知的远程代码执行路径，以及掌握引擎深入知识的少数核心开发人员承担着多项职责，这一决策过程导致修复工作停滞不前，在长达数月的时间里反复重启。我们不会避讳这一点：这次延迟是一次结构性失败，既源于安全团队的决策流程，也源于其资源的匮乏。安全团队自此开始调整其流程，相关工作仍在继续，以便能够通过多数决做出决策，并鼓励各方寻求折中方案。

构建可持续的专业安全组织

在过去的几个月里，PHP 安全工作的组织方式发生了重大变化。2026 年 5 月，PHP 基金会成立了生态系统安全团队，与 PHP 安全团队协同开展分类、协调和加固工作。Volker Dusch 作为 PHP 基金会的驻场 AI 安全工程师，极大地改善了 PHP 安全团队与基金会之间的沟通协作。Alexandre Daubois 于 7 月加入了PHP 基金会，协助 PHP 安全团队对安全报告进行分类、处理和修复，Daniel Scherzer 则于 9 月加入，负责加固相关工作。

今年早些时候，我们与 Alpha-Omega 合作，使用 Anthropic 的 Claude Mythos 对 PHP 进行了扫描。但在 Mythos 扫描之后，我们又增加了其他工具，包括用于验证报告和漏洞利用的 OpenAI Daybreak Red，以及与我们在 PHP 所支持的每个平台上的 CI 相匹配的清理器构建和复现环境。

PHP 基金会将 PHP 项目带入了 Patch the Planet 项目，作为该项目的一部分，安全公司 Calif 于 2026 年 7 月 30 日开始对 PHP 进行审计。8 月 11 日，Calif 的研究员 Ryan A 报告了一个与我们在 2024 年发现的 OOM 问题根本原因相同的无条件远程代码执行漏洞。OpenAI 在同一天独立报告了相同的根本原因，随后 OpenAI 于 9 月 18 日报告了更多攻击向量，Wiz 也于 8 月 24 日报告了相关向量。最近，Trail of Bits 也开始对 PHP 进行审计。Calif、OpenAI 和 Wiz 的报告让我们清楚地认识到了 OOM 问题的全部影响，自 8 月 11 日起，修复该问题成为 PHP 基金会所有从事安全工作团队的首要任务。如果没有基金会的资助，就不可能让多人全职投入此问题，最终也就无法在周末乃至昼夜不停地进行工作，以与相关各方进行协调和沟通。

AI 辅助研究的增长也意味着 PHP 安全团队收到的报告远多于以前。正如 Alexandre Daubois 上周在PHP 安全团队如何处理你的报告一文中所述，该团队自 July 1st 以来已经发布了 15 个 CVE，并处理了 100 多份最终被认定为无效、重复或无法复现的报告。AI 帮助团队验证报告，并将根因相同的报告归为一组，但每项判断都由人作出，每个补丁也都由人处理。

泄露与披露受阻

这些漏洞的协调披露工作原本进展顺利，直到预定发布日期前 2 天。

October 20th 星期二 UTC 15:00 左右，两个 CVE ID 开始在在线论坛和社交媒体上流传。相关消息附带了错误的发布时间和错误的 CVSS 评分 10.0（实际评分为 9.2）。没有泄露任何技术细节。作为回应，PHP 项目提前了预公告，并在19:30 UTC 发布。项目还把发布时间从 October 22nd, 14:00 UTC 提前到了 October 21st, 14:00 UTC。当时发行商仍在打包修复版本，立即发布会让许多用户无法便捷地完成更新。将发布时间提前一天，是在迅速采取行动、给大家留出准备时间，以及确保漏洞披露时所有人都有简便的升级路径之间作出的最佳折中。

由于漏洞泄露及约 20:00 UTC 发布的预公告，Calif——报告这些漏洞的安全公司之一——不慎发布了一段视频。视频展示了他们的概念验证代码如何在多个目标上运行，并披露了少量额外但有限的漏洞细节。该公司删除视频后不久，其副本便开始在社交媒体上流传。这段视频促使各种 PoC（漏洞利用概念验证）加速开发，随后又在 October 21st 加剧了相关信息的传播。

我们于 Oct 20th 23:00 UTC 左右开始向少数关键基础设施提供商提供的缓解措施建议，也可能已经泄露。泄露发生后，PHP 安全团队密切监测并检查了新出现的 PoC，但在发布／公开披露时尚未发现任何可实际利用的漏洞利用程序。

October 21st 07:41 UTC，在协调发布前超过六小时，Chainguard 单方面打破了禁发约定，发布了包含该修复的构建镜像。与其他发行商一样，Chainguard 提前收到了补丁，以便其用户在漏洞披露后能够立即更新。此时，任何攻击者都可以研究二进制形式的修复，而其他所有 PHP 用户仍在等待发布。这无视了各方为协调披露投入的数周工作。

谨慎乐观的展望

今天的发布体现了我们正在改善 PHP 安全处理方式方面取得的进展。自八月 fully 了解 OOM 问题的全部影响后，安全团队、基金会和发布经理便为所有受支持分支交付了针对这一根深蒂固问题的修复，各发行版和 LTS 供应商也提前收到了补丁，以便其用户能够快速更新。

我们相信，对于修复方案卡在艰难取舍上的严重漏洞，如今会更快地传达给 PHP Foundation 领导层，因为我们正在调整流程，让领导层能够协助推动局面并及时解决。我们目前正优先采取措施，确保今后报告的那些同样需要复杂修复的漏洞能够更快得到解决。PHP Foundation 和 PHP 安全团队在过去几周收获良多，并将努力将这些经验转化为可持续、可重复的流程。

我们需要你提供什么

PHP 支撑着网络的很大一部分，包括政府服务、在线商店、银行、媒体网站，以及企业每天依赖的大量软件。然而，针对 PHP 本身的安全工作仍依赖于一小群由基金会资助的开发者，以及少量志愿者的帮助。

如今，工具发现漏洞的速度比以往任何时候都快，对防守方和攻击方而言皆然，而报告数量还会持续增长。工具无法做到的是：为引擎中的长期设计决策确定正确的修复方案、权衡兼容性取舍并审查补丁。作出这些决定需要熟悉整个 PHP 代码库的经验丰富的工程师，而如今这样的人太少。

PHP Foundation 的一项核心使命，是扩大深度了解 PHP 代码库的工程师规模，并为安全团队提供其所需资源。只有依赖 PHP 的人提供资金，我们才能实现这一目标：

在 PHP 上构建产品和服务的公司：请以与您对 PHP 的依赖程度相匹配的水平赞助 PHP Foundation。
向数百万用户提供 PHP 的托管服务商、云平台和发行版。
服务基于 PHP 运行的政府和公共机构。德国 Sovereign Tech Agency 对 2024 年审计的资助展示了公共投资能够取得怎样的成果，而我们需要更多此类投资，而且要持续进行。

赞助 PHP Foundation 是确保 OOM 漏洞等结构性问题得到可持续解决的最直接方式，避免它们演变成紧急事件。请访问 thephp.foundation/sponsor 成为赞助方；如果您的组织希望讨论更大规模的承诺，请联系我们。

致谢

感谢 PHP 安全团队、志愿者和 PHP Foundation 承包商、发布经理，以及各发行版和 LTS 供应商中促成这些发布的软件包维护者。感谢 Calif，尤其是 Ryan A；感谢 Wiz、OpenAI Codex Security，尤其是 Amy Burnett，还有 OSTIF 和 Quarkslab，感谢他们开展研究并负责任地披露漏洞；感谢 Alpha-Omega、OpenAI 和 Anthropic 向团队提供其工具的使用权限，并为部分安全工作提供资金；感谢 Sovereign Tech Agency 为 2024 年审计提供资金；也感谢所有赞助方，是他们的支持使这项工作成为可能。