CVE-2026-119977：WordPress 核心升级竞态漏洞，黑客可趁更新窗口远程执行代码

摘要： 2026 年 10 月，WordPress 修复了一项影响核心升级流程的远程代码执行漏洞 CVE-2026-119977，CVSS 3。1 评分为 8。1。攻击者可能利用升级期间临时文件目录可被访问的问题，在无需登录的情况下执行服务器端代码。CISA 已确认该漏洞存在实际利用活动。本文介绍漏洞原理、受影响版本、自查方法及修复措施。

一、漏洞概述

给网站升级，本来是为了修复安全问题。但 CVE-2026-119977 揭示了一个容易被忽略的风险：升级过程本身也可能产生短暂的攻击入口。

2026 年 10 月 28 日，WordPress 发布 7。1。4 安全版本，修复了核心升级过程中存在的竞态条件。10 月 29 日，WordPress 官方 GitHub 安全公告进一步解释了漏洞的触发场景。

这里有一个评分差异值得说明：WordPress 官方 GitHub 公告将该问题标为 Low，而 GitHub Advisory Database 对 CVE-2026-119977 给出的 CVSS 3。1 评分为 8。1（High）。官方的较低定级可能与攻击窗口短暂有关，但公告没有详细解释评分差异。

二、漏洞原理：为什么升级期间会出现攻击入口？

WordPress 的核心升级过程，需要先准备新版本文件，再将它们替换到现有网站目录。

对于使用完整安装包的升级，WordPress 会将新文件解压到 wp-content/upgrade/ 下的临时目录。

正常流程大致如下：

管理员或自动更新程序触发升级
             |
             v
下载 WordPress 新版本安装包
             |
             v
解压到临时升级目录
             |
             v
检查并准备新版本文件
             |
             v
替换正式网站文件
             |
             v
清理临时目录

问题出现在第三步。

1。 临时升级目录具有可预测性

旧版本 WordPress 使用的临时升级目录路径具有一定规律，而且该目录可能位于 Web 服务器能够直接访问的位置。

这意味着，攻击者可能在网站升级期间，通过 HTTP 请求访问正在解压的新版本文件。

例如，临时目录中可能出现如下结构：

wp-content/
└── upgrade/
    └── [临时目录]/
        └── wordpress/
            ├── wp-admin/
            │   └── setup-config。php
            ├── wp-includes/
            └── 。。。

这里的 setup-config。php 是 WordPress 安装配置程序的一部分。

正常安装时，它负责引导用户配置网站。对于已经运行的网站，这类安装程序通常不应该通过另一份临时核心文件被外部访问。

然而，在旧版完整包升级过程中，临时目录中的安装文件可能短暂暴露。

2。 TOCTOU 竞态条件

TOCTOU 是 Time-of-check to Time-of-use 的缩写，中文通常称为“检查时与使用时之间的竞态条件”。

它描述了一类程序错误：程序先检查某个资源的状态，随后使用该资源，但在这两个动作之间，资源的状态或可访问条件发生了变化。

对于此次漏洞，关键是升级文件从解压到清理之间存在一个时间窗口。

攻击者可以尝试在这一窗口内访问临时安装文件。

WordPress 升级程序          外部攻击者
       |                       |
开始解压完整安装包             |
       |                       |
临时目录出现                   |
       |                       |
       |                 猜测临时目录路径
       |                       |
       |                 请求安装程序
       |                       |
继续执行升级                   |
       |                       |
       |                 触发异常安装流程
       |                       |
       |                 可能执行服务器端代码
       |                       |
清理临时目录                   |

WordPress 官方安全公告确认，攻击者如果在完整包解压期间赢得这一竞争，就可能实现远程代码执行。

3。 为什么可能绕过 WordPress 安全插件？

许多 WordPress 安全插件依赖正式网站的 WordPress 初始化过程加载。

