PHP2Shell 漏洞争议解读：我们该如何处置？
PHP2Shell两个CVSS 9.2漏洞引发两派争论：一派说高危免认证RCE必须连夜修，一派说POC仅在特定环境复现不用恐慌。本文溯源官方修复提交与CrowdStrike、OX Security评估，讲清「能触发」与「能稳定利用」的区别，给出红黄绿三级自查表与治本加缓解的处置清单。
导语：同样是 PHP2Shell 这两个 CVSS 9.2 的漏洞，一边是「连夜升级」，一边是「别慌，POC 都跑不稳」。两种说法其实都没全错，只是讨论的不是同一件事。这篇不站队，把分歧拆开讲，再给一张能直接照做的处置表。
先把事实摆清：洞在哪，为什么会这么严重
两个编号 CVE-2026-109618 和 CVE-2026-109619，10 月 21 日 PHP 官方发布 8.2.35、8.3.36、8.4.27、8.5.12 四个修复版本，官方修复是一个提交：Avoid state corruption via bailout（避免 bailout 造成的状态损坏）。
机制其实不复杂。PHP 处理内存超限时，一直靠一个「长跳转」的机制直接终止当前执行、跳到恢复点。问题在于：如果这次跳转发生在引擎内部正干活的时候，被跳过的不只是你的业务代码，还有引擎自己的清理和记账。于是会话、序列化上下文这类跨请求复用的状态，可能还指着上一份已经被释放的内存。
为什么偏偏是 session.upload_progress 这个功能成了暴露面？它从 PHP 5.4 起默认开启。当 multipart 请求里带上 PHP_SESSION_UPLOAD_PROGRESS 字段时，上传解析器会在你的脚本被编译之前就驱动会话回调——每一次进度更新都要开会话、解码、写入、再整份编码回去。这些步骤的分配量完全由请求决定：分片数量、字段名长度、进度值长度，都能把内存往上限上顶。而这一切，发生在任何一行业务代码运行之前。
规模也不小。Shodan 在 10 月 21 日的统计显示，约 200 万台暴露在公网的 PHP 服务器受影响，能识别出 PHP 版本的服务器里有 99.99% 还没修，其中约 137 万台（69%）跑的是永远拿不到官方补丁的老版本。
所以「这是底层缺陷，WAF 和代码过滤拦不住」这个判断是成立的。但它离「拿个工具一扫就能拿下服务器」还很远，这就是分歧的来源。
两种说法为什么都能成立
关键在区分两件事：能触发，和能稳定利用。
说高危的一派，看的是触发条件：不需要账号、不需要登录、远程可打；session.upload_progress 默认开启；PHP-FPM、mod_php、FrankenPHP、LiteSpeed 这类常驻 SAPI 全在攻击面内；只要构造特制 multipart 请求，不需要真的传一个大文件。CVSS 9.2 是按影响上限打的分——一旦利用成功，保密性和完整性都是高影响。
说「没那么好利用」的一派，看的是稳定接管：内存破坏类漏洞有个老规矩，能撞崩不等于能控执行流。利用效果高度依赖版本、编译参数、SAPI 类型、操作系统、libc、内存分配器和内存布局；公开的利用脚本常常只在特定靶机上跑得通，换一套环境就只崩不拿。
这一派有权威旁证。CrowdStrike 在针对这次漏洞的评估里写得很直接：不太可能出现一个 EXP 通吃所有部署，但对固定镜像、固定版本组合（某个 Docker 镜像 + 已知 libc + 固定应用）可以预先校准偏移，做出稳定利用；同时截至目前，还没有确认的在野成功利用。OX Security 的复现报告也说明，他们验证了触发链，但没有做武器化。
一句话总结：让 PHP 进程异常退出，门槛很低；稳定接管服务器，门槛很高。两个结论并不矛盾。
两个容易踩的误读
误读一：POC 跑不稳，就可以慢慢修。风险是动态的。同类漏洞的利用链会随着公开研究、靶场复现、AI 辅助调优不断迭代，能适配的环境越来越多。今天只在特定环境成立，不代表下个月还这样。等一版好用的公开 EXP 流出来再补救，窗口已经没了。
误读二：CVSS 9.2，等于扫到就能拿下。评分评估的是攻击面、权限要求和影响上限，不看当下 POC 的成功率。反过来也成立：「评分高但难利用」不是拖延的理由——监管和行业预警按上限风险处置，是标准动作，不是危言耸听。
按环境分级：你的站点在哪一档
| 等级 | 典型特征 | 动作 |
|---|---|---|
| 红色（优先） | Apache mod_php；版本低于 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12；公网暴露且开启 upload_progress | 48 小时内升级，升级前先叠加缓解 |
| 黄色（排期） | PHP-FPM、FrankenPHP 等常驻 SAPI，版本在受影响范围，公网有上传或表单接口 | 本周排期升级，同步做缓解与监控 |
| 绿色（常规） | 纯内网不对外；已关闭 upload_progress；已升到修复版本 | 纳入常规维护节奏，保留日志告警 |
把 mod_php 单独列出来是有原因的：单进程常驻、内存布局相对可控，是目前公开研究里较容易做稳定复现的场景。FPM 多 worker 的堆布局要复杂得多，难度不在一个量级。
处置方案：治本与缓解分开做
一、治本：升级
- 升到 8.2.35、8.3.36、8.4.27、8.5.12 或更高。8.1 及更早分支官方已停止维护，没有补丁——要么迁到受支持分支，要么用发行版的 LTS 回补版本。
- 升级后必须重启 PHP-FPM 或 Apache 服务。只换文件不重启，等于没修。
- 各分支维护截止时间，可以对照我们之前整理的PHP2Shell 修复版本与维护截止时间表，顺手把年底就要停维的 8.2 一起规划掉。
二、缓解：升级前或实在升不了时的过渡手段，不能当补丁用
- php.ini 设置
session.upload_progress.enabled = Off，改完重启服务生效； - FPM 设
pm.max_requests = 1，让 worker 处理一个请求就重建，直接断掉跨请求的利用链。代价是性能，流量大的站点要先评估； - WAF 拦截携带
PHP_SESSION_UPLOAD_PROGRESS的异常嵌套 multipart 请求，上传接口做限流； - 非必要的上传接口先下线，上传目录禁止执行脚本，Web 进程用低权限账号运行；
- 盯住 PHP 子进程异常退出、陌生外联和异常子进程。
还有一个坑要提醒：官方提到过的 memory_limit = -1 缓解方式，会取消 PHP 的内存上限，很容易把「漏洞触发」变成「业务自己内存溢出被打死」。用之前先算清代价，一般不建议当常规手段。涉及 PHP 环境改造和版本迁移，可以参考我们的PHP 技术服务说明。
给运维和站长的四句话
按上限风险做规划，按环境差异排优先级，两头都不走极端。公网加 mod_php 的组合先动手，纯内网排期处理。短期缓解要叠加，不要单独依赖关一个配置项。威胁情报继续盯——这类漏洞后续出现适配不同环境的利用样本，是大概率事件。
这类底层漏洞没有「业务代码写得干净就没事」的说法。尊云科技可以对现有网站和系统的运行环境做一次摸底，把 PHP 版本、SAPI 模式、上传配置和现有缓解措施列清楚，再给出升级与缓解的先后顺序。
说明：本文仅作安全科普与处置参考，不提供漏洞利用工具，禁止用于未授权测试。请遵守网络安全相关法律法规。
