PHP2shell漏洞怎么修复：版本对照与验证

PHP2shell漏洞修复是指把 PHP 运行时升到官方修复版本、并重启全部 worker 这件事。卓创源码网（zhuochuangyun.cn）把版本对照、每种部署方式的动作和验证方法拆开写，照着做就行。

PHP2shell漏洞修复版本对照表

PHP 分支	受影响版本	修复版本	支持状态
PHP 8.5	低于 8.5.12	8.5.12	在保，官方直接发布
PHP 8.4	低于 8.4.27	8.4.27	在保，官方直接发布
PHP 8.3	低于 8.3.36	8.3.36	在保，官方直接发布
PHP 8.2	低于 8.2.35	8.2.35	在保，2026-12-31 结束生命周期
PHP 8.1 及更早	8.1.x / 8.0.x / 7.x / 5.4 起全部受影响	无官方安装包	已停止支持，仅有最小源码回补分支

PHP2shell漏洞怎么修复？判断标准只有一条

判断标准只有一个：运行中的版本号低于对应分支的修复版本就是没修。8.5 升 8.5.12、8.4 升 8.4.27、8.3 升 8.3.36、8.2 升 8.2.35。

升完之后最关键的一步是确认生效，而不是确认安装成功。升级只替换磁盘上的文件，常驻的 PHP 进程还在跑老代码。官方公告里反复出现「重启每一个 worker」这句话，正是因为大量「明明升级了还是被打」的案例都卡在这一步。实际验证有两条路：

一是看运行中进程报告的版本，不是看磁盘上装了什么。在 FPM 环境用 php-fpm8.3 -v 之类的方式查，或临时放一个带鉴权的 phpinfo 页面看 Server API 与版本号。二是注意 X-Powered-By 响应头不可信，站点主动隐藏版本号时，光看 HTTP 响应证明不了已修复。

还有一条容易漏：一台机器上常常同时存在多个 PHP 版本、多套容器镜像，每一个都要单独确认。

PHP2shell漏洞升级步骤有哪几步？备份、重启、验证、回查

完整动作链是六步，顺序不能乱。

第一步，备份数据或做服务器快照，留出回滚路径。第二步，记录升级前每个 PHP 实例的版本、SAPI 类型和所在位置。第三步，按分支升到对应修复版本，注意 8.2 分支在容器里要用写死的镜像标签。第四步，重启所有 PHP worker 与 Web 服务，不只是主站那一个。第五步，用运行中进程的方式验证版本，别只看磁盘文件。第六步，在测试环境验证老源码在新版本上跑得通，再回查 10 月 20 日之后的日志。

这六步里第四步和第五步最常被省掉，也正是「升级了但没生效」的主要来源。

如果要评估工作量，可以按部署方式分开看：宝塔面板在软件商店直接更新，最省事；Docker 要注意浮动标签陷阱并强制重建容器；源码编译需要自己处理回补分支和依赖；虚拟主机则完全依赖主机商。

宝塔面板、Docker 镜像、源码编译三种部署分别怎么升？

宝塔面板：官方只发布源码包，8.2 到 8.5 四个分支可以直接在软件商店更新到修复版本；宝塔为 7.4、8.0、8.1 三个停更分支自行打包了修复版，Linux 面板是 7.4.34、8.0.31、8.1.35。操作前先刷新软件列表，再看对应 PHP 版本的更新入口。Windows 面板没有旧版本打包，只能改配置文件做临时缓解：把 session.upload_progress.enabled 设为 0 写到实际加载的 php.ini 里，保存后重启对应服务。

Docker 镜像：官方镜像已经跟进，但浮动标签有陷阱。php:8.5-fpm、php:8.4-fpm、php:8.3-fpm 这类浮动标签指向修复版，php:8.2-fpm 还停在 8.2.34，用 8.2 分支的部署必须把标签写死成 php:8.2.35-fpm。重建时用 docker compose build –pull –no-cache，再 up -d –force-recreate 强制换掉容器，最后进容器执行 php -v 核对。

源码编译：官方为 7.4、8.0、8.1 提供了最小回补分支，在 php-src 仓库里有对应标签。适用于有编译能力但拿不到 LTS 厂商回补包的情况。另外注意 rpms.remirepo.net 这个社区仓库在发布当天不会同步更新，RHEL 系建议直接用发行版官方包。

