WordPress CVE-2026-119977：升级到 7.1.4 前先封住 wp-content/upgrade

站长笔记2026-11-12发布 WarpEdit

WordPress 4.7 到 7.1.3 的核心升级流程里有一个竞态漏洞，编号 CVE-2026-119977。没登录的攻击者如果正好在升级的那几秒里访问到 wp-content/upgrade 里临时解压出的安装程序，就可能在服务器上执行代码。10 月 28 日发布的 WordPress 7.1.4 和各分支的安全版本已经修好，CISA 也在 11 月 3 日把它列入了已被利用漏洞目录。麻烦的是，从旧版本升到修复版的这一次升级，仍然由旧的升级代码来执行。所以正确顺序是：先在 Web 服务器层禁止访问 wp-content/upgrade，确认返回 403，再升级，升级后检查有没有被入侵的痕迹。下文的版本号、日期和配置写法核对于 2026 年 11 月 12 日。

WordPress CVE-2026-119977 封面：wp-content/upgrade 目录被标有 403 的闸门封住，旁边 7.1.4 升级进度条继续推进

先确认你的站在不在范围内

受影响的是 WordPress 4.7 到 7.1.3。修复版本都在 10 月 28 日同一天发布，最新分支是 7.1.4，旧分支各有对应的安全版本。WordPress.org 更新接口目前给出的修复版本如下：

你现在的分支	升级到（含本次修复）
7.1.x	7.1.4
7.0.x	7.0.8
6.9.x	6.9.11
6.8.x 到 6.1.x	6.8.12、6.7.11、6.6.11、6.5.14、6.4.14、6.3.14、6.2.15、6.1.16
6.0.x 到 5.0.x	6.0.18、5.9.20、5.8.19、5.7.21、5.6.23、5.5.24、5.4.25、5.3.27、5.2.30、5.1.28、5.0.31
4.9.x、4.8.x、4.7.x	4.9.35、4.8.34、4.7.39
4.6 及更早	没有修复版本，只能迁到受支持的版本

查看当前版本，可以在后台「仪表盘 → 更新」看，也可以在服务器上用 WP-CLI 跑 wp core version。开了自动后台更新的站，大概率已经被自动升到了分支修复版，但不要默认它一定升了，逐个站点看一眼更稳。

同一个 7.1.4 版本里还修了十几个其他问题，大多是存储型 XSS，其中不少需要先有投稿者、作者或编辑这类登录账号才能利用。之前写过的 WordPress 7.0.3 安全更新说明讲过怎么判断这类漏洞对自己的站影响有多大，思路是一样的。

漏洞是怎么发生的

用完整安装包做核心升级时，WordPress 会把新版本解压到 wp-content/upgrade/ 下面的一个临时目录，检查文件后复制到正式站点，最后删掉临时目录。问题出在解压和复制之间：

临时目录里是一份完整的 WordPress，包括安装向导 wp-admin/setup-config.php。大多数主机上，wp-content 能被外网访问，里面的 PHP 也能执行。
这份临时副本里没有 wp-config.php，安装向导会以为站点还没装好，直接进入配置流程，而且不需要登录。
攻击者如果抢在这几秒内访问安装向导，可以让它在临时目录里写出一份指向自己数据库的 wp-config.php。旧的升级代码复制文件时不会跳过这个文件，于是正式站点的配置会被覆盖。攻击者接着走安装流程建出第一个管理员，再上传插件执行 PHP。

发现这个漏洞的 Picus Security 研究员 Umut Bayram 还说明了另一条路：即使配置文件没被复制过去，攻击者也可以在临时副本被删除前，用自己的数据库把它装起来、登录，然后以 Web 服务器的权限执行 PHP，进而读写正式站点的文件。

时间窗口很短。Wordfence 在实验室里测到的窗口只有几秒，所以攻击者的做法是反复轮询。Wordfence 在 10 月 28 日上线防火墙规则后 9 分钟就拦到了第一批请求，其中两个最活跃的来源对一小批站点连续探测了约 14.5 个小时，Wordfence 认为这是在等这些站点升级。

评分上两边说法不一：Wordfence 在 CVE 记录里给的 CVSS 是 8.1，WordPress 自己的安全公告把它定为低危。不过 CISA 已经根据实际被利用的证据把它列入 KEV 目录，GitHub 上也出现了自称可用的利用代码（是否真的可用还没有定论）。对站长来说，不必纠结评分，按「正在被人试」来处理就行。

