从版本检测到服务重启：PHP最新RCE漏洞完整修复实战-php教程-PHP中文网

我们以ubuntu上部署的php-fpm站点为例，完整的漏洞修复流程要走完版本盘点、补丁核对、安装更新、进程替换、业务验收这几步，每个环节都留好操作证据，才能确认修复真的落到了实际运行的服务上，而不是只更新了终端里默认的php版本，漏了线上跑的实例。

PHP 官方网站相关页面截图

准备阶段：把实例与配置对应起来

下面所有操作命令都以Ubuntu环境下的PHP 8.3 FPM为演示，你实际操作前得先核对自己环境里的真实服务名、配置路径，别上来就直接跑命令。先查站点反向代理转发到哪个套接字或者端口，顺着找到对应的进程池，绝对不能直接拿终端里默认PHP解释器的版本，就推定所有站点都用同一套运行环境。

操作前先把当前的软件包版本号、已装扩展、运行配置、数据库和上传目录都做好备份，提前确认好回滚方案。多节点集群的话先摘出灰度节点切走流量，单节点环境提前申请好维护窗口，所有变更都要明确划定业务写入的边界，避免更新过程中打断正在进行的订单提交或者文件写入操作。

阶段一：版本盘点之后，核对供应商安全包

# Ubuntu 8.3 FPM 的只读检查示例
php -v
php-fpm8.3 -v
dpkg-query -W php8.3-fpm php8.3-common php8.3-cli
apt-cache policy php8.3-fpm
systemctl show php8.3-fpm --property=ExecStart,MainPID

Ubuntu 官方漏洞说明中的软件包版本检查方法

发行版维护包经常会在旧的基础版本上回补安全修复，不会直接跳大版本号，所以你得对照官方安全公告里的完整包号来校验，只有直接用PHP官方上游发行包的场景，才按各分支的修复最低版本要求核对。要是碰到来源不明的PHP执行文件，得顺着安装记录一路溯源，不能随便标记成已修复。

阶段二：安装前检查依赖变更

刷新本地软件包索引，确认安全更新源能正常访问，跑模拟升级命令先看会触发哪些变更，重点留意有没有扩展被意外移除、服务被替换、配置文件冲突的情况，发现异常先把依赖问题解决完再往下走。
应用发行商提供的修复包，记得把包管理器输出的所有变更记录都留存好，碰到系统提示要不要覆盖配置文件的情况，先对比新旧配置的差异，别直接默认覆盖，把业务之前配好的监听规则、权限设置搞丢。
测试配置文件和扩展能不能正常加载，确认服务满足启动条件，再进下一阶段的进程替换操作。

sudo apt update
apt-get -s upgrade
# 人工核对模拟清单后再安装
sudo apt upgrade
sudo php-fpm8.3 -t

这次的漏洞根源是PHP解释器的异常内存处理逻辑，还有跨请求状态重置的问题，只在业务层改代码不可能把旧引擎变成修复后的版本。旧版本异常退出的时候没清理的引用，很可能被同一个工作进程处理后续请求的时候复用，补丁改的是解释器底层的内部处理逻辑，光清业务的字节码缓存完全替代不了打补丁的作用。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

而且安装完新的修复文件之后，内存里还在处理请求的旧进程用的还是旧代码，这就是下一阶段重启替换进程绝对不能省的原因。

阶段三：替换工作进程，再恢复流量

sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm
systemctl show php8.3-fpm --property=MainPID,ExecMainStartTimestamp
sudo journalctl -u php8.3-fpm -n 50 --no-pager

网站通过代理连接FPM的架构，重点要对应到站点绑定的那个进程池；要是PHP是直接跑在Apache模块里的，配置测试没问题之后要把整个Apache进程完整替换掉。容器化部署的项目直接更新镜像重新创建实例就行，别硬套系统包管理的服务重启命令。

环境	替换对象	确认依据
FPM 系统服务	实际池及其旧进程	包号、进程和网页环境
Apache 模块	加载模块的服务器进程	新进程与模块对应关系
容器运行时	新镜像创建的全部副本	摘要与内部解释器版本

阶段四：用最小证据验收真实运行环境

下面给的脚本只会读取必要的版本、配置和扩展指纹，你把它存成audit.php之后，用目标环境的PHP解释器直接跑一遍做本地校验；线上网页环境的话，要放到受保护的诊断入口里检查，绝对别长期把完整环境信息暴露在公网。

PHP 官方函数文档说明怎样读取当前加载的配置文件

<?php // 完整只读检查，故意把上游门槛与最终修复结论分开。
$floors=['8.2'=>'8.2.35','8.3'=>'8.3.36','8.4'=>'8.4.27','8.5'=>'8.5.12'];
$branch=PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
$floor=$floors[$branch] ?? null;
$extensions=get_loaded_extensions(); sort($extensions);
echo json_encode(['php'=>PHP_VERSION,'sapi'=>PHP_SAPI,
    'ini'=>php_ini_loaded_file() ?: '(none)',
    'upstream_floor'=>$floor,
    'upstream_floor_met'=>$floor !== null && version_compare(PHP_VERSION,$floor,'>='),
    'extensions_sha256'=>hash('sha256',implode(',', $extensions)),
    'final_verdict'=>'requires vendor package, process and business evidence'],
    JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;

这个样例我们是在本地PHP 8.5.10的WebAssembly环境里跑的，输出结果如实显示没达到这个分支的上游修复门槛，我们这里没做任何Linux系统包升级或者服务重启操作，也不会放虚构的修复成功截图，你在自己的目标服务器上验收的时候，必须拿到完整的软件包版本、进程替换的双重证据才算数。

只读示例的真实运行输出：只读检查将版本门槛与最终验收结论分开输出