· adswds-team · 安全 · 7 min read
PHP 内存耗尽可打成未授权 RCE：CVE-2026-109618，先升再谈缓解
PHP 官方 2026-10-21：CVE-2026-109618（CVSS 4.0 9.2）让 OOM 打断未完成的请求初始化，mod_php 上已演示未授权 RCE。修复版本 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。
据 PHP 官方安全公告（2026-10-21）与 GHSA-w8hw-w9fx-j79w，CVE-2026-109618 是 PHP 核心里的严重远程代码执行：内存耗尽（OOM）用 longjmp() 提前退出时，请求内存可能只初始化了一半，随后的请求清理会把这份无效状态当成有效数据。公告写明：风险覆盖对外提供 Web 请求的安装，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 与 LiteSpeed；其中 mod_php 风险最高，已有演示——未授权请求能在任何应用代码运行之前触发。
一句话：落地页还没执行你的 PHP，运行时自己就可能先被打穿。
同日还有独立的 CVE-2026-109619（过期全局状态）。两枚都要修，配置缓解互不替代。
一、公告里已确认的事实
| 项 | 内容 |
|---|---|
| 编号 | CVE-2026-109618 / GHSA-w8hw-w9fx-j79w |
| 评级 | Critical，CVSS 4.0 为 9.2（AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H） |
| 受影响 | 8.2.35、8.3.36、8.4.27、8.5.12 之前的对应分支 |
| 修复版本 | 8.2.35、8.3.36、8.4.27、8.5.12 |
| 已确认影响 | 以 Web 工作进程账户执行的未授权 RCE |
| 已验证场景 | 默认输入与内存限制、常见 prefork、多 worker 的 mod_php，经 HTTP 完成 RCE |
| FPM | 源码分析认为仍可能受影响；尚未演示完整的 FPM 利用。请求启动失败时 FPM 会退出子进程，从而避免消费那份无效状态 |
| FrankenPHP | 与 mod_php 类似会无条件做请求清理，公告认为很可能受与应用无关的攻击 |
| LSAPI | 模型接近 FPM；与应用相关的利用「可能但未验证」 |
oss-security 邮件（Jakub Zelenka，PHP 安全团队）与 GitHub Advisory 一致：失败的分配不必和那块无效内存有关；多种 OOM 路径都能稳定走到这个条件。英国 NCSC 已呼吁立即处理 CVE-2026-109618 与 CVE-2026-109619。
官方还说明了若干能在「看起来没超过 post_max_size」时把内存打满的 multipart 路径（无可用 Content-Length、部件头数量、不计入 max_file_uploads 的空文件控件、嵌套字段名）。本文不复述构造步骤。对运维有用的结论是：只在反代上卡一个看起来很小的 body 上限，并不自动等于 PHP 内存上限也守住了。
二、版本怎么对
- 在跑 8.5.0–8.5.11、8.4.0–8.4.26、8.3.0–8.3.35、8.2.0–8.2.34 的，升到本分支修复版。AWS 安全公告 2026-143 用的就是这组边界。
- PHP 8.1 及更旧不再从 PHP 项目收常规更新。公告称安全团队为从源码构建、又拿不到发行版 LTS 的人提供了 7.4 / 8.0 / 8.1 的最小源码 backport；发行版是否带上，要问供应商。
- 8.2 在 2026-12-31 结束生命（见 8.2.35 发布说明），这次补丁之后不会再有安全更新。
- 依赖志愿者仓库
rpms.remirepo.net的，公告当天明确说当天不会有包，建议改发行版包或自行从源码构建。
补丁本身的做法（Advisory）：OOM 不再 longjmp() 冲出未记账的上下文，改为在下一个 VM 安全点做延迟的软 OOM，并在更高阈值用 _exit() 做硬 OOM。
三、暂时升不了时，官方怎么说
公告写明：只有升级才是完整修复。 下面只降低特定路径的暴露。
-
memory_limit=-1，用 FPM 池或 Apache 的php_admin_value锁死，确认没有池、目录或应用把有限值设回去。这去掉「可预期的 PHP 内存上限」这条已确认利用条件，底层mmap()失败仍可能走进原路径。 - 不靠上传的应用：
post_max_size = 8M；需要上传：post_max_size = 32M，且upload_max_filesize低于它。 - 在 Web 服务器或反代上限制解码后的请求大小、字段数、multipart 部件数、头部数和嵌套深度；没有可用 Content-Length 的请求也要覆盖。
- 容器可用 cgroup
memory.max当可用性边界，最好只杀掉出问题的 worker。不要用RLIMIT_AS/RLIMIT_DATA，它们会在触顶时让分配失败，正好走到有漏洞的longjmp()。 - 同时做 CVE-2026-109619 的缓解，Advisory 明确要求两边一起看。
四、和落地页主机的关系
广告落地若在客户自己的 PHP 主机上出页，暴露面就是这台机器的 PHP，而不是页面 HTML 写得紧不紧。官方 PHP 包的常见档是 PHP 8.3，对应修复版本是 8.3.36。mod_php 上问题发生在应用代码之前，意味着「业务里没有危险函数」不能当成没风险。
FPM 尚未有完整利用演示，不等于池子可以留在 8.3.35。同一 worker 上还有另一枚已在 FPM 验证会话路径的 RCE，见同日那篇。
边缘判定把访客规则放在请求进业务之前，挡不住 PHP 运行时在解析请求体时自己出错。先把解释器升到修复版，再谈规则。
五、小结
CVE-2026-109618 是 2026-10-21 两枚严重 PHP RCE 里、mod_php 已完成未授权演示的那一枚。修复版本是 8.5.12、8.4.27、8.3.36、8.2.35。配置项只能收窄路径。落地页、跟踪跳转和后台若还在这些分支的旧小版本上，按主机而不是按站点排期升级。
相关阅读：过期全局状态 RCE、9 月 FPM IPv6 ACL。
