2026-10-24 14:31:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

PHP远程代码执行漏洞分析：漏洞预警

VLab安全实验室

2026年10月22日 17:40
北京

去阅读

VLab-实验室

PHP 内核中存在两处可导致远程代码执行的严重漏洞（CVE-2026-109618/CVE-2026-109619）。漏洞位于 PHP 解释器内核，攻击者无需任何认证，仅发送一条特制 HTTP 请求即可在服务器上执行任意代码，CVSSv4.0 评分均为 9.2。补丁发布前漏洞细节已提前泄露，Cloudflare 在补丁发布后 2 小时内监测到数十万次利用尝试，CISA 同日发出紧急告警。

需要特别说明的是：“未认证”指的是触发条件无需凭据，不等于“任意 PHP 部署均可无限制 RCE”。 完整代码执行已在 Apache mod\_php 环境下公开验证，但依赖特定 SAPI、堆布局控制与 ASLR 处理；PHP-FPM 场景下尚无公开的完整 RCE 演示，实际利用难度因部署形态差异显著。

漏洞概述

影响范围

PHP 8.5 < 8.5.12

PHP 8.4 < 8.4.27

PHP 8.3 < 8.3.36

PHP 8.2 < 8.2.35

PHP 8.1 及更早的全部版本

漏洞原理

CVE-2026-109618：OOM 处理中的内存状态破坏

PHP 在处理内存耗尽（OOM）错误时，会通过 longjmp() 直接退出当前上下文。问题在于：在某些上下文中，请求相关的内存在完全初始化之前就已处于可访问状态。若此时发生内存分配失败，PHP 未能正确处理提前退出，导致请求内存处于无效状态。

攻击者需构造包含大量请求头、嵌套字段名或空文件控件的 multipart 请求，在请求体大小不超过 post_max_size 的前提下，使解析阶段的内存消耗超过 memory_limit，从而触发 OOM。这里的关键前提是解析开销与请求体大小之间的不对称：请求体本身可能只有几 MB，但解析其头部结构可消耗数百 MB 内存。

该路径的完整 RCE 已在 Apache mod\_php + prefork MPM 环境下被公开验证。在 mod\_php 下，Apache 会无条件调用请求关闭流程，关闭过程会处理 OOM 留下的无效状态，最终导致内存破坏和代码执行。PHP-FPM 从源码分析可能受同一缺陷影响，但公开研究中尚未演示完整的 FPM RCE 链；LSAPI 是“可能但未验证”。此外，成功利用通常需要处理 ASLR 或获取与目标构建匹配的偏移量，公开 PoC 多针对特定 PHP 版本和构建环境。CyCognito 确认，该漏洞的完整 RCE 验证针对的是 mod\_php + prefork + 默认内存限制，不是所有部署形态。

CVE-2026-109619：残留全局状态导致释放后重用

PHP 工作进程会保留指向上一个请求内存的全局状态（如错误、会话、对象和扩展状态），但在请求内存释放前未将这些状态完全重置。同一工作进程处理下一个请求时，若部分输入解析、配置、会话或错误处理逻辑在请求正常初始化之前运行，就会访问这些残留的陈旧状态，造成释放后使用（Use-After-Free）。

利用此漏洞需要两个请求由同一个 worker 先后处理，分别充当“生产者”与“消费者”。已确认的其中一条路径依赖 session.upload_progress：第一个 multipart 请求触发 OOM 或异常退出，留下指向已释放内存的全局状态；第二个请求在 RINIT 重置该状态之前，由上传进度回调再次访问该指针。因此，session.upload_progress.enabled = On（PHP 默认值）是这条路径的前提。另一条路径依赖 fatal_error_backtraces 开启。官方已确认该路径，同时还有与 Fatal Error 等相关的其他路径在研究中。在 FPM 场景下，PHP 官方明确指出利用“取决于合适的应用操作”（depends on a suitable application operation）。

需要说明的是，有一个公开仓库声称对 session.upload_progress UAF 机制进行了源码审计和 ASAN 复现，结论是该 UAF 在已发布的 PHP 中不存在，Z_TRY_ADDREF 使 progress 结构体持有自己的引用，track_init() 释放的是反序列化副本而非活跃数组。这个结论与官方通告和多数 PoC 仓库矛盾，但至少说明该漏洞的利用细节在社区中仍有争议，不能简单写成“确定可利用”。

攻击链路分析

整体利用路径可概括为：

构造恶意 multipart POST 请求

→ 触发 OOM 或残留全局状态

→ PHP 内核内存状态异常（内存破坏 / UAF）

→ [前提：特定 SAPI + 堆布局控制 + ASLR 处理]

→ 以 Web 工作进程权限执行任意代码

→ 植入后门 / 横向移动 / 数据窃取

针对特定条件下的靶场的漏洞复现

破坏性分析

该漏洞的 CVSSv4.0 评分为 9.2，属于严重级别，其破坏性体现在以下几个维度：

认证门槛为零，但利用门槛不为零：无需认证或用户交互即可触发内存破坏条件，但实现代码执行需要满足部署形态（mod\_php 已验证，FPM 未演示完整 RCE）、堆布局控制和 ASLR 处理等条件。在 PHP-FPM 等 SAPI 下，Red Hat 评估认为“远程代码执行在实践中是困难的”。

内核层触发：漏洞在 PHP 引擎内部、应用代码运行之前触发，业务层安全机制全部失效。

全生态波及：WordPress、Drupal、Joomla、Laravel、Magento、MediaWiki、phpMyAdmin、Nextcloud 等主流 CMS 和框架均在受影响范围内。

*在野利用活跃度需审慎看待：补丁发布前细节已泄露，Cloudflare 在补丁发布后 2 小时内监测到数十万次利用尝试；但 TrendAI 指出“成功利用在野尚未被独立证实”，CyCognito 称“截至撰写时没有确认的大规模入侵报告”。大量“利用尝试”不等于大量成功 RCE*。

修复建议

官方安全更新

唯一彻底的修复手段是升级至对应分支的安全版本，并重启所有 PHP 工作进程（仅替换二进制文件不足以消除风险）：

PHP 8.5：升级至 8.5.12。

PHP 8.4：升级至 8.4.27。

PHP 8.3：升级至 8.3.36。

PHP 8.2：升级至 8.2.35。

PHP 8.1 及更早的版本：官方已终止支持，建议升级至受支持版本；短期内无法升级的应实施网络隔离，或联系发行版/LTS 厂商获取回溯补丁。

临时缓解措施

PHP 官方明确表示没有完整的临时缓解方案，以下措施仅能降低风险，不能替代升级。

关闭会话上传进度：在 php.ini 或 PHP-FPM 池配置中设置 session.upload\_progress.enabled = Off。需特别注意，该配置在 mod\_php 下无效，而 mod\_php 恰是本次风险最高的部署形态；mod\_php 用户不能依赖此项缓解，应优先升级或下线暴露面。此外，该措施仅针对 CVE-2026-109619。

限制请求体大小：按业务需要下调 post\_max\_size、max\_file\_uploads，并在 Web 服务器层限制请求体上限。

WAF 虚拟补丁：拦截请求体含 PHP\_SESSION\_UPLOAD\_PROGRESS 的 multipart 请求，并限制字段名长度与 multipart 分段数。该措施作用于流量层，可拦截已知请求特征，但无法覆盖所有变形 payload，属缓解而非根治。