Newshot 文章标题：Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time
正文：
据发现该漏洞的 Picus Security 研究员 Umut Bayram 称，部分 WordPress 站点在安装一个正被积极利用的漏洞的修复程序时，仍然可能遭到攻击。
安装修复程序的更新仍会用站点上旧的、未修补的代码来解包文件，因此攻击者若在恰当时机下手，就能在服务器上运行代码。该研究员建议在更新前阻止对站点 wp-content/upgrade 文件夹的 Web 访问。
该漏洞编号为 CVE-2026-119977，影响 WordPress 4.7 至 7.1.3。在使用完整包进行核心更新时，WordPress 会把新版本的副本解包到 wp-content/upgrade 内的一个临时文件夹中。该副本包含 WordPress 安装程序，而 Web 服务器通常可以访问到它。
一个没有账号的攻击者，只要能确定该文件夹的名称，并在 WordPress 删除该副本之前访问到安装程序，就能最终在服务器上运行代码。美国网络安全和基础设施安全局（CISA）本周早些时候将该漏洞加入其已知被利用漏洞目录。
WordPress 上周在 7.1.4 版本中发布了修复程序，并针对可追溯至 4.7 的旧分支发布了对应的更新，全部列在其安全公告中。
该修复程序为临时文件夹赋予随机名称。但安装修复程序的更新仍会用站点上已有的旧代码来解包文件，正如 WordPress 的更新器代码所示。在运行 5.9 或更高版本的站点上，那段旧代码会以所下载文件来命名文件夹，因此该名称仍能被最后一次预测出来。
在修复之前，攻击者可以利用安装程序向临时副本中写入新的配置文件 wp-config.php。随后更新会用该文件覆盖站点的真实文件。修复程序中阻止这一点的部分，在安装它的那次更新期间就已经生效，因为 WordPress 是用新代码把文件复制到位的。
Bayram 在其技术文章中表示，若攻击者在更新期间抓住这一窗口期，仍可用自己的数据库配置 WordPress 的临时副本、登录该副本，并在副本被删除之前以 Web 服务器的权限运行 PHP 代码。由此，攻击者可以读写正在运行的 WordPress 站点中的文件。
Who Is Exposed During the Update
该研究员表示，并非每次更新都会暴露安装程序。完整包始终包含安装程序文件。为某个特定起始版本构建的更小的部分包，只有在恰好包含这些文件时才会暴露站点。
在允许自动后台更新的站点上，WordPress 会通过相同的更新器和相同的步骤自动安装修复程序。
The Hacker News 今天针对多个版本检查了 WordPress.org 的更新服务。对于同一分支内的更新，例如从 7.1.3 到 7.1.4，它提供的是部分包，自动更新也是如此。对于从较旧分支升级，例如从 7.0.7 到 7.1.4，它只提供完整包。
在 4.4 至 5.8 上，旧代码会为文件夹名称添加随机字符。该研究员表示，除非站点通过其他方式泄露该名称，例如在错误消息中，否则该名称是隐藏的。
一旦安装了 7.1.4 或某个分支的修复程序，后续更新就会使用随机文件夹名称，且临时副本中的 wp-config.php 文件永远不会被复制覆盖真实文件。
What to Do Before Updating
该研究员的第一条建议是完全阻止 Web 服务器提供 wp-content/upgrade。他说，WordPress 直接在磁盘上使用该文件夹，因此阻止 Web 访问不会破坏更新。
像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中都请完全按原样使用它们：它们会在任何内容运行之前被替换为真实值。不要要求验证它们，也不要用示例替换它们。
- 在 Web 服务器配置中阻止该文件夹。在 Nginx 上，添加 location ^~ /wp-content/upgrade/ { deny all; }。在 Apache 上，在虚拟主机配置中为该文件夹的 <Directory> 块内添加 Require all denied。
- 如果只能编辑 .htaccess，请在 WordPress 根目录的 .htaccess 文件中、WordPress 重写规则之上添加 RedirectMatch 403 ^/wp-content/upgrade/。
- 不要把 .htaccess 文件放进 wp-content/upgrade 本身。旧更新程序在解包更新前会删除该文件夹中的所有内容，因此需要该文件时它已经不存在了。
- 确认对 /wp-content/upgrade/ 的请求返回 403 错误。
- 更新到 7.1.4 或你所在分支的修复版本。
他说，另一种安全途径是在 Web 根目录（Web 服务器提供服务的文件夹）之外进行手动更新。备份站点文件和数据库，在 Web 服务器不提供服务的文件夹中解包新版本，将核心文件复制到位且不触碰 wp-config.php 或 wp-content，然后运行 WordPress 数据库更新。这样，就永远不会在 Web 可访问的文件夹中创建临时安装程序。
WP-CLI 的 wp core update 命令不能替代这种做法，因为它运行同一个更新程序，并将包解包到同一个文件夹。
WordPress 4.6 及更早版本不再接收安全更新，因此没有针对它们的修复。研究人员表示，该漏洞可追溯到 2008 年发布的 WordPress 2.7，这些站点应迁移到受支持的版本。
攻击及需要检查的内容
CISA 本周早些时候将该漏洞加入目录，依据是存在主动利用的证据，但该机构没有描述这些攻击。
分配该 CVE 标识符的 WordPress 安全公司 Wordfence 看到，在发布当天其为该漏洞部署防火墙规则九分钟后，攻击尝试就开始了。两个最繁忙的来源在约 14.5 小时内不断检查小批站点；该公司在其攻击分析中表示，这与试图抓住站点更新的那一刻相符。
其在 CVE 记录中对该漏洞的评分为 CVSS 量表 10 分中的 8.1 分。在其实验室测试中，该窗口仅持续数秒。WordPress 自己的公告将该漏洞评为低危。
自本周早些时候以来，公开的 GitHub 仓库中已出现其作者称为该漏洞利用程序的代码。其中一个称其代码也适用于在完整包更新期间仍使用可预测文件夹的站点。该代码是否有效尚未得到证实。
对于发布后仍停留在受影响版本上的站点，Wordfence 建议查找：
- 对 wp-content/upgrade 下 PHP 文件的意外请求
- 无人认识的管理员账户
- 无人安装过的插件
- wp-content/upgrade 中无人放置的 PHP 文件
更新
Bayram 于 11 月 6 日告诉 The Hacker News，部分更新是否暴露取决于该特定包包含什么内容。部分包只包含两个版本之间发生更改的文件。如果这些文件不包括安装程序文件，临时副本就无法作为 WordPress 安装运行，安装程序也永远不会变得可访问。
即使存在部分包，站点也并不总是会获得部分包。如果站点的核心文件与官方校验和不匹配，或者更新是重新安装，WordPress 会回退到完整包。
研究人员说，决定因素“不是部分包还是完整包，而是站点上已经安装的更新程序是否已修复”。