PHP高危漏洞修复后，如何确认服务器真的安全？5步自查清单

昨天关注了 PHP 的两个高危安全漏洞后，很多开发者最关心的其实不是漏洞原理，而是一个更实际的问题：

我的服务器到底有没有受到影响？升级之后，真的修复了吗？

尤其是使用 PHP-FPM、Nginx、Apache，或者运行 WordPress、Laravel 等 PHP 应用的开发者，仅仅看到服务器上安装了某个 PHP 版本，并不能证明线上网站已经使用了修复版本。

这篇文章整理一套适合开发者和运维人员执行的 PHP 安全自查流程。建议收藏，排查线上环境时可以逐项核对。

一、先确认：这次漏洞影响哪些环境？

PHP 官方在 2026 年 10 月 21 日发布安全公告，修复了两个可能导致未认证远程代码执行的高危漏洞：

• CVE-2026-109618：与内存不足处理过程中的内存安全问题有关。

• CVE-2026-109619：与请求处理过程中残留的内部状态有关。

官方公布的修复版本如下：

如果你使用的是上述分支的旧版本，应尽快按照官方公告和系统发行版的更新方式进行修复。

PHP 8.1 及更早的版本已经不在 PHP 官方常规安全维护范围内。部分操作系统或第三方维护方可能提供回补补丁，因此不能只根据版本号判断，应该同时核对供应商公告。

参考：PHP 官方 2026 年安全公告
PHP: News Archive - 2026

二、第一步：查看命令行 PHP 版本

登录服务器后，执行：

php -v

这条命令会显示当前命令行使用的 PHP 版本。

例如：

PHP 8.3.35 (cli)

如果你的环境显示的是受影响的旧版本，就需要进一步核对更新情况。

但这里有一个很容易忽略的问题：

命令行 PHP 版本不一定等于网站实际运行的 PHP 版本。

一台服务器上可能同时存在多个 PHP 版本，命令行使用 PHP 8.3，网站却通过另一个 PHP-FPM 服务运行。

所以，这一步只能作为初步检查，不能单独作为修复完成的证明。

三、第二步：检查 PHP-FPM 实际运行情况

如果网站使用 PHP-FPM，可以先查看系统中运行的相关服务。

在 systemd 系统中，可以执行：

systemctl list-units --type=service --all | grep -E 'php.*fpm'

不同 Linux 发行版、软件包来源和安装方式，服务名称可能不同。

例如，某些环境使用带版本号的服务名，另一些环境则使用自定义服务名称。

确认服务后，再根据实际服务名称查看状态：

systemctl status php8.3-fpm

注意：上面的服务名称只是示例，请替换成服务器上的真实名称。

接下来还需要确认：

1. Nginx 或 Apache 实际连接的是哪个 PHP-FPM 服务。

2. 这个服务对应的 PHP 二进制文件和安装包版本是什么。

3. 更新后，相关 PHP 工作进程是否已经按正确方式重启或重新加载。

不要仅凭服务处于 active (running) 状态，就认为漏洞已经修复。服务正常运行与使用安全版本，是两个不同的检查目标。

四、第三步：确认 Web 服务器使用的版本

这是整个自查过程中非常重要的一步。

对于 Nginx + PHP-FPM，需要检查 Nginx 配置中 PHP 请求转发到哪个 FastCGI 地址或 Unix Socket，再确认对应的 FPM 实例使用什么版本。

可以先检查 Nginx 的有效配置：

nginx -T

该命令会输出较多配置内容。查看时注意保护配置中的敏感信息，不要直接把完整输出公开到网上。

对于 Apache 环境，需要进一步确认使用的是 PHP-FPM，还是通过 mod_php 加载 PHP。

如果使用 mod_php，就不能简单地根据某个 PHP-FPM 服务的版本判断网站是否安全。

另外，如果服务器使用 Docker、容器镜像或面板管理的 PHP 环境，也需要检查实际部署的镜像、运行中的容器和对应的 PHP 版本。

真正要确认的是：处理外部 Web 请求的 PHP 运行环境，是否已经得到修复。

五、第四步：更新后进行验证

确认需要升级后，建议遵循以下流程：

1. 备份必要的配置和业务数据，并确认备份可以恢复。

2. 根据操作系统或软件供应商提供的安全更新进行升级。

3. 确认实际运行环境已经切换到修复版本，或供应商明确说明已经回补相关安全补丁。

4. 按照部署方式重启或重新加载必要的服务。

5. 检查网站首页、登录、文件上传、后台任务、数据库连接等关键业务功能。

6. 检查 PHP、Web 服务器和应用日志，确认没有明显异常。

对于通过 Linux 发行版安装 PHP 的环境，不要直接套用其他发行版的安装命令。不同系统的软件包名称、仓库和补丁发布方式可能不同。

如果是生产服务器，建议先在测试环境验证，再按变更流程部署。

六、第五步：检查是否存在异常迹象

升级能够修复已知漏洞，但不能自动证明此前没有发生过入侵。

如果服务器在漏洞修复前暴露于公网，建议进一步检查：

• Web 访问日志中是否存在异常请求峰值或可疑请求模式。

• PHP 应用是否出现不明文件、陌生脚本或异常代码变更。

• 是否出现不明系统进程、账户或计划任务。

• 是否存在异常的外联连接或无法解释的资源占用。

• 管理后台、SSH 和应用账户是否有异常登录记录。

以上现象都需要结合正常业务行为判断，单独出现某一项并不必然代表遭到攻击。

如果怀疑已经被入侵，不要只删除可疑文件就宣布恢复安全。应保留相关日志和证据，检查凭据、持久化机制及受影响范围，并按照事件响应流程处理。

七、这次漏洞修复，最容易犯的三个错误

错误一：只检查 php -v。

命令行版本可能与 Web 运行环境不同，必须继续核对实际服务。

错误二：升级后不检查服务和业务。

软件包更新完成，不等于所有运行中的进程都已经切换到修复版本。

错误三：把临时缓解当成彻底修复。

PHP 官方明确指出，针对这两个漏洞没有能够完全替代升级的缓解措施。配置调整只能降低部分风险，不能替代安装适用的安全修复版本。

参考：
PHP: News Archive - 2026

八、最后整理一份自查清单

可以把下面这份清单用于自己的服务器维护记录：

• 已确认命令行 PHP 版本。

• 已确认网站实际使用的 PHP 运行环境。

• 已确认 PHP-FPM、Apache 或其他运行方式。

• 已核对官方修复版本或供应商回补公告。

• 已完成适用的安全更新。

• 已确认相关服务和工作进程使用修复后的环境。

• 已检查网站核心功能。

• 已检查相关日志和异常迹象。

• 已记录更新时间、版本、验证结果和回滚方案。

PHP 安全维护最重要的不是看到漏洞新闻后马上转发，而是把公告转化为可以执行、可以验证、可以复盘的维护流程。

如果你负责维护 PHP 网站，建议把这份清单纳入日常运维流程。遇到高危漏洞时，按照相同方法核对影响范围、更新状态和验证结果，比单纯查看版本号更加可靠。

参考资料

1. PHP 官方安全公告：PHP: News Archive - 2026

2. PHP 官方发布公告：php.announce: [ANNOUNCE] PHP 8.5.12 Released

本文用于防御性安全检查与运维参考。实际升级方式应以所使用的操作系统、软件供应商和部署环境的官方说明为准。