打补丁之后：确认修复已经在运行

为什么只看已安装的版本不够

升级软件包只是替换了磁盘上的文件。PHP-FPM 主进程、带 mod_php 的 Apache 和 LiteSpeed 会把旧代码留在内存里，直到重启为止。于是命令行里显示的是新版本，处理请求的却还是旧版本。

1. 重启每一个 PHP worker

sudo systemctl restart php8.3-fpm     # 每个在用的版本都要重启：php8.2-fpm、php8.4-fpm …
sudo systemctl restart apache2        # mod_php；RHEL 上是 httpd
sudo systemctl restart lsws           # LiteSpeed

在 cPanel、Plesk 这类面板上，同时装着好几个 PHP 版本很常见。凡是给站点提供服务的版本，每个都要重启。

容器的话，要基于已修复的标签重新构建镜像，并替换掉每一个正在运行的容器。只重启旧容器，跑起来的还是旧的 PHP。

2. 从 Web 这一侧确认运行的版本

在某个站点的 Web 根目录里放一个临时文件。

<?php echo PHP_VERSION, ' ', PHP_SAPI;

用浏览器打开它，记下输出，然后删掉这个文件。正常应该看到 8.3.36 fpm-fcgi 之类的结果。如果用的是发行版的软件包，版本号可能还是较低的那个，这时到软件包的 changelog 里确认修复。

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

3. 有用的设置保留下来

如果你不用上传进度功能，PHP 项目建议打完补丁后仍然保留 session.upload_progress.enabled = 0。对大多数站点来说，这样做没有任何代价。

4. 查看日志，但别轻易下结论

打开 log_errors，配合 error_reporting = E_ALL，再翻看打补丁之前那几天的 PHP 和 Web 服务器日志。重点看 worker 崩溃、请求刚开始就出现的内存错误，以及异常的上传。

日志干净不等于没事

安全通告没有提到已发现在野利用。不过针对这些漏洞的攻击可能发生在 PHP 写日志之前，所以日志安静并不能证明什么都没发生。如果确实看到了被入侵的迹象，请找专业的应急响应公司。我们不做取证。

完成

当每台服务器、每个给站点提供服务的 PHP 版本，从 Web 这一侧报告出来的都是已修复的构建，PHP2Shell 这件事就处理完了。把日期和版本记下来，客户和审计人员会问。

最后审阅：2026年10月22日