PHP 两个严重 RCE 漏洞深度复盘：影响范围与升级指南

一、事件概述：为什么一个「Hello World」也不安全

近期 PHP 官方披露了两个严重级别的远程代码执行（RCE）漏洞。这类漏洞的危险性在于：攻击面并不取决于业务代码的复杂度。只要服务器上运行的 PHP 版本低于已修复版本，哪怕站点首页只是一个静态的「Hello World」，同样处于可利用范围之内。

这一点需要特别强调。很多运营者习惯性地认为「我的业务逻辑很简单，没有用户输入，所以不会被攻击」，但在解释器层面的漏洞面前，这个假设不成立。漏洞存在于 PHP 引擎本身处理请求的方式中，而非某个应用层的功能缺陷。只要请求能够进入 PHP 执行流程，攻击者就有可能构造出触发条件。

因此，本次事件的应对重点不是「排查业务代码」，而是「确认运行时版本并及时升级」。

二、30 秒自查：你现在应该做什么

对于网站运营者而言，判断路径可以压缩到极短的时间内完成。以下按部署方式分类说明。

2.1 通过官方源码编译或使用官方二进制包

直接对照分支与补丁版本：

当前分支	需升级至
8.2	8.2.35 或以上
8.3	8.3.36 或以上
8.4	8.4.27 或以上
8.5	8.5.12 或以上

若当前版本低于上述任一对应值，应直接升级到官方补丁版本。这是最直接、风险最低的处理方式。

2.2 版本低于 8.2（含 8.1 及更早）

这些分支已进入生命周期终点，官方不再提供支持，也没有正式发布的修复版本。继续运行意味着不仅要面对本次漏洞，还要面对未来所有不再修复的安全问题。

建议尽快迁移到仍受支持的分支。迁移时需要注意扩展兼容性、废弃语法、依赖库版本约束等，建议先在预发布环境完成回归验证。

2.3 通过操作系统发行版包管理器安装

这是最容易被误判的一类场景。发行版维护者通常会将安全修复回溯移植（backport）到其打包的版本中，因此版本号可能「看起来仍然很旧」，但实际上已经包含修复。

正确的判断方式是查阅发行商发布的安全公告，确认该补丁是否已被纳入当前软件包。不要仅凭版本号数字大小下结论，也不要因为数字旧就盲目替换为官方源码包——后者可能破坏与系统其他组件的依赖关系。

三、升级之后：为什么必须重启常驻进程

这是本次事件中最容易被忽略、但后果最严重的一环。

仅替换磁盘上的 PHP 文件并不等于完成升级。PHP-FPM、Apache 的 mod_php 工作进程，以及任何常驻的 PHP 进程，都可能在内存中保留旧版本的执行状态。如果只更新文件而不重启 worker，旧进程仍会继续以旧逻辑处理请求。

本次漏洞的利用链具有跨请求特征。这意味着攻击者可能通过多个请求逐步构造并维持某种「脏状态」，而这类状态驻留在旧 worker 的内存中。只要旧 worker 没有被替换，升级就是无效的。

正确的收尾动作包括：

1. 重启 PHP-FPM 服务；
2. 重启 Web 服务器（如 Apache、Nginx 配合 FPM 的场景，重点仍是 FPM）；
3. 检查并重启任何以常驻方式运行的 PHP 进程，例如队列消费者、定时任务守护进程、WebSocket 服务等；
4. 确认进程启动时间已更新，必要时通过进程管理工具核对。

可以用类似下面的方式快速确认运行中的进程是否已重新加载：

# 查看 PHP-FPM 主进程启动时间
ps -o pid,lstart,cmd -C php-fpm
# 确认当前生效的 PHP 版本
php -v

四、漏洞发现过程：一次典型的多方独立上报

本次漏洞的发现过程值得单独讨论，因为它反映了当前安全研究的一种新形态：多个机构在相近时间窗口内，借助 AI 辅助平台独立定位到同一类问题。

4.1 时间线梳理

• 7 月 30 日：某安全研究机构启动针对 PHP 的安全审计。
• 8 月 11 日：该机构上报了一个无条件远程代码执行问题；同日，另一家机构的 AI 安全团队独立报告了同一根因。
• 8 月 19 日：某云厂商研究团队借助内部 AI 平台发现首个 PHP 漏洞。
• 8 月 20 日至 21 日：该团队分别在两个主流内容管理系统上验证了未授权 RCE 的可利用性。

4.2 修复与致谢

相关安全公告中列出的上报者来自多个独立团队，负责修复开发的是 PHP 核心维护者。多方交叉确认同一根因，说明这类问题并非偶然发现，而是具备一定系统性特征，值得后续持续关注。

4.3 对开发者的启示

AI 辅助代码审计正在显著缩短漏洞从「存在」到「被发现」的时间窗口。对防御方而言，这意味着：

• 不能再依赖「漏洞冷门所以没人会发现」的侥幸心理；
• 补丁发布与升级之间的时间差，正在成为最危险的暴露期；
• 自动化依赖管理与版本监控的价值进一步上升。

五、给不同角色的行动建议

对个人开发者：确认本地与线上运行版本，按分支对照表升级，重启所有 PHP 进程。若使用容器镜像，重新构建镜像而非仅更新容器内文件。

对运维团队：梳理全部 PHP 运行时清单，包括不直接对外提供服务的内部服务；对发行版包管理器安装的实例，以发行商公告为准；将「升级后重启」写入标准操作流程，避免遗漏。

对企业安全负责人：本次事件再次说明运行时组件的生命周期管理是基础防线。建议建立版本台账，对已停止支持的分支制定明确的下线时间表，并将跨请求类漏洞的防护纳入架构评审考量。

六、小结

本次两个严重 RCE 漏洞的核心信息可以归纳为三点：

1. 影响范围由 PHP 版本决定，与业务复杂度无关；
2. 修复动作必须包含进程重启，否则升级无效；
3. 发行版用户需以发行商安全公告为准，而非单纯比较版本号。

漏洞的发现方式正在变化，但防御的基本功没有变：知道自己在运行什么版本，能在补丁发布后快速完成升级，并确保升级真正生效。