PHP2Shell 的补丁发下去才两天，PHP 官方又追了一条公告。不过这次语气完全不一样。
上周是"所有用 PHP 跑 web 的，立刻升"。这次是信息性公告（informational advisory）：编号 CVE-2026-115560，又是一个能导致远程代码执行的问题，但官方明说不走紧急修复，会在下一个常规 bugfix 版本里修。翻译过来就是：先别慌，有条件的把某个开关关掉。
先把话说清楚：这个洞不是 PHP2Shell，也没有被上次那四个版本（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）修掉。它是独立的一条路。
触发条件有多"窄"
官方把条件写得很具体，得同时满足：
- 应用配置里把
session.serialize_handler设成php_binary或php_serialize； - 然后在运行时用
ini_set()又把它改回php，而且要在session_start()之前改； session.upload_progress还是开着的。
三条全占，才可能被利用。官方自己都说这配置"在现实里不太常见（unlikely）"，所以才按常规节奏处理，不单独出紧急版。
但注意第三条——session.upload_progress 默认就是开的。风险往往不在你"开了什么"，而在你没意识到它一直开着。
影响版本 & 修复版本
影响版本：满足上面那套配置的 PHP。它不绑某个具体版本号——从 PHP2Shell 那天起，session.upload_progress 就已经被写进 GHSA-6wmf-4rv5-p3rp（CVE-2026-109619 那份）当缓解项了，这个新问题和那条路同源。
修复版本：暂无。官方会在下一个常规 bugfix 版里发完整公告（编号已预留给 CVE-2026-115560）。在那之前，官方给的动作只有一个：
session.upload_progress.enabled = 0一条自查命令
看你机器上这个开关到底是什么状态：
php -i | grep -E 'session.upload_progress.enabled|session.serialize_handler'session.upload_progress.enabled 显示 On 的，接着往下看。
怎么关（坑还是那个坑）
别用 ini_set()，也别用 FPM 的 .user.ini。这类设置必须在请求解析之前生效，运行时再改就晚了。写在真正早生效的地方：
php.ini 全局：
session.upload_progress.enabled = Off或者写在 FPM pool：
php_admin_value[session.upload_progress.enabled] = 0改完把每个 worker 都重启：systemctl restart php-fpm（或你对应的 pool 服务）。只 reload 不一定能把老 worker 换掉。
上周关过的，可以跳过
公告里专门提了一句：如果你 10 月 21 日跟着 PHP2Shell 已经把 session.upload_progress.enabled 关了，保持现状就行，不用再做别的。
别把"informational"当成"不用管"
我的判断是，这条公告的价值不在"又多严重"，而在它把一件事摆到了台面上：同一个开关，上周是缓解手段，这周成了新的攻击面。官方写"unlikely"是给大众看的；对配置千奇百怪、还留着一堆老项目的机器来说，php_binary / php_serialize 这种冷门设置恰恰最容易在某台老机器上躺着。
那天看完公告，我干的就一件事：把手上几台机器的 session.upload_progress.enabled 全查了一遍，On 的统一关掉、重启 worker。前后不到十分钟——比赌那个"unlikely"划算。
三条命令记一下：
php -i | grep session.upload_progress.enabled
php -i | grep session.serialize_handler
systemctl restart php-fpm上周那篇 PHP 引擎自己有个洞 讲的是"能升就升"；这篇讲的是升不动、或者补丁还没出来的时候，先把身边的开关过一遍。两件事不冲突。
官方公告：https://www.php.net/archive/2026.php#2026-10-23-1
评论