PHP运行时漏洞修复验证方法

PHP2Shell 这类运行时漏洞最容易被误判的地方，是把“修好了”等同于“升级了”。补丁落地只是起点，真正的验证要回答三个问题：请求实际由哪个运行时处理、修复是否覆盖全部执行路径、缓解措施是否只挡住了攻击而没有挡住业务。CVE-2026-109618 与 CVE-2026-109619 的 CVSS v4.0 评分均为 9.2，且攻击尝试在补丁发布前就已出现，这意味着验证必须带着“可能已被打过”的假设去做，而不是升级完就收工。

验证的第一步是确认生效对象。后台“站点健康”显示的版本可能是 CLI 版本或缓存结果，不能作为结论。应以临时探针页输出为准，同时拿到版本号、SAPI 类型和实际加载的 ini 文件路径。这三个字段缺一不可：版本号决定是否在受影响区间，SAPI 决定配置该改在 FPM pool 还是 Apache，ini 路径决定“改了没生效”的根因排查方向。探针核对完立即删除，它本身就是一个信息泄露点。

第二步是验证覆盖面，而不是验证单点。同一台服务器上的 CLI、计划任务、队列 worker、容器基础镜像，都可能停留在旧版本。主站探针显示已修复，并不代表 crontab 里那个统计脚本也安全。验证方式是逐项取实际解释器版本，而不是看配置文件里写了什么。共享主机环境下拿不到 root，就只能以主机商的书面答复作为凭据，口头确认在复盘时没有价值。

第三步是验证缓解措施的有效性与副作用。访问限制类规则要白名单内外各测一次，确认 403 与 200 的边界符合预期；上传与请求体限制不能只改配置就宣布完成，必须用探针确认 ini_get 返回的是新值，再实测一次正常上传。这里有个高频错误：用 ini_set() 或 .user.ini 设置这类参数，加载时机太晚，对运行时行为不起作用，配置看起来改了，实际没有生效。WAF 规则则应先在检测模式跑一个观察窗口，确认后台表单和上传接口没有被误杀，再切阻断。

第四步是验证“之前有没有被利用”。缓解只降低后续风险，不能回溯。需要查 Web 访问日志中针对 PHP 入口的异常 POST、FPM 错误日志里的致命错误，以及上传目录中近期出现的可执行文件。预期结果是空输出；一旦命中，先隔离并保留副本，再清理，直接删除会破坏证据链。同时回看同一时间窗口的访问日志，还原入口。

最后是验证回滚路径是否真的可用。每一项变更都应有明确的验证方法、观察窗口和回滚方式，配置文件保留带日期的副本，回滚时直接覆盖，比凭记忆改回去可靠。观察窗口内按重要性盯住首页、登录后台、表单提交、媒体上传和计划任务，这几条覆盖了绝大多数会被配置变更打断的功能。

需要强调的是，WordPress 核心、主题、插件的更新解决不了 PHP 层面的问题，这是本次事件中最容易混淆的一点。两者是独立的处理线，处理了其中一条，不等于已经收口。