CISA KEV：WordPress 核心升级竞争窗口正遭主动攻击

这是一个相当棘手的漏洞。CISA 已将 CVE-2026-119977——WordPress Core 中的一个 TOCTOU（检查时间与使用时间不一致）竞争条件漏洞——列入其 已知被利用漏洞目录（KEV），并称已有实际利用证据。该漏洞 CVSS 评分为 8.1，据 CISA 公告，未经身份验证的攻击者可能在升级窗口期间在服务器上执行代码。根本原因在于：完整安装包核心升级过程中使用了可预测、可通过 Web 访问的暂存路径。

再读一遍。这个漏洞不在插件、主题或某个陈旧的默认配置里，而是出在更新机制本身——也就是说，给存在漏洞的站点打补丁的那一刻，恰恰是它最脆弱的时候。这就像某个速通技巧：要越过 Boss，唯一办法是穿过一面短暂失效的墙。如果攻击者的请求恰好落在这个窗口内，就能在你的服务器上执行任意代码。美国联邦文职行政机构需在 2026 年 11 月 6 日前依据约束性运营指令 BOD 26-04 完成修复。其他机构也应把这个日期当成自己的截止期限。

此 TOCTOU 原语的工作原理

TOCTOU 漏洞是一类经典问题：程序先检查某个条件（检查时间），随后基于该条件执行操作（使用时间）——如果攻击者能在两者之间改变状态，就能得逞。类似文件系统中利用符号链接替换实施的竞争攻击，只不过这里的“文件系统”是你的网站根目录，而“计时器”则是核心升级过程。

据 The Hacker News 报道，Wordfence 上周披露了该漏洞的细节。利用该漏洞不需要站点账户，但需要把握时机：攻击者必须在一次完整的核心更新期间，抓住升级流程将文件暂存到可预测且可通过 Web 访问的路径的短暂窗口。CISA 的 KEV 条目明确将“完整安装包核心升级过程中使用的可预测、可通过 Web 访问的暂存路径”列为根本问题，并指出被暂存的 setup-config.php 安装程序路径是可被观测到的攻击目标。

从概念上看，攻击流程如下：

1. WordPress 开始完整安装包的核心升级，并将新版本解压到一个名称可预测、可通过 HTTP 访问的暂存路径中。
2. 在升级完成、暂存区被清理或锁定之前，攻击者向被暂存的安装程序（例如被暂存的 setup-config.php）发送请求，与清理步骤展开竞赛。
3. 如果请求落在窗口期内，攻击者便可通过可控输入驱动这些暂存代码，并以 Web 服务器用户身份实现代码执行。
4. 后渗透阶段：植入 webshell、窃取 wp-config.php 中的凭据、横向移动——套路一如既往。

“WordPress Core 存在一个 TOCTOU（检查时间与使用时间不一致）竞争条件漏洞，可能允许未经身份验证的攻击者在升级窗口期间在服务器上执行代码，”CISA 表示。

已确认、有待证实与未知之处

已确认的部分：CISA 基于已有的实际利用证据将 CVE-2026-119977 列入 KEV，而 KEV 收录的标准是：具备 CVE 编号、存在利用证据，并提供明确的缓解指导。据 The Hacker News 报道，补丁于上个月末发布。

监测数据显示攻击活动相当频繁。Wordfence 表示，在漏洞公开披露后的前 21 小时内，其记录到针对暂存 “setup-config.php” 安装程序路径的请求超过 18,500 次，并且在报道发布时，其最近 24 小时内拦截了 12,632 次利用尝试。另外，蜜罐运营方 Previdian 记录到来自某个英国地理位置 IP 的三次利用尝试，时间为 2026 年 10 月 30 日。这种扫描与真实攻击并存的流量规模，与一个刚刚公开、且极易批量利用的漏洞相吻合。

未知之处：没有任何来源将此次利用归因于某个具名组织，CISA 与相关报道也都未说明有多少站点真正被攻陷、又有多少仅仅遭到探测。请将 18,500 这一数字理解为攻击流量，而非已确认的入侵事件。此外，来源中同样未确认受影响的具体核心版本，因此稳妥的假设是：凡未安装 10 月底发布的补丁版本的站点，都应视为存在风险。

