【已复现】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619) 第一阶段研究

源影安全团队

2026年10月22日 01:27
湖北

去阅读

近日 PHP 官方一口气发了两个高分漏洞的修复,合并编号 CVE-2026-109618 和 CVE-2026-109619,CVSS v4 打到 9.2。当天我们就在隔离环境里把复现做完了,这里先把能公开的部分写出来,技术细节后面单独开篇。

先说结论:这组洞在 PHP 引擎里,不在任何应用上。不管跑的是 WordPress、Drupal 还是自己写的页面,只要 PHP 版本在受影响列表里、按默认配置对外提供服务,就可能被打。我们在 8.4 和 8.2 两个分支的默认部署上,只发普通 HTTP 请求、不登录,完整走通了从打崩服务到执行命令的全过程。

漏洞的机理说穿了不复杂。PHP 内存用超的时候,会用一种比较粗暴的方式直接跳出当前执行流程,这一跳,把一些放到一半、还没来得及收拾的内部状态留在了原地。请求结束,PHP 照常把这块内存还给内存池,但全局位置上还记着老地址。下一个请求进来,正好走到要读这个老地址的地方,读到的就是别的数据——运气差一点进程崩溃,内存布局被精心安排过,就能变成信息泄露,再往前一步就是执行任意命令。

整个过程不需要登录,也不要求页面调用任何特定函数。我们专门用一行输出的空白页当靶子,链路照样成立。也就是说这是引擎层的问题,业务代码怎么写都躲不开,只能升级,或者按官方建议调配置。

受影响范围官方公告写得很全:8.5.11 及以下、8.4.26 及以下、8.3.35 及以下、8.2.34 及以下,再往前的维护分支也给了源码修正。部署形态上,Apache 自带模块方式和最常见的 php-fpm 加 Nginx 反代,默认参数就中招,两种我们都搭了环境。

目前已知的限制：

1. 需 display\_errors=On:第一步“泄露内存布局”的触发路径依赖它,Off 时 地址泄露暂未打通

2. 仅 mod\_php 验证过;php-fpm 是另一条利用变体,暂未完成

3. 利用代码里写死了 PHP 内部函数的内存地址偏移和堆填充参数,不同版本、不同编译的这些值都不一样;换版本或改 memory\_limit,必须重新测一遍才能用

4. 利用需连发两个请求且由同一个 apache子进程处理;worker 越多两次请求   落到同进程的概率越低,要多试几次

5. 已升级(8.5.12/8.4.27/8.3.36/8.2.35)或 memory\_limit=-1 的资产基本无收益

6. 命令结果回显依赖目标 webroot 可写,否则只能盲打

参考:

https://www.php.net/archive/2026.php#2026-10-20-1