WordPress路径穿越漏洞的修复边界

补丁发布之后，很多运维者会把“升到 7.1.2”当作事情的终点。这次事件的修复边界比版本号复杂：官方封堵的是核心模板解析流程中的目录穿越校验，而分支选择、验证深度、临时缓解的有效范围，全都落在补丁之外。

版本边界是一条分支线

CVE-2026-87902 的受影响区间从 4.7.0 延伸到 7.1.1，修复因此不是单一版本，而是按维护分支回溯的一组版本：7.1.2、7.0.6、6.9.9、4.7.37，中间分支各有对应的维护版，具体以官方公告为准。这意味着“是否已修复”不能只和一个版本号比对，而要先确认站点落在哪条维护线上。低于 4.7 的环境处在官方维护边界之外，找不到对应补丁，正确的判断是把它当作不再受安全维护的资产处理，迁移或重建，而不是在旧分支里翻找等效修复。

补丁修代码路径，但不收窄暴露面

目录穿越发生在核心层，不依赖插件开关，也没有可以关掉的配置项，这一点容易让人误以为边界已经闭合。但注册了自定义查询变量的插件会扩大可被构造的入口；主题是否带 page-templates 目录、PHP 版本是否偏旧、服务器是否装有 PEAR，影响的是能否进一步升级为代码执行，而不是是否受影响。补丁修的是代码路径，暴露面仍要自己收窄。CISA 将其纳入已知被利用漏洞目录，Patchstack 记录到补丁发布后数日内利用流量增长约十倍，攻击从探测转向实际写入文件——这个窗口比多数人预估的短。

临时缓解同样有边界。WAF 上的虚拟补丁、限制上传目录的脚本执行、关闭后台文件编辑，都作用在请求到达核心之前，规则被绕过即失效。它们买的是时间，不是修复，因此必须配上带责任人与截止日期的时间盒，否则缓解措施会沉淀成永久状态。回滚也一样：回到受影响版本，风险原样保留，它只是止损动作，后面仍要重新排期并加强日志监控。

判断一次处置是否真正结束，不看版本号是否匹配，而看三条线是否同时对上：当前分支是否取到对应修复版；核心完整性校验与上传目录、模板文件的痕迹排查是否走完；暂时无法更新时，缓解措施是否有明确的到期与升级路径。三条线之外的部分属于残余风险，应当被记录、被跟踪，而不是被当作已经解决。