PHP 严重漏洞：从内存破坏到可验证的修复

这些漏洞改变了什么

漏洞位于 PHP 核心，处于 Laravel、Symfony、WordPress 等框架之下。应用依赖即使已全部更新，底层解释器仍可能存在漏洞。潜在后果是以 PHP 进程的权限执行远程代码；对文件、密钥和其他服务的影响范围，取决于环境中的权限与隔离边界。

修复版本于 2026 年 10 月 21 日发布。PHP 为两项漏洞给出的 CVSS 4.0 评分均为 9.2；NVD 对 CVE-2026-109618 记录的 CVSS 3.1 评分为 9.8。两者采用的评分版本与向量不同。公开概念验证代码的出现提高了修复紧迫性，但不能据此断定某个系统已被入侵，或所有环境均可被同样利用。

官方已修复版本

表格列出仍受官方支持的分支。发行版的补丁回移可能采用不同的软件包版本号，应核对供应商公告及软件包修订号。PHP 8.1 及更早版本已不在常规官方支持范围内；LTS 软件包和紧急源码回移补丁需要单独评估。

CVE-2026-109618：初始化中断后留下无效内存状态

内存不足（out-of-memory，OOM）的处理流程可能在请求内部结构尚未完全初始化时中断操作。随后的请求清理却可能将不完整状态当成有效状态使用。问题并非单纯“占用过多内存”，而是异常中断之后的清理过程不再安全。

在 mod_php 中，已演示在应用代码执行前实现远程代码执行。PHP-FPM 在启动失败时可能终止子进程，但应用执行期间的相关路径仍须评估。因此，登录页以及仅由框架执行的输入校验，都不足以构成完整防线。

CVE-2026-109619：内存已释放，引用仍存活

第二项漏洞跨越了请求边界。持久运行的工作进程保留了指向上一条请求内存的全局引用。如果在释放内存之前没有正确重置状态，后续操作就可能继续将其当成有效内存使用。这属于释放后使用（use-after-free）。

这一链条需要产生过期状态的操作，以及在正常初始化之前访问该状态的消费者；后一次请求必须由同一个工作进程处理。致命错误可能打断清理，会话、上传操作或早期诊断也可能参与相关路径。新的 HTTP 请求不一定意味着新的进程，更不意味着全局内存已经重新建立。

相同漏洞，不同暴露路径

如何判断实际暴露面

优先处理面向互联网的服务和 mod_php 环境，同时盘点 API、管理后台、上传功能、导入工具以及内嵌 PHP 的第三方产品。在 FPM 环境中，应结合进程池和应用流程评估；只更换 HTTP 前端无法消除解释器本身的漏洞。

采用回移补丁的软件包可能仍显示较旧的上游版本号。判断依据应是供应商公告和实际安装的软件包修订号，而非 HTTP 响应标头或简单的版本字符串比较。“PHP 8.2+”并不能证明已修复：每个分支都有各自的首个修复版本。

以运行时补丁为核心的分层防护

最关键的措施是安装完整的运行时补丁。在准备变更期间，应限制暴露路径并检查代理和服务器的限制。WAF 可以减少已识别的恶意流量，但无法证明所有内存破坏路径都已被阻断。

在不需要相关功能时关闭 session.upload_progress.enabled，或在适用的 PHP 8.5 场景中关闭 fatal_error_backtraces，只能减少特定路径；这些设置须在管理级配置中生效，并重启工作进程。它们不能替代补丁。调整 memory_limit 前应评估可用性和资源边界，不能对所有环境套用同一设置。

可验证的修复流程

1. 盘点 Web 服务器、FPM 进程池、队列工作进程、计划任务和镜像中的 PHP。终端里的 php -v 只能验证对应的 CLI 二进制文件。
2. 根据供应商公告确认修复，记录软件包、修订号、软件源，以及适用时的容器镜像摘要。
3. 在预发布环境测试登录、上传、会话、导入、集成、扩展和后台任务，准备可恢复的备份及回滚方案。
4. 升级软件包或重建镜像，并替换所有受影响进程。磁盘上的文件已更新，不代表旧的工作进程已经退出。
5. 切换后验证实际承载流量的运行时、业务流程和日志。使用受限的诊断方式，不要为了证明版本而公开 phpinfo()。
6. 保留部署和验证证据。回滚到存在漏洞的版本时，需要实施隔离措施并制定新的修复计划。

升级之后还应观察什么

将致命错误、OOM 事件、工作进程崩溃、启动警告及异常上传行为，与代理和应用日志关联分析。这些信号有助于调查，但单独出现并不能证明漏洞已被利用。反过来，没有错误日志也不能证明安全，因为故障可能发生在写入日志之前。

如果怀疑系统已遭入侵，安装补丁并不代表事件响应已经结束。应保留证据、隔离资产，并评估凭据、文件变更和关联访问。除了完成修复，还应调查修复之前发生过什么。