PHP 两个高危 RCE 漏洞完成修复：内存边界问题为何拖了两年
导语 PHP 项目发布 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两个在特定条件下可被未认证攻击者利用的远程代码执行漏洞。问题分别位于内存不足后的对象状态和跨请求残留的全局状态，几乎每个请求都会经过相关路径。更值得关注的是，其中一个根因早在 2024 年审计后已露出迹象，却因兼容性、拒绝服务风险和资源不足长期没有形成可接受的修复方案。
PHP 两个高危 RCE 漏洞完成修复：内存边界问题为何拖了两年 · 配图 1 核心内容 第一个问题与内存上限触发时的清理有关。请求如果在极不凑巧的时刻碰到 memory_limit，PHP 可能留下只初始化了一部分的内部数据，后续却把它当成完整对象使用，最终造成内存破坏。研究者在 Apache 的 mod_php 默认配置下证明，攻击可在应用代码执行前触发，并实现远程代码执行；在 PHP-FPM 场景中，也确认可通过应用层路径触发。
第二个问题来自错误处理后的陈旧全局状态。一次致命错误可能让内部指针继续指向前一个请求已释放的内存；同一工作进程处理后续请求时，再次使用该地址就会形成释放后使用。报告者不仅复现了崩溃，还在真实应用与 mod_php 组合中演示了代码执行。
这类缺陷难修，不是因为补丁只有几行，而是因为它们位于引擎中心。一个方案可能破坏向后兼容，另一个可能引入新的拒绝服务机会，还有方案要求大量第三方扩展同时调整。PHP 安全团队此前依赖共识决策，面对多个都不理想的选项迟迟无法定案。基金会把这种延误直接称为结构性失败，而不是把责任推给单个开发者。
2026 年 8 月，多家研究团队分别给出同一根因的可执行攻击路径，风险从“理论可能”变成明确的远程代码执行，修复随即成为最高优先级。最终补丁覆盖全部受支持分支，并提前提供给发行版和长期支持厂商。披露过程后来又因 CVE 编号和演示视频提前流出而被迫加速，发布日期从 10 月 22 日提前到 21 日。
深度解读 事件显示，AI 辅助安全研究正在显著提高报告产量，但漏洞发现速度并不等于修复速度。PHP 团队自 7 月以来发布了 15 个 CVE，同时处理了一百多份无效、重复或无法复现的报告。工具可以聚类相同根因、验证利用条件，却无法替代熟悉整个引擎的人在性能、兼容性与安全性之间作决定。
编辑判断是，成熟开源基础设施的最大风险往往不是“没人发现漏洞”，而是少数核心维护者成为修复吞吐量的瓶颈。外部审计、自动分析和漏洞奖金都能增加输入，如果没有稳定资金、清晰决策权与可重复的发布流程，更多报告反而可能加重积压。
启示与展望 运行 PHP 的团队应立即升级到对应受支持分支的新版本，并确认 Web 服务器和 PHP 工作进程已实际重启。仅更新软件包但保留旧进程，补丁可能尚未进入运行中的内存。还应盘点非官方扩展和长期未升级的发行版，因为底层修复不代表外围组件自动兼容。
这次修复解决了两个具体漏洞，也推动 PHP 调整安全团队的决策机制、增加专职人员和复现环境。长期答案不是寄望下一次披露永不泄漏，而是让复杂修复更早升级、让补丁能快速打进各分支，并让依赖 PHP 获利的组织承担与其依赖程度相称的维护成本。