WordPress 7.1.2：一个「有条件」的高危漏洞，补丁发出 5 小时就有人在扫了

先看事实

9 月 22 日，WordPress 发布了 7.1.2。这是一次纯安全发布，官方的定性是「critical severity（严重级）」，并且明确建议立即升级。

要修的是一个未认证的路径穿越问题，编号 CVE-2026-87902（GHSA-7hp8-65ch-5whp），由安全研究员 Robert Ressl 负责任披露。官方的描述是：未认证的攻击者，在某些条件下，可以让「页面模板解析」把活动主题目录之外的、可读的本地 PHP 文件包含进来；如果服务器环境和当前主题的相关前置条件同时满足，这可能导致远程代码执行（RCE）。

几个值得记住的细节：

• 修复只动了一个文件：/wp-includes/template.php；
• 受影响范围是 4.7.0 到 7.1.1 的所有核心版本；
• 官方给每个还在维护的分支都打了回补，一路到 4.7.37，共 25 个分支；
• 4.6 及更早的版本，官方已经不再提供安全更新。

一个改一处核心代码就能修掉的漏洞，通常说明两件事：这个漏洞很「基础」，也意味着它很好被自动化利用。

真正让我在意的是时间线

有第三方安全汇总给出 CVSS v4.0 9.2 的评分，漏洞报告者公开了 PoC。但更扎眼的是补丁之后发生的事：

安全公司 Patchstack 观测到，补丁发布不到 5 小时就出现了侦察流量；到 9 月 23 日，已经观察到攻击者通过这个漏洞往磁盘里写 PHP 文件。 Patchstack 的说法很直白：攻击者可控内容的任意文件写入，就是代码执行。

它还没有被加进 CISA 的「已知被利用漏洞」目录——那是流程时间的问题，不是安全与否的判断标准。公开 PoC + 自动扫描 + 已经在写文件，这个组合足够说明优先级了。

「有条件」三个字，最容易被误读

官方的措辞里有一个 conditional：要同时满足服务器环境和当前主题的前置条件，才能走到 RCE。

很多人看到「有条件」就安心了：我的主题不是那样，我的服务器不特殊，我应该没事。

但攻击侧的运作方式恰好相反——扫描器就是用来替你验证条件的。它不需要预先知道哪个站满足条件，它批量试。而且「服务器环境」这部分你未必真的清楚：共享主机上的 PHP 扩展、容器镜像的编译参数、几年前为了某个插件改过的配置，都可能落在你从没看过的地方。

所以，「有条件」对我们只意味着一件事：它降低的是攻击者的命中率，不是你中招之后的后果。

顺便说，这已经是 9 月的又一次紧急发布

如果你也在维护 WordPress，把最近几次排在一起看：

• 9 月 17 日，7.1.1 是一次维护加安全发布，其中包含一个被第三方安全厂商称为 Comment2Shell 的存储型 XSS 链（按其报告，可进一步串联成服务端代码执行）；
• 9 月 22 日，就是这次的 7.1.2。

再往前，7 月 24 日有 7.0.2 的紧急补丁，8 月更是连续做了一轮紧急更新。

把这些放在一起，结论不是「WordPress 不行了」，而是另一件事：核心本身就是攻击面。 插件和主题的供应链问题我们聊过很多次，但核心代码同样在被持续研究——它的幸运之处在于修补机制成熟：出得快、回补到很老的版本、而且有自动后台更新。

我会怎么做

第一，能开自动后台更新就开着。这次从发布到被扫描只有几个小时，靠手动点后台的节奏根本跟不上。

第二，别停在旧分支的旧补丁上。你如果用 5.x、6.x，至少升到这次对应分支发布的补丁版；4.6 及更早的，认真考虑迁移。

第三，检查「有没有已经被写进去的东西」。最近留意主题目录、上传目录里陌生新增的 PHP 文件和时间戳；有日志的，翻一下这几天异常请求。

第四，判断不了的别硬撑，交给会看的人看。

我的判断是：这次事件对个人博主最大的提醒，其实不是漏洞本身，而是——维护这件事没法靠「我很小心」来完成。你不可能比扫描器更勤快。能把风险压下去的，只能是可自动执行的流程：自动更新、定期备份、尽量短的插件清单，以及出了事知道从哪查。

程序更新这件事，最贵的从来不是升级，而是以为不升也行。

（内容由AI生成，仅供参考）