CVE-2026-109619：通过陈旧全局状态实现的 PHP 远程代码执行

出了什么问题：停在厂商公布的层次

PHP Foundation 称，致命错误若发生在错误的时点，可能使内部状态指向属于前一个请求的内存。同一工作进程上的后续请求随后可能使用这块已释放的内存。Foundation 称释放后使用和工作进程崩溃已得到确认，报告者还在一台运行于 Apache mod_php 的真实应用上演示了远程代码执行。英国 NCSC 的描述与 php.net 的句子一致：状态在底层内存释放后仍然存在，同一工作进程上的后续请求可能在初始化重置它之前使用它。

多伦多大学通告把默认开启的 session upload progress 列为一条已确认的路径。PHP 项目的临时指引称，设置 session.upload_progress.enabled=0 可以挡住已确认的 session 路径，但不能挡住其他变体。关闭这项设置是缓解，不是修复。我们不描述请求如何进入致命错误窗口。

mod_php 与 PHP-FPM

Expel 转述 PHP 称，PHP 在应用自身代码可被推入致命错误的情形下，针对 PHP-FPM 演示了这个 CVE。FPM 的暴露取决于应用和部署，PHP 仍然认为 FPM 安装有风险。mod_php 仍是 PHP 项目称为最高风险的配置，对这一对漏洞整体也是如此。加拿大网络安全中心重复了这一评估：mod_php 上已演示的利用允许未经身份验证的请求在应用层代码运行之前触发漏洞。

修复

没有单独的补丁。安装 10 月 21 日的版本并重启每一个工作进程。在 PHP 8.5 上，项目还把 fatal_error_backtraces=0 列为临时措施，且只挡住已确认的 fatal backtrace 路径。按照 php.net 公告，用 error_reporting、display_errors 或 @ 运算符把诊断藏起来并没有帮助。Google Cloud 把这一对漏洞的受影响版本写为 5.4 至 8.5.11；这与 PHP 实际发布修复的分支如何并列，见版本页。