排查 WordPress 路径穿越利用痕迹

一条带目录跳转特征的请求记录，很容易被直接读成入侵证据。在 CVE-2026-87902 这类漏洞上，这种推断跨过的环节太多。WordPress 项目于 2026 年 9 月 22 日披露的问题位于 get_page_template() 的模板解析过程，未认证即可触发，效果是让站点包含活动主题目录之外、服务器本地可读取的指定 .php 文件。注意后半句的限定：文件必须在目标服务器上存在且可被读取，攻击者无法凭此读取远程文件。路径穿越成立，和代码执行成立，是两件事。

先理清受影响范围

排查的起点是版本，不是日志。公告列出的受影响范围从 6.0.0 起延续至 7.1.1，涉及 6.7、6.8、6.9、7.0、7.1 等多个分支，修复版本为 7.1.2。仍运行更早 6.x 分支的站点，不能因为公告中未明确列出就默认自己安全，应当拿公告的完整版本清单和后台显示的实际安装版本逐项比对。同一台服务器上的其他 WordPress 实例也要一并盘点：一台机器挂多个站点时，漏掉一个就等于没修。

日志提供线索，不提供结论

Web 访问日志中值得留意的形态有三类：针对页面模板选择功能的异常参数、带目录跳转形式的请求，以及来源集中、节奏规律的探测行为。这些特征说明有人在试探入口，但它们本身不证明试探成功。文件是否真的被包含、被包含的对象是否可执行、执行后留下了什么，都需要结合文件变更记录另行取证，重点核查异常出现的 .php 文件及其位置是否落在活动主题目录之外。把探测流量和入侵证据记在同一栏里，后续处置就会失去判断依据。

状态要分层记录

更稳妥的做法是把结论拆成三项分别记录：运行受影响版本、日志中出现可疑请求、已确认被利用。三者对应完全不同的动作。前两项指向升级与加固，第三项才进入应急响应流程。升级之前先备份数据库、站点文件以及当前主题与插件配置，完成后检查前台页面、页面模板和关键后台功能；升级任务显示成功后，仍要回到站点确认实际运行的版本号，而不是相信任务状态。

暂时无法升级的站点，与其仓促宣布“已处理”，不如把原因、处理窗口和日志保留情况写清楚。公开可访问的站点在未认证触发条件下本就处于被探测的位置，能不能说清自己处在哪一层状态，比急着给出一句“没事”更有意义。