CVE-2026-109618 · GHSA-w8hw-w9fx-j79w

CVE-2026-109618: 内存耗尽（OOM）导致的内存损坏 RCE

PHP2Shell 中“内存耗尽”的那一半：攻击者在 PHP 解析请求时把它推入内存耗尽，留下初始化到一半的数据，而 PHP 之后会信任这些数据。结果就是：无需认证即可以 Web 服务器用户身份执行代码。

最后核实 2026-10-22

严重程度

Critical · CVSS 4.0 9.2

认证

无需认证

修复版本

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

所属

PHP2Shell（与 CVE-2026-109619 一起）

概要

PHP 在内存耗尽时会用 longjmp() 中断当前上下文。如果此时请求内存只初始化了一部分，请求关闭阶段就会读取这些无效数据或据此跳转。多条 multipart 解析路径可以在正常限制内把 PHP 推入 OOM，而且发生在任何应用代码运行之前。

影响： 无需认证即可以 PHP Web worker 用户身份执行代码。 已演示： 已在 WordPress、Drupal 和 Joomla（mod_php，默认限制）上演示认证前 RCE。

成因

PHP 在内存耗尽时会抛出致命错误，并用 longjmp() 直接跳出当前代码路径。那一刻做到一半的东西，就永远停在了一半。

如果请求内存已分配但尚未初始化，请求关闭阶段就会读取这些无效数据或据此跳转。多条 multipart（文件上传表单）解析路径都能在正常限制内把 PHP 推入内存耗尽——所以根本不需要任何应用代码参与。

PHP 列出的弱点类型：释放后使用（CWE-416）、异常情况处理不当（CWE-755）、访问未初始化指针（CWE-824），以及相关的状态处理类 CWE。

已知攻击路径

上传进度反序列化器中的释放后使用

上传进度处理在请求初始化完成之前就解码会话数据。一次内存分配失败会释放请求堆，却把反序列化器的全局记录留在原处；同一 worker 的下一个请求会把被攻击者重新占用的内存当作有效状态。

通过 PHPSESSID 远程泄露内存

OOM 中断后，一个会话 ID 指针变成悬空指针。之后的 multipart 请求会把它此时指向的内存做 URL 编码后写进响应的 PHPSESSID Cookie——即使应用从未启动会话。

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全部无修复

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

部署方式…109618说明
Apache + mod_php已证实 RCE两个 CVE 均已在默认限制下验证可达 RCE。风险最高的部署方式。
PHP-FPM（nginx、Apache、Caddy……）存在风险已在 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 列出了以下部分缓解措施：

  • 以应用无法覆盖的方式设置 memory_limit = -1（在 FPM 池或 Apache 配置中使用 php_admin_value），并配合容器或 cgroup 内存上限。
  • 调低 post_max_size：不需要上传文件时设 8M，需要时设 32M；upload_max_filesize 要低于它。
  • 在 Web 服务器或代理层强制限制请求：解码后大小、字段数、multipart 分段数、请求头数量、嵌套深度。
  • 不要使用 RLIMIT_AS / RLIMIT_DATA（ulimit -v、systemd 的 LimitAS=）——它们会触发同样的有漏洞的内存分配失败。

参考资料

常见问题

CVE-2026-109618 不登录就能利用吗？+

能。它在 PHP 解析传入请求时就被触发，早于任何应用代码、路由或认证逻辑。

关闭 session.upload_progress 能修复 CVE-2026-109618 吗？+

不能。这个设置针对的是 CVE-2026-109619 的已证实路径。针对 CVE-2026-109618 最主要的配置缓解措施，是以管理员方式设置 memory_limit = -1 并配合 cgroup 内存上限——即便如此也不完整。

哪些版本修复了 CVE-2026-109618？+

2026 年 10 月 21 日发布的 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。7.4、8.0 和 8.1 有源码回移植；各发行版会提供各自的已修复软件包。

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

公告根据源码分析评估 FPM 存在风险，PHP 基金会也表示已通过应用层代码路径在 FPM 上证实 RCE。演示中最直接的情形是默认限制下的 Apache + mod_php。

相关页面