php2shell：PHP 自身的两个 RCE

PHP 核心 · 2026.10.21

PHP 自身，被攻破了

两个 RCE，CVSS 9.2。登录之前，代码先跑。

漏洞不在应用，

在语言本身。

两个 CVE · CVSS v4.0

9.2

同一评分。10 月 21 日，PHP 紧急发布修复版。

共同模式

失败时，清理被跳过了

分配失败，longjmp 直接跳出

请求结束，残缺状态没人收拾

下一个使用者，把它当成有效数据

请求的一生

洞，在应用代码之前

解析 multipart 与请求初始化，都发生在脚本运行之前。

内存耗尽，

善后做了一半。

CVE-2026-109618 · OOM → RCE

从崩溃到执行

撑破内存超大字段名进入 $_POST 哈希表

跳过初始化longjmp 逃出，桶只写了一半

shutdown 收尸把残缺桶当成正常数组销毁

伪造析构堆排布让 pDestructor 指向 system()

CVE-2026-109618 · 触发器

绕过 post_max_size

单个 part 的头数量没有上限

空文件字段不占 max_file_uploads

只检查声明的 Content-Length，chunked 可绕过

CVE-2026-109618

0行

mod_php 在脚本启动前已 shutdown；业务代码未执行。

CVE-2026-109619

上一个请求的尸体，

被下一个请求踩到

worker 的全局指针仍指向已释放的请求内存。

CVE-2026-109619 · 跨请求

幽灵如何活过一次请求

错误发生致命错误或 OOM，跳过重置

请求释放内存释放，指针悬空

下个请求同一 worker 在 RINIT 前读取

无脚本入口session.upload_progress 无需 session_start()

谁最危险

mod_php 风险最高

mod_php总会 shutdown；已演示未认证 RCE

PHP-FPM失败即回收；upload_progress 可利用

影响范围

5.4起

多份分析称直到 8.5.11。修复版：8.2.35、8.3.36、8.4.27、8.5.12。

一个弄脏这次，

一个毒害下次。

补丁做了什么

换一种失败方式

软失败OOM 延迟到 VM 安全点

硬退出仍不安全就直接 _exit()

不再返回longjmp 不带着残缺状态继续

在打补丁之前

先关掉两条路径

session.upload_progress.enabled = 0

PHP 8.5：fatal_error_backtraces = 0

重启所有 worker；补丁才是彻底修复

记住

别让失败，

留下可用残骸。

升级 PHP，然后重启每一个 worker。