WordPress 核心升级流程示意：下载、解压到 wp-content/upgrade 临时目录、检查、复制、删除，解压到复制之间标出几秒攻击窗口 — 示意图：按 WordPress 安全公告、Picus Security 与 Wordfence 的公开说明整理，2026 年 11 月 12 日核对。窗口长短取决于服务器速度，Wordfence 实验室测得通常只有几秒。

为什么装修复版的这一次还要额外防

7.1.4 的修法是给临时目录起随机名字，补上目录里的 index.php 防护，并且复制时不再用临时目录里的 wp-config.php 覆盖正式配置。但是从旧版本升到 7.1.4 时，解压这一步是站点上现有的旧代码做的：

5.9 及以后的旧版本：临时目录按下载的安装包文件名命名，名字可以被预测，所以最后这一次升级仍然暴露。
4.4 到 5.8：旧代码会在目录名后加随机字符，除非站点通过报错信息之类的途径泄露了路径，否则不容易被猜到。
防覆盖的那部分修复在这次升级里已经生效，因为复制文件这一步用的是新代码。所以最后这次升级里，风险主要剩下「临时副本被装起来执行 PHP」这条路。

是完整包还是部分包也有影响。完整包一定带安装向导；部分包只包含两个版本之间改动的文件，不一定带。The Hacker News 在 11 月 6 日查过 WordPress.org 的更新服务：同分支内升级（比如 7.1.3 到 7.1.4）给的是部分包，跨分支（比如 7.0.7 到 7.1.4）只给完整包。另外，站点核心文件和官方校验值对不上，或者是重新安装时，WordPress 会退回完整包。研究员的结论是：关键不在完整包还是部分包，而在站点上已装的升级程序有没有被修复。

自动后台更新、后台点「立即更新」和 WP-CLI 的 wp core update 走的都是同一套升级代码，解压到同一个目录。换一种方式点升级并不能绕开这个窗口，真正有用的是先把目录挡住。

升级前：在服务器层封住 upgrade 目录

WordPress 升级时是直接在磁盘上读写 wp-content/upgrade 的，从来不需要通过网页访问它。所以在 Web 服务器上禁止访问这个路径，不会影响升级。规则要加在 Web 服务器配置或站点根目录，不能放进 upgrade 目录里面。

Nginx

在站点的 server 块里加一条：

location ^~ /wp-content/upgrade/ {
    deny all;
}

^~ 的意思是这条前缀匹配一旦命中，Nginx 就不再去检查正则 location（和它写在 location ~ \.php$ 前面还是后面无关），这样 /wp-content/upgrade/xxx.php 不会被转给 PHP-FPM。改完先 nginx -t 检查语法，再 nginx -s reload 或 systemctl reload nginx。用 CloudPanel、1Panel、aaPanel 这类面板管理站点的，规则加在该站点的 Nginx 配置里，保存后让面板重载即可。

Apache（能改虚拟主机配置）

在虚拟主机配置里给这个目录单独加一个块，路径换成你站点的实际路径：

<Directory "/var/www/example.com/wp-content/upgrade">
    Require all denied
</Directory>

改完 apachectl configtest，没问题再重载 Apache。

只能改 .htaccess 的虚拟主机

在 WordPress 根目录的 .htaccess 里加一行，放在 # BEGIN WordPress 那段重写规则的上面：

RedirectMatch 403 ^/wp-content/upgrade/

如果 WordPress 装在子目录里（比如 /blog/），路径前要带上子目录。不要在 wp-content/upgrade 里面放 .htaccess，旧的升级程序解压前会清空这个目录，文件会在最需要它的时候被删掉。

确认返回 403

规则生效与否，用请求结果说话：

curl -I https://example.com/wp-content/upgrade/
curl -I https://example.com/wp-content/upgrade/test.php

两条都应该返回 403。如果返回 200、出现目录列表，或者 test.php 返回的是 PHP 报错页，说明规则没生效或者顺序不对。站点前面有 CDN 或 WAF 的，也可以在那一层对这个路径加访问规则，但源站最好也挡一层，免得有人绕过 CDN 直接访问源站 IP。

终端中两条 curl -I 请求 wp-content/upgrade/ 和 upgrade/test.php，均返回 HTTP/1.1 403 Forbidden — 在本地测试环境（Nginx 1.26 + WordPress 7.1.4）加上文中的 location 规则后执行的实际输出，域名为 example.com。

再升级：后台更新或站外手动更新

