今天早些时候，PHP 项目（PHP project）发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两个严重漏洞：特定条件下，未经验证攻击者可在运行 PHP 的服务器上执行代码，需立即更新。这一篇转而关注其成因与修复，以及近两年 PHP 安全改进。首个漏洞 CVE-2026-109618 为 OOM 损坏型远程代码执行：请求在错误时刻达到 memorylimit 会留下部分初始化数据并损坏内存；在阿帕奇（Apache）与 modphp（mod_php）下，未经验证请求可在应用代码运行前触发远程代码执行。

今天早些时候，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 的 memorylimit，PHP 可能会留下部分初始化的内部数据，并在之后将其视为有效数据，从而损坏内存。在使用 modphp 的 Apache 上，未经身份认证的请求可以在任何应用代码运行前触发该问题，且已在默认设置下演示了完整的远程代码执行。通过应用级代码路径，PHP-FPM 上也确认了远程代码执行。
• CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp：通过残留状态实现 RCE：在错误的位置发生致命错误，可能会让内部状态指向属于前一个请求的内存。之后由同一 worker 处理的请求可能会使用这块已释放的内存。已确认会出现释放后使用（use-after-free）和 worker 崩溃，报告者还在运行 mod_php 的 Apache 上，针对一个真实应用演示了远程代码执行。

首次外部审计与安全关注度提升

2024 年，PHP 进行了多年来首次外部安全审计。PHP 基金会从 Sovereign Tech Agency 获得资金，通过 OSTIF 组织这次审计，并由 Quarkslab 执行。在修复 Quarkslab 报告的一个问题时，一名受 PHP 基金会聘用的 PHP 核心开发者发现了 CVE-2026-109618 背后 OOM 问题的最初迹象。2024 年，人们曾推测 OOM 问题存在潜在利用方式，但没有找到具体途径，而其他影响明确的现实问题掩盖了这些担忧。

为了修复 OOM 问题，PHP 安全团队提出了几种相互竞争的方案，但每一种都有代价：破坏向后兼容性、带来新的拒绝服务风险，或者要求大量第三方扩展做出修改——而后者似乎无法协调。安全团队以共识方式运作，难以在这些方案中做出选择，也担心发布错误选择的后果。再加上当时并不知道通往远程代码执行的路径，而具备引擎深入知识的少数核心开发者又身兼多项职责，这一决策过程导致修复工作停滞并在几个月里反复重启。我们不想掩饰：这次延迟是一次结构性失败，既源于安全团队的决策流程，也源于其资源不足。安全团队此后已开始改变流程，这项工作仍在继续，以便决策能通过多数票做出，并鼓励折中。

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

过去几个月里，PHP 安全工作的组织方式发生了很大变化。2026 年 5 月，PHP 基金会成立了生态系统安全团队，与 PHP 安全团队并肩处理分诊、协调和加固工作。Volker Dusch 作为 PHP 基金会驻场 AI 安全工程师的工作，显著改善了 PHP 安全团队与基金会之间的沟通与协作。Alexandre Daubois 于 7 月加入，帮助 PHP 安全团队分诊、处理和修复安全报告；Daniel Scherzer 于 9 月加入，承担加固工作。

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

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 安全团队如何处理你的报告》中所说，自 7 月 1 日以来，团队已发布 15 个 CVE，并处理了 100 多份最终被认定无效、重复或无法复现的报告。AI 帮助团队验证报告，并把具有相同根本原因的报告分组，但每一个判断和每一个补丁都由人做出和完成。

泄露与被打乱的披露

这些漏洞的协同披露在目标发布日前两天之前一直进展顺利。

10 月 20 日（周二）约 15:00 UTC，两个 CVE ID 开始在线上论坛和社交媒体流传。它们附带了错误的发布时间，以及错误的 CVSS 评分 10.0（实际评分为 9.2）。没有技术细节泄露。作为回应，PHP 项目将预先公告提前，并于 19:30 UTC 发布。它还将发布时间从 10 月 22 日 14:00 UTC 提前到 10 月 21 日 14:00 UTC。发行版当时仍在打包修复程序，因此立即发布会让许多用户没有便捷的更新方式。把发布提前一天，是在快速行动、给人们准备时间，以及确保在漏洞披露时所有人都有简单更新路径之间的最佳折中。