风险自查：你是否处于影响范围之内？

第一步看似枯燥却至关重要：盘点资产。WordPress 承载了公共互联网的很大一部分，而在中型组织中，真正的风险往往不是你知道的官网，而是某个产品团队在 2023 年搭建后就被遗忘的博客。请从外部攻击面数据、托管账户和 CDN 配置中提取 CMS 指纹。凡是未升级到已修复核心版本的自托管 WordPress 实例，都在排查范围之内。

第二步：确定其中哪些实例会通过公网执行完整安装包的核心升级。那些位于维护模式闸门之后的站点、由部署自动化通过 WP-CLI 更新的站点，以及由托管服务商负责核心更新的托管客户，其暴露窗口都明显更小。最糟糕的情形是：某个公开站点上有人在 wp-admin 中点击“立即更新”，而整个互联网都在围观。

检测：日志会说明一切

从防御者的角度看，这个漏洞有一点很好：利用行为在日志中非常显眼。攻击者必须在暂存安装程序路径存在时请求它，而在一个成熟的站点上，setup-config.php 原本就不应该接收任何外部流量。请回溯检查近期升级窗口前后的访问日志，搜索以下内容：

# Find requests hitting staged installer paths
grep -E 'setup-config\.php' /var/log/nginx/access.log* | grep -v ' 404 '
# Correlate with your upgrade windows: who requested it, and did they POST?
awk '$7 ~ /setup-config/ {print $1, $4, $6, $7, $9}' /var/log/nginx/access.log*

对该路径的 GET 请求若返回 404 只是背景噪音——互联网会扫描一切。而如果在你正在升级期间，来自非你方 IP 的 POST 请求命中该路径并返回了 200，那就是你的安全事件。顺着线索排查：检查 Web 根目录下新建的 PHP 文件、异常的管理员账户、被修改的 wp-config.php，以及时间戳之后 Web 服务器发出的外联连接。这也正是 BOD 26-04 现在明确要求各机构执行的补丁后入侵排查——先打补丁，再验证补丁是否被装在一台早已失陷的主机上。

缓解：先缩小窗口，再将其关闭

根本解决办法是升级到已修复的核心版本，这一点必须优先。CISA 的 KEV 指导原则是：优先修复已列入目录的漏洞，毫无例外。但由于此漏洞使更新过程本身成为攻击面，如何打补丁同样关键：

• 立即打补丁，升级到 10 月底发布的核心版本——但要审慎操作，不要在繁忙的公开站点上随手点击更新。
• 尽可能在站点外执行更新：在服务器上使用 WP-CLI（wp core update）或你的 CI/CD 流水线，而不是通过 Web 触发的升级程序。没有 Web 端窗口，也就没有 Web 端竞争。
• 升级期间将站点移出公共访问路径：启用维护模式，对除管理员 IP 之外的所有访问返回 503；或在负载均衡器处临时限制访问。
• 在 WAF 或服务器层面拒绝外部访问暂存/安装程序路径，作为补偿性控制措施——返回 403 的暂存 setup-config.php 会让这场竞争无路可走。
• 打补丁后进行排查：检查日志中过往对暂存安装程序路径的访问记录，并在宣告完成前排查 webshell 和异常账户。

对 CMS 运维的更大启示

更深层的问题在于架构：一个将可执行代码解压到可通过 Web 访问、路径可预测的位置的升级流程，本身就是一张常驻的邀请函。长远来看，正确的做法是把更新当作部署而非点击操作：拉取发布版本，在 Web 根目录之外进行暂存，原子化切换，并且绝不让安装程序对陌生人可达。这是 PHP 生态中基本要求，也与我们此前报道过的一些问题一脉相承，比如那些让大部分 Web 都陷入倒计时的免认证 PHP 漏洞。

向 Wordfence 致敬，感谢其披露与监测数据；也感谢 Previdian 提供的蜜罐验证。现在请去打补丁——务必谨慎——并在更新程序运行时检查日志。