目录挡住、确认 403 之后，就可以正常在后台更新，或者等自动更新跑完。Wordfence 的建议也是尽快升级，不要因为最后一次窗口而拖着不升：窗口只存在于升级进行的那段时间，升到修复版以后，以后的升级都会用随机目录名，临时目录里的 wp-config.php 也不会再被复制过去。

没法改服务器配置、又想完全避开这个窗口的，可以用研究员给的另一条路：在 Web 服务器不对外提供的目录里手动更新。

备份站点文件和数据库。
把新版本的安装包解压到网站根目录之外的位置。
把核心文件复制到站点，不动 wp-config.php 和 wp-content。
访问后台，按提示完成数据库更新。

这样整个过程中，外网能访问的目录里从来不会出现临时安装程序。备份和回滚的具体做法，可以参考之前的 WordPress 7.1 升级避坑指南。

用 Wordfence 的站点注意时间差：Premium、Care 和 Response 用户在 10 月 28 日就拿到了防护规则，免费版要到 11 月 27 日才有。而且这条规则需要防火墙处于优化后的 Extended Protection 模式，因为攻击请求直接访问临时目录里的独立 PHP 文件，不会加载你的 WordPress，普通插件层的防护看不到。Wordfence 自己也说，防火墙规则不能代替升级。

升级后：查一遍有没有被打过

升级只能堵住以后的攻击，修不了已经发生的入侵。Wordfence 建议，在漏洞公开后还停留在受影响版本上的站点，重点查这几样：

访问日志里对 wp-content/upgrade 下 PHP 文件的请求，特别是 setup-config.php 和 install.php。比如：grep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*（日志路径按你的环境调整，压缩的旧日志用 zgrep）。只有 403 的探测请求说明规则挡住了；出现 200 要重点看。
不认识的管理员账号：后台「用户」按角色筛选，或者 wp user list --role=administrator。
没人装过的插件：wp plugin list，对照自己的插件清单。
wp-content/upgrade 里多出来的 PHP 文件：find wp-content/upgrade -name "*.php"。两次升级之间这个目录通常是空的，或只有 index.php。

另外建议看一眼 wp-config.php 的修改时间和数据库连接参数。这个漏洞的一条利用路径就是用攻击者的数据库配置覆盖正式配置，如果升级后网站突然跳到安装界面，或者内容全没了，先别重新安装，直接按入侵处理：保留日志，从备份恢复，改掉数据库和管理员密码。

WordPress 后台「仪表盘 → 更新」页面显示当前版本 7.1.4，提示您使用的 WordPress 是最新版本 — 本地测试站点（WordPress 7.1.4 简体中文版）的「仪表盘 → 更新」页面，2026 年 11 月 12 日截图。

升级完以后，规则要撤掉吗

可以不撤。WordPress 本来就不需要通过网页访问 wp-content/upgrade，研究员也说明挡住它不会影响升级。升到修复版后，这个漏洞本身已经不需要这条规则了，但它几乎没有成本，留着可以多一层防护，以后再出类似问题时也不用临时去改。管理多个站点的，可以直接写进服务器的公共配置模板。

资料来源

原始资料（核对日期：2026 年 11 月 12 日）：

WordPress 7.1.4 发布公告（2026 年 10 月 28 日）：https://wordpress.org/news/2026/10/wordpress-7-1-4/
WordPress 版本发布列表（各分支修复版本与日期）：https://wordpress.org/download/releases/
NVD，CVE-2026-119977（2026 年 10 月 31 日发布）：https://nvd.nist.gov/vuln/detail/CVE-2026-119977
CISA 已被利用漏洞目录，CVE-2026-119977（2026 年 11 月 3 日加入）：https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-119977
Wordfence，Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core（2026 年 11 月）：https://www.wordfence.com/blog/2026/11/attackers-actively-probing-for-upgrade-window-rce-vulnerability-in-wordpress-core/
Picus Security，Umut Bayram 技术分析（2026 年 11 月 9 日更新）：https://www.picussecurity.com/resource/blog/cve-2026-119977-when-updating-wordpress-becomes-the-vulnerability
The Hacker News（2026 年 11 月 6 日）：https://thehackernews.com/2026/11/installing-fix-for-exploited-wordpress.html
比利时网络安全中心 CCB 预警（2026 年 11 月 3 日）：https://ccb.belgium.be/advisories/warning-remote-command-execution-wordpress-core-during-upgrade-window-actively-exploited