php2shell漏洞升不了级？三道临时防线先挡一波

PHP 的 php2shell 漏洞（CVE-2026-109618/109619）修复版已经发布两天，但现实里不是每个环境都能立刻升级：生产服务器要走变更流程，老项目卡在扩展兼容上，外包维护的站点一时半会儿联系不上人。官方安全公告里给了几项临时缓解措施，这篇文章把它们整理成三道可以直接落地的防线，先把最危险的攻击面堵住，为升级争取时间。

防线一：把 memory_limit 改成不限制

听起来反直觉，但第一条攻击链的原理是：PHP 用 longjmp() 中断超内存的请求，中断时内部请求数据只初始化了一半，清理流程把这些残缺数据当正常的处理，就造成了内存破坏。把 memory_limit 设为 -1（不限制）可以从根上避免触发这条链。关键做法是在 FPM 池配置里用 php_admin_value 写死（php_admin_value[memory_limit] = -1），这个指令应用代码无法覆盖；同时检查目录级配置有没有把限制改回去——应用目录下的 .user.ini、代码里的 ini_set、甚至 php.ini 里的运行时设置都可能重新写回一个有限值，改完记得用 phpinfo 确认实际生效值。另外，关掉内存限制意味着失控的脚本会吃内存，配合好进程管理器的重启策略再上。

防线二：关闭 session.upload_progress

多条攻击链依赖 PHP 的上传进度机制（session.upload_progress），这个功能默认开启，但现实中极少有站点真的在用它。在 php.ini 或 FPM 池里加一行 session.upload_progress.enabled=0，代价仅仅是前端上传进度条失效——绝大多数网站本来就没实现这个功能。一行配置砍掉一大片攻击面，是临时措施里性价比最高的一项。

防线三：网关层拦 multipart 请求

攻击需要构造特制的 multipart 表单请求，所以可以在 Nginx 或上游代理层对可疑 multipart POST 做拦截。给一个思路：在 Nginx 里对 POST 且 Content-Type 为 multipart/form-data 的请求返回 403，只对你确认需要上传功能的路径（比如后台媒体上传）开白名单。代价很直白：前台凡是带文件上传的表单都会受影响，电商和投稿类站点要谨慎评估，先用日志观察真实流量里 multipart 请求来自哪些路径，再决定拦多宽。

顺便把检测挂上

安全研究者已经公开了针对这两条 CVE 的检测规则集，覆盖 Suricata、Sigma 和 ModSecurity 三种格式（官方地址：github.com/ikow/php2shell-poc，MIT 许可），可以直接部署到现有监控里。没有 IDS 的站点至少人工看两样：访问日志里来源不明的 POST 请求，以及 PHP-FPM 错误日志里突然增多的 worker 崩溃和 502——研究实测显示部分攻击链会让无会话的页面直接 502，这是一个很显眼的异常信号。

最后再说一遍

这三道防线只能缩小攻击面，官方原话是“不能让安装变得安全”，唯一完整的解法依然是升级到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。把临时措施当成绷带，别当成治疗方案，修完版本记得逐项撤掉临时代码，恢复内存限制和上传功能。