核对php网站是否完成php2shell相关修补，应以实际运行环境是否包含完整补丁为准，不能只看控制面板中的版本名称，也不能把关闭某个配置项当成通用修复。上游对应修补版本包括8.2.35、8.3.36、8.4.27和8.5.12，发行商回补的软件包则需要按其安全公告判断。
先识别网站实际使用的PHP
命令行PHP、Web服务器模块与PHP-FPM可能不是同一套程序。终端可先查看命令行版本：
php -v php --ini
这两条命令只能帮助确认当前Shell调用的PHP与配置，不能直接证明网站正在使用同一版本。还需结合站点配置、FPM服务及实际部署路径，确认处理网页请求的运行入口。如果为了检查临时建立版本查看页面，应限制访问并在完成后移除，避免长期公开环境细节。使用面板维护的多版本环境，要逐个核对实际绑定的站点。
对照上游补丁或发行商修订
源码部署可按所用分支核对包含修补的版本；发行版软件包可能保留原有主版本字符串、通过修订号回补安全修正，因此应查看具体安全公告与包版本。处于停止维护状态的旧分支不能只靠比较补丁号判断长期安全性。即使有个别回补，也不代表该分支重新获得完整维护，应结合迁移计划处理。
PHP安全公告列出的对应修补版本
更新后让服务使用新程序
替换软件包后，仍需按部署方式重启或重新载入相关服务，使工作进程实际使用更新后的程序。只完成文件替换、旧进程继续运行，不能视为检查闭环。验证时检查站点基本访问、登录、上传及原有业务流程，同时查看服务和应用日志。安全修补后的功能回归与是否包含补丁，是两个都需要确认的环节。
立即学习“PHP免费学习笔记（深入）”；
配置缓解不能替代完整更新
该类问题涉及跨请求残留状态，具体可达路径与应用、扩展和运行方式有关。某项配置可能减少特定触发路径，却不覆盖所有情况；关闭错误显示或日志同样不能作为已经安全的证明。检查记录应包含运行入口、软件包或构建版本、补丁依据和服务更新时间。完成这些核对后，再继续清理不必要的配置和异常日志，避免仅凭“目前没有报错”判断风险已经消失。
