WordPress 核心升级爆 RCE 漏洞：先封目录再安全更新

给 WordPress 站点做维护的人，大多有个根深蒂固的习惯：一看到后台蹦出核心更新提示，点一下「立即更新」就完事。可 2026 年 10 月底爆出的这个漏洞，恰恰把「更新」本身变成了最危险的时刻——攻击者不需要你点任何按钮，只要趁你升级的那十几秒，就能在服务器上远程执行代码。

这个漏洞到底特殊在哪

漏洞编号 CVE-2026-119977，类型是「条件竞争」（CWE-367），CVSS 评分 8.1，属于高危。它影响的不是某个插件，而是 WordPress 核心本身：从 4.7 到 7.1.3 的几乎所有版本都中招。更麻烦的是，美国网络安全和基础设施安全局（CISA）已经在 2026 年 11 月 3 日把它加进了「已被利用漏洞目录」（KEV），这意味着官方认定它已经在真实攻击中被使用，必须尽快处置。

普通漏洞大多是「你访问某个页面，攻击者趁虚而入」；这个漏洞的触发点却在升级过程里。WordPress 做全量包核心升级时，会先把新版本文件解压到一个路径固定、而且 Web 服务器能直接访问的临时目录——/wp-content/upgrade/。从解压完成到升级收尾之间，存在一个短暂的「升级窗口期」，这段时间里那些临时文件处于没有保护的状态。未认证的攻击者只需要在窗口期内，持续去访问这个可预测的路径、和升级流程抢时间，就能抢先篡改升级过程，进而在服务器上写入 webshell、拿到控制权。

换句话说：你越积极地「点更新」，在某些攻击者的脚本里，反而越接近被拿下。

官方怎么修的

WordPress 官方在 2026 年 10 月 28 日发布了安全版 7.1.4，修复了这个问题，并且把补丁回滚到了所有还在安全维护期的分支。各分支对应的修复版本如下：

1. 7.1 分支 → 7.1.4
2. 7.0 分支 → 7.0.8
3. 6.9 分支 → 6.9.11
4. 6.8 分支 → 6.8.12
5. 6.7 分支 → 6.7.11
6. 6.6 分支 → 6.6.11
7. 6.5 分支 → 6.5.14
8. 6.4 及更早分支 → 6.4.14 一路回退到 4.7.39

官方公告地址：https://wordpress.org/news/2026/10/wordpress-7-1-4/ 。如果你开启了自动后台更新，建议先去后台「更新」页确认版本号真的已经变成修复版，而不是只看了「已安排更新」的提示。

为什么「直接更新」反而可能中招

关键点在于：执行更新的，是你那套还没打补丁的旧代码。也就是说，在你点更新的那一刻，站点用的还是漏洞版本；补丁要等这次升级跑完才生效。这就带来一个尴尬的局面——最该打补丁的时候，恰恰是用着有洞的代码去操作。

安全厂商观察到，补丁发布后的头 21 小时里，针对升级路径的恶意请求就超过了 1.8 万次。虽然截至公告时还没有确认成功的入侵案例，但攻击尝试已经铺开，靠「赌它打不中」显然不行。

安全升级的四步顺序

按漏洞原理，正确的顺序是「先关门、再更新、最后核对」，而不是「先更新、再祈祷」：

1. 备份：先把整站文件和数据库完整备份。这一步什么时候都别省，它决定了你最坏情况下的退路。
2. 封目录：在升级之前，通过 Web 服务器配置拒绝外部访问 /wp-content/upgrade/。Nginx 加一句 location ^~ /wp-content/upgrade/ { deny all; }，Apache 对该目录设 Require all denied。这个动作不依赖 WordPress 内部，是版本无关的硬防护，也能挡住升级窗口期的竞争请求。
3. 更新：在后台点「立即更新」，升到 7.1.4 或你所在分支的修复版。托管环境就先和主机商确认他们是否已经封了那个目录、是否已经更新。
4. 核对：更新完别急着关页面，确认后台版本号、检查是否有异常管理员账号、顺手翻一下访问日志里有没有命中 wp-content/upgrade/.*setup-config.php 这种不该出现的请求痕迹。

几个容易忽略的细节

临时缓解不等于修好。如果暂时不能更新，封 upgrade 目录是最实在的降险手段，但它只是堵住了被利用的路径，没有消灭漏洞本身，最终还是要走版本升级。另外，使用安全插件只能保护「正在运行的站点」，保护不了升级窗口里那一份临时解压文件——所以封目录必须落在服务器或主机配置层，而不是靠插件。

如果你手上有多台客户站，这周值得统一发一条提醒：先备份、先封目录、再更新。一次带着备份和封目录的更新，比事后解释一次事故要容易得多。

我的看法

这个漏洞最反直觉的地方，是它把「做好运维」的动作本身变成了攻击面。对站长来说，结论其实很朴素：更新一定要做，但别在没有任何防护的情况下盲目点。先把 /wp-content/upgrade/ 这道门在服务器层关上，再让旧代码去跑那最后一次升级，等补丁真正落地，你就从「升级窗口里的猎物」变成了「已经关门的人」。对那些自己管服务器、又长期没动过升级策略的人，这周花十分钟把这条规则写进配置，回报率远超它的成本。