如果攻击者直接访问临时升级目录中的独立 PHP 文件，请求可能绕过正式站点中的部分插件防护逻辑。

因此，即使网站已经安装 Wordfence 等安全插件，仍需要检查 Web 服务器对临时目录的访问限制。

不过，具体攻击能否成功，还取决于服务器配置、升级时机及临时文件的实际状态。

三、哪些版本受到影响？

根据 WordPress 官方 GitHub 安全公告，漏洞影响从 4。7 到 7。1。3 的多个分支。官方已经将修复补丁回移到较早版本。

例如，5。9 分支的修复版本为 5。9。20，4。7 分支为 4。7。39。

这些版本号来自 WordPress 项目维护者发布的官方安全公告。

对于长期没有升级的 WordPress 网站，建议优先迁移到当前受支持的主版本，以便获得后续安全维护。

四、哪些网站管理员需要担心？

此次漏洞主要涉及自行部署 WordPress 核心程序的网站。

攻击成功需要同时满足几个条件：目标运行受影响版本、发生完整安装包升级、临时目录能够通过网络访问，以及攻击者能够在短暂的升级窗口内触发相关文件。

尤其需要关注自动更新。

很多网站会在凌晨自动执行核心升级。攻击者如果持续监测特定网站，就可能等待其进入升级阶段。

网站平时运行正常，并不代表升级期间不存在风险。

五、风险现状：已经出现实际利用活动

1。 攻击难度有多高？

该漏洞的 CVSS 3。1 向量为：

CVSS：3。1/AV：N/AC：H/PR：N/UI：N/S：U/C：H/I：H/A：H

其中：

• AV：N：可通过网络触发。
• AC：H：攻击复杂度高。
• PR：N：无需已有账户权限。
• UI：N：无需受害者交互。

攻击复杂度较高，主要因为攻击者需要准确命中升级窗口。

不过，自动化扫描可以反复尝试，降低人工操作成本。

2。 是否存在公开 PoC？

截至 2026 年 11 月 6 日，本次检索尚未核实到公开、完整且可稳定复现远程代码执行的 PoC。

公开资料已经描述了临时目录暴露、安装程序访问以及竞态条件，但这些技术说明与完整利用代码应当分别看待。

GitHub 上存在针对相关升级目录的扫描项目，其功能与完整 RCE 利用链也存在差异。

3。 是否已有真实攻击？

有。CISA 已将 CVE-2026-119977 加入 KEV（Known Exploited Vulnerabilities）目录。

加入日期为 2026 年 11 月 3 日。CISA 将其列为已知遭利用漏洞，意味着该机构掌握了符合收录标准的实际利用证据。

此外，Wordfence 的威胁监测数据显示，安全更新发布后不久，就有攻击流量开始探测 WordPress 临时升级目录。

公开报道提到，Wordfence 在安全公告发布后的约 21 小时内记录了超过 18,500 次针对相关路径的请求。

需要区分的是，这些请求属于扫描或攻击尝试记录。CISA 的 KEV 收录确认了漏洞存在实际利用活动，但目前公开资料尚未提供可独立核验的大规模网站入侵数量。

六、如何检查自己的 WordPress 网站？

1。 查看 WordPress 版本

如果已经安装 WP-CLI，可以在网站根目录执行：

wp core version

也可以在 WordPress 后台进入：

仪表盘 → 更新

查看当前核心版本以及可用安全更新。

对于容器部署：

docker exec <container_name> \
  wp core version --allow-root

上述命令要求容器内安装 WP-CLI。实际使用时，应根据容器用户权限调整执行方式。

2。 检查临时升级目录

在 WordPress 网站根目录执行：

find wp-content/upgrade \
  -type f -name "setup-config。php" -print

如果发现临时目录中存在安装程序文件，需要进一步确认是否有升级任务正在执行。

这项检查主要用于发现遗留文件。由于漏洞具有时间窗口特征，未发现文件也无法单独证明历史上没有受到攻击。

