PHP CVE-2026-115560未修复RCE:PHP2Shell补丁后的紧急预警

导语:PHP2Shell 补丁上线两天,官方再预警 CVE-2026-115560:特定会话配置下可能未认证 RCE,暂无补丁,只有一行配置管用——先关掉 session.upload_progress。

一、两天之内,补丁和新坑一起到

10 月 20 日晚,PHP 团队向全球预告:21 日 14:00 UTC 发布紧急安全版本,修两个 CVSS v4.0 9.2 的致命漏洞——CVE-2026-109618(RCE via OOM corruption)与 CVE-2026-109619(RCE via stale global state)。10 月 21 日,PHP 8.5.12、8.4.27、8.3.36、8.2.35 准时上线,公告写得很直白:”没有完整缓解措施,升级是唯一安全的选择”。

攻击面早就热了。亚马逊的 MadPot 蜜罐在 10 月 17 日就记录到针对这两个漏洞的利用尝试,比公开披露早了四天;Cloudflare 称披露后 45 分钟内出现数万次尝试,到 10 月 22 日早期已冲进百万量级;Sophos 与 Arctic Wolf 都看到攻击者试图借这两条链投递 Mirai 变种(Sophos 称之为 Potassium)。好消息是,Previdian、Wordfence 等厂商目前只看到扫描与试探,尚未确认成功代码执行——稳定的利用链比想象中难搓。

然后 10 月 23 日 10:17 UTC,PHP 又发了一份信息级公告,主角是 CVE-2026-115560:可能 RCE,没有补丁,建议先关掉一个功能。

二、CVE-2026-115560 到底在什么条件下触发

官方公告很短,触发条件却写得毫不含糊。要被这条链打中,应用必须同时满足三点:配置里把 session.serialize_handler 设成 php_binary 或 php_serialize;运行时用 ini_set() 把它改回 php,而且改在 session_start() 之前;同时 session upload progress 还开着。

从不在运行时改 serialize handler 的应用,继续开着上传进度也没事。PHP 判断这套组合”实践中不太可能”,所以没走紧急发布通道,打算在下一个常规修复版本里补一份完整公告。这也意味着:受影响版本范围、修复版本、CVSS 评分,目前统统还是空白。

要理解它为什么存在,得看 PHP2Shell 的根因结构。研究者把这类问题拆成”生产者”与”消费者”:某个请求在错误处理中把全局状态发布出去(生产者),下一个请求在正常初始化之前就去读这段状态(消费者)。session upload progress 在 body 解析阶段就开跑,既能把会话与解码器状态提前发布,也能在下一个请求提前读取。10 月 21 日的补丁主要堵住了消费者一侧,生产者一侧的口子还在——CVE-2026-115560 很可能就是从这道缝里钻出来的更窄通道,不过 PHP 至今没有确认两者同根因。

三、蓝队今天就该动的三件事

第一,立刻关掉 session.upload_progress.enabled=0。写在 php.ini、PHP-FPM pool 配置或 .htaccess 的 php_value 里都行,改完记得重启全部 worker,别只 reload。10 月 21 日的公告已经把它列为 CVE-2026-109619 的缓解措施,照做过的同学这次什么都不用加。

第二,别把”关上传进度”当万能钥匙。Datadog 的复现结论很明确:它挡不住 CVE-2026-109618 与 109619,这两个只能靠升级到 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 解决。

第三,排查自己的代码里有没有运行时改 serialize handler 的动作,顺手把 10 月 17 日之后的可疑活动翻一遍:大体积 multipart 表单、请求初始化阶段的内存耗尽错误、web worker 里冒出来的陌生 shell 进程,以及 PHPSESSID 里出现的异常数据——Wiz 披露的内存泄露手法是把陈旧内存 URL 编码后塞回 PHPSESSID,拿到的可能是别的请求里的凭据。

公开仓库里已经有利用链与检测规则在流通,但既然在野利用带上了 Mirai 的牟利味道,本文不提供任何利用代码下载,防守方把精力放在规则和排查上更划算。