由于泄露和约 20:00 UTC 的预先公告，报告了这些问题的安全公司之一 Calif 误发布了一段视频。视频展示了他们的概念验证针对多个目标生效，并泄露了少量额外但有限的漏洞细节。被删除视频的副本很快在社交媒体上流传。这段视频加速了各种 PoC（漏洞利用概念验证）的开发，并在 10 月 21 日增加了传播。

我们在 10 月 20 日 23:00 UTC 左右开始向少数关键基础设施提供商提供的缓解建议，可能也泄露了。PHP 安全团队在泄露后密切监控并检查了出现的 PoC，但在发布/公开披露时没有发现任何可用漏洞利用。

10 月 21 日 07:41 UTC，在协同发布前六个多小时，Chainguard 单方面打破禁运，发布了包含修复的构建镜像。与其他发行版一样，Chainguard 提前收到了补丁，以便其用户能在漏洞披露的瞬间更新。现在，任何攻击者都可以在其他所有 PHP 用户仍在等待发布时，以二进制形式研究这个修复。这无视了许多相关方为协同披露所做的数周工作。

谨慎乐观的展望

今天的发布显示了我们在 PHP 安全处理方式上的进展。8 月一旦理解 OOM 问题的全部影响，安全团队、基金会和发布管理者就在所有受支持分支上交付了这个根深蒂固问题的修复；发行版和 LTS 供应商提前收到了补丁，以便其用户能快速更新。

我们相信，如果一个严重漏洞的修复卡在艰难的权衡上，如今它会更快到达 PHP 基金会领导层，因为我们正在改变流程，让领导层能帮助引导局势，及时解决。我们现在正优先采取措施，确保未来报告的需要类似复杂修复的漏洞能更快得到解决。PHP 基金会和 PHP 安全团队在过去几周学到了很多，并将努力把这些经验转化为持久、可重复的流程。

我们需要你们做什么

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

如今，工具发现漏洞的速度比以往任何时候都快，对防御者和攻击者都是如此，报告数量还会继续增长。工具做不到的是：为引擎中一个长期存在的设计决定选定正确的修复，权衡兼容性取舍，并审查补丁。做出这些决定需要了解整个 PHP 代码库的经验丰富的工程师，而今天这样的人太少了。

PHP 基金会的一项核心使命，是增加对 PHP 代码库有深入了解的工程师数量，并为安全团队提供所需资源。只有依靠那些依赖 PHP 的人提供资金，我们才能实现这个目标：

• 在 PHP 上构建产品和服务的公司：请按照你们对 PHP 的依赖程度，赞助 PHP 基金会。
• 向数百万用户交付 PHP 的托管服务商、云平台和发行版。
• 服务运行在 PHP 上的政府和公共机构。德国 Sovereign Tech Agency 对 2024 年审计的资助显示了公共投资能取得什么成果，我们需要更多这样的持续投资。

赞助 PHP 基金会是最直接的方式，能确保像 OOM 漏洞这样的结构性问题在演变成紧急事件之前，就以可持续的方式得到解决。请通过 thephp.foundation/sponsor 成为赞助者；如果贵组织希望探讨更大投入，请联系我们。

致谢

感谢 PHP 安全团队、志愿者以及 PHP 基金会的承包商，感谢发布管理者，以及发行版和 LTS 供应商的软件包维护者，是你们让这些发布成为可能。感谢 Calif，特别是 Ryan A，感谢 Wiz，感谢 OpenAI Codex Security，特别是 Amy Burnett，感谢 OSTIF 和 Quarkslab 的研究与负责任披露；感谢 Alpha-Omega、OpenAI 和 Anthropic 让团队使用他们的工具，并资助部分安全工作；感谢 Sovereign Tech Agency 资助 2024 年的审计；也感谢所有赞助者，你们的支持让这项工作成为可能。

讨论气氛混乱、互相指责，也夹杂对 PHP 安全的自嘲。分歧主轴是：协调披露被多方提前打破后，多数人批评 Chainguard 等抢跑行为破坏规则并追问泄露责任，少数人则认为提前公开修复反而能让用户自保，并把根本问题归到 PHP 安全团队的共识决策和 C 实现。