3。 检查 Web 访问日志

对于 Nginx：

sudo grep -E \
'wp-content/upgrade/。*\。php|setup-config\。php' \
/var/log/nginx/access。log

对于 Apache：

sudo grep -E \
'wp-content/upgrade/。*\。php|setup-config\。php' \
/var/log/apache2/access。log

如果日志已经轮转，需要同时检查历史归档文件。

重点关注 2026 年 10 月 28 日以来的异常请求，尤其是访问升级目录中 PHP 文件的记录。

如果请求返回 HTTP 200，还需要结合响应内容、请求时间、升级日志和服务器其他异常判断是否存在实际利用。

七、如何修复和缓解？

1。 升级 WordPress 核心

最直接的方法是安装官方安全版本。

如果使用 WP-CLI：

wp core update

升级完成后：

wp core version
wp core verify-checksums

第二条命令用于核验核心文件完整性。如果网站存在定制修改，需要结合实际部署情况解释校验结果。

对于 WordPress 7。1 分支，应至少升级至 7。1。4。

对于较早分支，应安装对应的官方安全回移版本，或者直接升级到受支持的新版本。

2。 阻止访问升级目录中的 PHP 文件

如果暂时无法升级，可以在 Web 服务器层面限制临时目录中的 PHP 文件访问。

例如，对于使用 Nginx 的 WordPress 网站，可以添加：

location ~* ^/wp-content/upgrade/。*\。php$ {
    return 403;
}

需要确保这条规则优先于通用 PHP 处理规则。

修改后先检查配置：

sudo nginx -t

确认配置有效后再重新加载：

sudo systemctl reload nginx

对于 Apache，可以在 wp-content/upgrade/ 目录中使用适当的访问控制配置，禁止通过 HTTP 执行 PHP 文件。

部署前需要确认网站实际的 WP_CONTENT_DIR、自定义升级目录以及 Web 服务器路径映射。

这类限制可以减少攻击者直接访问临时 PHP 文件的机会，但仍应尽快完成官方补丁更新。

3。 检查是否已经遭到入侵

由于该漏洞已被 CISA 列入 KEV，公网 WordPress 网站建议进行一次安全排查。

重点检查：

• 最近是否出现未知管理员账户。
• wp-content 下是否存在异常 PHP 文件。
• 是否新增来源不明的插件或主题。
• wp-config。php 是否发生未经授权的修改。
• Web 访问日志是否存在针对临时升级目录的可疑请求。

如果发现明确的入侵迹象，应进一步检查服务器进程、计划任务、数据库账户和访问凭据，并从可信备份或镜像恢复受影响组件。

八、总结

CVE-2026-119977 揭示了 WordPress 核心升级过程中的一个特殊风险：用于安装新版本的临时文件，在短暂时间内可能成为外部攻击者的执行入口。

它具有三个值得关注的特点。

首先，漏洞涉及 WordPress 核心升级流程，影响多个长期维护分支。

其次，攻击者无需登录网站，但必须满足特定的升级时机和网络访问条件。

最后，CISA 已确认存在实际利用活动，说明这个短暂的攻击窗口已经引起攻击者关注。

对于 WordPress 管理员，建议优先完成核心版本升级，并在 Web 服务器层面限制对临时升级目录中 PHP 文件的访问。对于长期暴露公网的网站，还应检查历史访问日志及服务器文件完整性。

这次漏洞最重要的启示是：软件升级过程同样需要受到访问控制和安全监测。

资料核验日期：2026 年 11 月 6 日。

主要参考：WordPress 官方 7。1。4 安全发布公告、WordPress 官方 GitHub 安全公告 GHSA-4w3m-c66w-69mg、GitHub Advisory Database GHSA-p6jj-qrp3-7m4g、CISA KEV 漏洞目录、Wordfence 威胁情报及 BleepingComputer 安全报道。