PHP 发布紧急安全更新，修复高危远程代码执行漏洞
2026 年 10 月 21 日，PHP 项目正式发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 版本。此次更新旨在修复两个严重的安全漏洞，这些漏洞允许未经认证的攻击者在特定条件下于运行 PHP 的服务器上执行任意代码。对于所有使用 PHP 环境的用户而言，立即升级至上述最新版本是必要的安全措施。
本次披露涉及两个核心 CVE：
- CVE-2026-109618 / GHSA-w8hw-w9fx-j79w：通过内存溢出（OOM）导致的远程代码执行（RCE）。当请求恰好在触发 PHP 内存限制的时刻到达时，可能导致内部数据部分初始化并被误判为有效，进而破坏内存结构。在 Apache 配合 mod_php 的环境下，未经认证的请求可在应用程序代码执行前触发此机制，默认设置下已证实可实现完整的远程代码执行；在 PHP-FPM 环境下，则通过应用级代码路径确认了 RCE 风险。
- CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp：通过陈旧状态导致的远程代码执行。致命错误可能导致内部指针指向之前请求释放的内存区域。若同一工作进程处理后续请求，可能利用已释放的内存。该漏洞已被证实存在 Use-After-Free 问题并导致工作进程崩溃，且在 Apache 上的 mod_php 环境中展示了针对真实应用程序的远程代码执行能力。
由于内存管理和错误处理贯穿几乎所有 PHP 请求流程，这两个位于核心位置的漏洞具有极高的危险性。修复此类问题面临巨大挑战，需在保证向后兼容性、维持性能以及避免对庞大的第三方扩展生态系统造成破坏之间取得平衡。
外部审计与开发流程优化
PHP 基金会指出，过去两年间其安全处理机制发生了显著变化。2024 年，在主权技术机构资助下，PHP 通过 OSTIF 委托 Quarkslab 进行了多年来的首次外部安全审计。正是在修复 Quarkslab 报告的问题过程中，签约的核心开发人员发现了 CVE-2026-109618 背后 OOM 问题的早期迹象。尽管当时理论化了潜在利用途径，但由于缺乏具体的攻击载体且其他显性影响掩盖了担忧，未引起即时警报。
为解决 OOM 问题，PHP 安全团队曾探索多种方案，但每种方案均伴随权衡：包括破坏向后兼容性、引入新的拒绝服务风险或要求修改大量第三方扩展。受限于共识决策机制及资源不足，修复工作在数月内多次停滞与重启。目前，安全团队已开始调整流程，转向多数决机制以加速决策。
构建可持续的专业安全体系
近期，PHP 安全工作的组织架构进行了重大调整。2026 年 5 月，PHP 基金会成立生态系统安全团队，与 PHP 安全团队协同进行分类、协调和强化工作。沃尔克·杜什（Volker Dusch）作为人工智能安全工程师加入基金会，改善了双方沟通；亚历山大·达布瓦斯（Alexandre Daubois）于 7 月加入，协助处理安全报告；丹尼尔·谢尔泽（Daniel Schierzer）于 9 月加入，负责硬化工作。
在工具层面，今年早些时候，PHP 基金会联合 Alpha-Omega 使用 Anthropic 的 Claude Mythos 扫描 PHP 代码库。此后又引入了 OpenAI 的 Daybreak Red 用于验证报告和漏洞。此外，PHP 项目被纳入“修补地球”计划，Calif 安全公司于 2026 年 7 月 30 日启动审计，并于 8 月 11 日由研究员 Ryan A 报告了无条件远程代码执行漏洞。同日，OpenAI 独立报告了相同根源的问题。Trail of Bits 也在持续进行审计。自 8 月 11 日起，解决该问题成为 PHP 基金会安全工作团队的首要任务，依靠基金会资助的多名全职人员及周末/24小时轮班工作，最终实现了跨方协调。
随着 AI 辅助研究的普及，PHP 安全团队收到的报告数量激增。自 7 月 1 日以来，团队已发布 15 份 CVE 并处理超过 100 份报告。AI 工具在验证报告和识别共同根源方面发挥了重要作用。
披露过程中的泄露与挑战
本次漏洞的协调披露过程遭遇波折。原定发布日期前两天，两个 CVE ID 开始在论坛和社交媒体流传，且 CVSS 评分被错误标记为 10.0（实际为 9.2），但未泄露技术细节。为此，PHP 项目提前发布预告，并将发布时间从 10 月 22 日 14:00 UTC 提前至 10 月 21 日 14:00 UTC，以便分销商打包修复。
然而，在加州时间 20:00 左右，一家安全公司错误发布了一段展示多目标概念证明的视频，泄露了部分有限细节，加速了 PoC 的开发。约 10 月 20 日 23:00 UTC，向关键基础设施提供商提供的缓解建议也可能发生泄露。尽管 PHP 安全团队密切监控出现的 PoC，但在公开披露时尚未发现功能性漏洞。
10 月 21 日 07:41，即协调发布前六个多小时，Chainguard 单方面打破禁运，发布了包含修复的镜像。这一行为使得攻击者可以二进制形式研究补丁，而其他用户仍在等待官方发布，忽视了多方数周的努力。
前景展望与呼吁支持
PHP 基金会表示，此次发布体现了安全处理能力的进步。一旦明确 OOM 问题的全部影响，团队迅速将补丁分发给发行版和 LTS 供应商，确保用户能快速更新。未来，基金会承诺将加快复杂修复方案的决策速度，并优先确保类似漏洞得到更快解决。
PHP 支撑着政府服务、电商、银行、媒体网站及企业软件等关键领域，但其安全工作仍依赖少数基金会资助的开发人员和志愿者。虽然自动化工具能加速漏洞发现，但决定引擎长期设计、权衡兼容性并审查补丁仍需具备深厚代码库知识的资深工程师。
PHP 基金会的核心任务是增加深入理解代码库的工程人员数量并为安全团队提供资源。这依赖于依赖 PHP 的组织提供资金：
- 基于 PHP 开发产品和服务的公司应根据依赖程度赞助基金会。
- 为数百万用户提供 PHP 的托管提供商、云平台和分发商。
- 使用 PHP 服务的政府和公共机构。德国主权技术机构对 2024 年审计的资助证明了公共投资的价值。
赞助 PHP 基金会是确保结构性安全问题在演变为紧急情况前得到可持续解决的最直接方式。组织可通过 thephp.foundation 成为赞助商，如需讨论更大承诺可联系基金会。