认为整起事件是多环节连环失误，协调披露几近失控

• 2024 年的相关问题尚未修补，随后 CVE 编号、错误的 CVSS 10.0 评分、修复镜像和营销视频又在预定发布日期前接连外泄，整个流程严重失灵。（高赞）
• 即便披露禁令已正式解除，两小时后 Docker 镜像仍不可用，说明发布执行连第一步都没做好。（少数人）
• 如果破坏披露禁令没有实质后果，这类抢跑不会是最后一次。（较多人） > 很多环节都出了问题：2024 年的问题没修，之后又有多方在预定发布日期前泄露信息。（@cubefox）

认为 Chainguard 单方面提前发布修复镜像不可原谅

• Chainguard 在原定协调发布前六个多小时就擅自公开含修复的构建镜像，攻击者可借二进制研究补丁，而其他 PHP 用户仍在苦等发布，这被指无视多方数周的协调披露努力。（高赞）
• 即使临近发布、场面混乱，也很难为这种单方面破禁令找到正当理由。（高赞） > 这几乎是对 Chainguard 的定论性指责，即便临近协调发布的混乱中，我也看不出有什么正当理由。（@ernubufiei）

认为 CVE 编号被提前贴出是误信无披露禁令的个人失误，发帖者已担责

• 提前在 HN 发布两个 CVE 编号的人自称联系人告知没有披露禁令，结果证明是谎言；他为此道歉并承担扰乱责任。（少数人） > 这部分是我做的，我为自己把它发到 HN 上负责，也很抱歉可能造成的干扰。（@petecooper）

批评安全公司 Calif 误判禁令已破并抢发营销视频

• Calif 作为报告方之一，看到泄露后竟理解为披露禁令已被打破，于是赶发营销视频，被嘲“本应更专业”。（少数人） > 最令人意外的是，Calif 看到泄露后以为披露禁令已被打破，然后赶着发营销视频，我本以为他们会更专业。（@dannyw）

认为协调披露反而让用户无法自保，提前公开修复是好事

• 在协调披露期间，普通用户拿不到补丁，只能被迫关站；若能提前获得修复镜像，就能直接更新保护自己，因此 Chainguard 破禁令“是好事”。（少数人） > 协调披露意味着人们无法保护自己，网站只能被迫关停，而不能简单地更新。（@charcircuit）

认为 PHP 安全团队的共识决策才是真正的症结

• PHP 安全团队靠共识在两个修复方案（含破坏性变更）间犹豫，害怕选错后果；真正的故事是决策机制失灵，应先发布一个修复，再用编译选项切换到另一个。（少数人） > 这才是真正的故事：应该先把其中一个破坏性修复发出去，再用一个编译选项切换到另一个修复。（@bombcar）

担忧 AI 辅助下漏洞很快会被做成可用攻击代码

• 对遗留系统而言，借助 AI 构造利用条件到底有多难是个现实疑问，有人想把它量化成 1 到 10 的难度分级。（少数人）
• 官方称泄露后出现的概念验证在发布时还不可用，但外界追问它们离可用攻击代码有多近，以及执着的攻击者能否靠大语言模型补完。（少数人） > 它们到底离可用有多近？一个执着的攻击者能否借助大语言模型搞出可用的漏洞利用代码？（@lol768）

认为 PHP 用 C 写是内存安全问题的根源，应改用 Rust 等语言

• 只要 PHP 仍以 C 实现，就会持续出现此类不安全内存问题；虽是老生常谈，但确实该用 Rust 或其他内存安全语言重写。（少数人） > 只要 PHP 还是 C 写的，它就不安全；应该改用 Rust 或其他内存安全语言重写。（@redox99）

对 PHP 安全生态的调侃已成社区情绪

• 流传的“PHP 安全指南”只有一句话“换点别的语言用”，折射出不少人对 PHP 安全生态的无奈与嘲讽。（少数人） > PHP 安全指南：换别的语言。全文完。（@miohtama）

有价值的补充

• 此前社区已有“PHP2Shell：AI 发现 PHP 关键远程代码执行漏洞”以及全球响应协调等相关帖，说明本次事件处于 AI 参与漏洞发现与多方协调披露的大背景中。（较多人）