PHP 安全更新后，怎样确认网站已经用上补丁

先找到处理网站请求的 PHP

一台服务器上可以同时装着几个 PHP 版本。终端执行 php -v 看到的是默认命令，网站绑定的 FPM 可能是另一个版本。排查时先看站点配置指向哪个服务、哪个池，再查对应进程。

10 月 21 日的 PHP 安全通告给出了 8.5.12、8.4.27、8.3.36 和 8.2.35 四个修复版本。如果使用发行版或商业支持包，还要查供应商是否回移了补丁，不能只按版本号大小判断。

包更新了，进程也要确认

更新软件包后，检查原来的服务是否已重载或重启，再验证网站的主要功能。不要为了查看版本，在公网长期保留 phpinfo 页面。

还有一项 session 配置提示

PHP 官网随后补充了 session upload progress 的说明：应用先将 session.serialize_handler 配为 php_binary 或 php_serialize，又在 session_start() 前用 ini_set() 切回 php，同时仍启用上传进度，才可能触发这条特殊路径。

官网建议在下次常规修复发布前设置 session.upload_progress.enabled=0；已按先前公告关闭的，应保留该缓解措施。官网也说明，不在运行时切换序列化处理器的应用可以继续启用此功能。处理前查清应用配置，随后跟进正式修复说明。

PHP 更新后，还要回头查入侵痕迹

PHP2Shell 已不只是理论风险。AWS 报告，蜜罐在 10 月 17 日就观察到相关利用尝试；Dream 后来报告，攻击者在特定 PAN-OS 防火墙管理接口中串联 PHP 漏洞与内核提权，取得了设备权限。AWS 的尝试不等于这批设备在 10 月 17 日已经失陷；关于事件、厂商修复和影响范围，本站另有“PHP2Shell 不只打网站”分析。

更新可以关闭漏洞入口，但不会自动删除已经留下的后门。对曾暴露在外的 PHP 服务，结合自己的访问与认证日志、异常账号和配置变更，按事件响应流程回溯至少从 10 月 17 日起的可疑活动。单条攻击请求不等于成功入侵，也不应公开保存 phpinfo 页面来验证版本。

交接时留下这些信息

一份有用的处置记录，至少能回答下面四个问题。缺少的信息直接写待核实。

• 这个站点实际用了哪个 PHP 服务和软件包？
• 对应哪个安全通告，补丁来自哪里？
• 什么时候更新、重载，哪些功能已经检查？
• 还有哪些配置或供应商说明需要跟进？