CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp

CVE-2026-109619: 跨请求残留全局状态导致的 RCE

PHP2Shell 中“跨请求”的那一半：发生致命错误后，PHP 会留下指向已释放内存的全局指针。同一 worker 的下一个请求会使用它们——导致内存泄露，或让攻击者执行代码。

最后核实 2026-10-22

严重程度

Critical · CVSS 4.0 9.2

认证

无需认证

修复版本

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

所属

PHP2Shell（与 CVE-2026-109618 一起）

概要

致命错误（包括 OOM）可能跳过每个请求结束时的重置，导致错误、会话、对象或扩展相关的全局状态仍指向请求结束时已释放的内存。同一 worker 上的下一个请求可能在正常初始化之前使用这块已释放的内存。

影响： 释放后使用（UAF），可导致 worker 内存泄露或代码执行。 已演示： 已在 WordPress 和 Drupal 上演示认证前 RCE；还演示了与应用无关的远程内存泄露。

成因

PHP 会把一部分状态放在请求级全局变量中——错误、会话、对象和扩展状态。正常情况下它们会在每个请求结束时重置。但致命错误（包括内存耗尽）可能跳过这次重置，关闭阶段的警告也可能在清空之后再次写入错误状态。

这些全局变量指向的内存会在请求结束时被释放。如果同一个 worker 随后在正常请求初始化之前运行代码——比如 INI 诊断或会话上传进度处理——就会使用已释放的内存。连续处理大量请求的 worker（PHP-FPM、mod_php 子进程）正是让这个漏洞可被触达的原因。

已知攻击路径

致命错误回溯中的释放后使用

EG(last_fatal_error_backtrace) 在销毁请求堆的 OOM 之后仍然存在。下一个请求中较早的诊断逻辑会沿着这个悬空指针访问。演示中最强的情形：开启 fatal_error_backtraces 的 PHP 8.5，在 mod_php 上实现 RCE。

会话上传进度的生命周期

被中断请求遗留的会话状态，会被下一个请求的上传进度处理使用。已在 mod_php 和 PHP-FPM 上验证 RCE。

OPcache 共享内存中的类型混淆

在推进 CG(map_ptr_last) 与发布共享边界之间发生内存分配失败，会留下各 worker 认知不一致的槽位，使某个 worker 把槽位复用于另一种对象类型。

其他请求级状态

公告指出对象和扩展相关的状态在特定条件下可被利用。补丁修复的是整个模式，而不仅是这几条路径。

PHP 官方公告和 Wiz 的文章对部分路径的归类不同。补丁修复的是共同的故障模式，所以归类方式不影响你需要做的事。

受影响与修复版本

分支存在漏洞修复版本
8.5< 8.5.128.5.12
8.4< 8.4.278.4.27
8.3< 8.3.368.3.36
8.2< 8.2.358.2.35
8.1 · 8.0 · 7.4全部仅源码回移植
5.4 – 7.3全部无修复

按服务器部署方式的暴露情况

部署方式…109619说明
Apache + mod_php已证实 RCE两个 CVE 均已在默认限制下验证可达 RCE。风险最高的部署方式。
PHP-FPM（nginx、Apache、Caddy……）已证实 RCE已在 FPM 上验证通过会话生命周期实现 RCE；OOM 路径已通过应用层代码路径证实，但尚无公开的通用 FPM 利用。
FrankenPHP / LiteSpeed LSAPI很可能受影响公告评估为很可能受影响。常驻 worker 只会让跨请求残留状态的问题更突出。
CLI（cron、队列 worker、artisan）公告未涉及公告未讨论，正常使用时也无法通过 HTTP 请求触达。但仍要升级——它们来自同一个软件包。

CVSS 4.0 评分：9.2

向量： CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

指标在本漏洞中的含义对分数的影响

AV:N

Attack Vector: Network（网络）

通过互联网发送普通 HTTP 请求即可触达。拉高分数

AC:H

Attack Complexity: High（高）

利用必须针对每个目标的内存布局调整，不是复制粘贴一个请求就能成功。拉低分数

AT:P

Attack Requirements: Present（存在前提）

能否成功取决于攻击者无法控制的部署条件（SAPI、内存限制、worker 复用）。拉低分数

PR:N

Privileges Required: None（无）

不需要账号，不需要登录。拉高分数

UI:N

User Interaction: None（无）

不需要任何人点击任何东西。拉高分数

VC:H / VI:H / VA:H

对漏洞系统的影响：High（高）

PHP 服务器的机密性、完整性和可用性全部失守。拉高分数

SC:N / SI:N / SA:N

对后续系统的影响：None（无）

评分不计入横向移动到其他系统——但实际中被窃取的凭据往往能做到这一点。拉低分数

为什么早期报道说是 10.0 →

修复与缓解

修复方法是升级 PHP

安装已修复版本并重启所有 PHP worker。修复指南 →

如果无法立即升级，php.net 列出了以下部分缓解措施：

  • 在 php.ini、FPM 池或服务器配置中设置 session.upload_progress.enabled = 0，然后重启所有 worker。详情 →
  • PHP 8.5：设置 fatal_error_backtraces = 0 并重启。这只能挡住已证实的回溯路径。
  • 移除按请求生效、会在初始化前输出诊断信息的无效或已弃用配置。用 error_reporting、display_errors 或 @ 隐藏它们没有用。
  • 修复攻击者可触发的致命错误和执行超时（回调、上传与导入处理、清理逻辑）。
  • 在性能允许的情况下，考虑设置 pm.max_requests = 1。

参考资料

常见问题

CVE-2026-109619 能在不执行代码的情况下泄露数据吗？+

能。跨请求的释放后使用可以泄露 worker 内存——其他用户的密码、API 密钥、会话令牌——而攻击者全程无需执行代码，因此更难被发现。

session.upload_progress.enabled = 0 能修复 CVE-2026-109619 吗？+

只能部分缓解。它能挡住已证实的会话路径，但挡不住其他变种，而且只有在 php.ini、FPM 池或服务器配置中设置（不能用 .user.ini 或 ini_set()）并重启所有 worker 后才有效。

PHP-FPM 受 CVE-2026-109619 影响吗？+

受影响。会话生命周期 RCE 已在 mod_php 和 PHP-FPM 上都得到验证。FPM worker 会连续处理大量请求，这正是跨请求残留状态所需要的条件。

调低 pm.max_requests 有用吗？+

它能缩短被破坏状态的存活时间，设为 pm.max_requests = 1 则完全不复用 worker，但性能代价很大。对只需要一个请求的攻击路径无效。

相关页面