PHP2shell漏洞修复后要重启吗？为什么这一步不能省？

必须重启，因为 PHP-FPM、Apache mod_php、LiteSpeed、FrankenPHP 这些运行模式都是常驻进程复用：接一个请求、执行、清理、再接下一个。升级替换的是磁盘上的二进制和脚本，已经加载进内存的旧代码不会自己消失。

这还有一个安全侧的推论，官方在 109619 的说明里讲得很清楚：第二个漏洞本身就是跨请求的释放后使用，一个请求留下失效状态、另一个请求读走它。worker 不重启，旧状态和新代码混在一起，等于给这个缺陷留了活动的舞台。

重启要覆盖全部实例。宝塔上一台机器可能同时装着 7.4、8.0、8.1、8.2、8.3 好几套，容器环境下每套镜像各自独立，漏掉一个就等于留了一个口子。

顺便说清 PHP2shell漏洞临时缓解措施的定位：那些配置是升级窗口期的桥，不是终点。官方明确说它们只减少特定攻击路径的暴露面，不让安装变得安全。

8.1 及更早版本没有官方安装包，该怎么走？

分三种情况处理。

第一种，有发行版或 LTS 厂商支持：直接问厂商要打了这两个 CVE 的包。国内很多云厂商和面板方已经在 10 月 21 日当天跟进了。宝塔 Linux 面板的 7.4.34、8.0.31、8.1.35 就属于这一类。

第二种，能自己编译：官方为 7.4、8.0、8.1 提供了最小源码回补分支。注意是「最小」回补，只修这两个漏洞，不含其他安全改进，编译前要评估影响。

第三种，5.4 到 7.3：没有任何官方修复，Wiz 的结论是这个区间每个版本都至少受一条影响。这时候只有两个选择——联系发行版要回补，或者按 NCSC 和 CERT-EU 的建议，先把受影响的对外服务从公网隔离或者直接下线，修好再恢复。

现实一点的判断是：老到 7.x 的项目，长期方案一定是迁移到 8.4 或 8.5 这样的受支持分支，8.2 也在 12 月 31 日到期，迁一次不如迁到位。

升级动作自检清单，8 项逐条打勾

1. 先做数据备份或服务器快照，留出回滚路径
2. 记录升级前每个 PHP 实例的版本、SAPI 类型、所在位置
3. 按分支升到对应修复版本，注意 8.2 分支用写死的镜像标签
4. 重启所有 PHP worker 与 Web 服务，不只是主站那一个
5. 用运行中进程的方式验证版本，别只看磁盘文件
6. 在测试环境先验证老源码在新版本上跑得通，尤其是用到大版本变更特性的项目
7. 回查 10 月 20 日之后的日志，确认没有异常请求与 worker 崩溃
8. 轮换数据库口令、API 密钥、会话密钥等运行进程能读到的凭据

升级完是不是就彻底安全了？

漏洞本身修掉了，但安全状态不一定干净。补丁不会替你清理已经落地的后门，也不会撤回已经泄露的凭据。

官方公告、国家互联网应急中心和 CERT-EU 的建议里都有同一条：10 月 20 日之后仍长时间对外的公网系统，在核查完成之前应按可能已被入侵处理。核查的最低动作是回查日志里有没有异常 multipart 请求、内存耗尽报错成片出现、HTTP 500 集中爆发、PHPSESSID 响应 cookie 异常偏大这些信号。

排查结论和凭据轮换记录都要留档：哪台机器、什么版本、什么时候升的、重启没重启、日志查出什么、哪些凭据换了。官方在发布后很快补发了最小回补分支，也是因为影响面比预想的大。同样地，一次干净的处置记录，下次再出公告时能省掉一半时间。

如果你手上的 PHP 源码需要重新部署环境、核对版本要求，或者想按模块挑一套维护状况更好的成品源码，可以先逛卓创源码网按品类对比，再对照[卓创源码网搭建服务价格表]（https://zhuochuangyun.cn/zcymwdjfwjgb/）确认部署与二次开发的工作量。拿不准该选哪套，加微信 ynzckj6666 或 QQ 3894381266，说明你的站点技术栈和当前 PHP 版本就行。