升级本应是让网站变安全的过程。但这一次，升级本身就是攻击窗口。

WordPress 7.1.4（10 月 28 日发布）修复了一个升级过程中的远程代码执行漏洞：CVE-2026-119977，CVSS 8.1。11 月 3 日，美国网络安全与基础设施安全局（CISA）把它列入 Known Exploited Vulnerabilities（KEV）目录，确认已经在野被利用，并要求联邦机构在 11 月 6 日之前处理完毕——这个期限昨天已经过了。

WordPress 7.1.4 升级窗口竞态 RCE：CVE-2026-119977，CISA 确认在野利用

漏洞出在哪：升级时的临时目录

问题出在完整包升级（full-package core upgrade）这个流程上。WordPress 升级时不是只打增量补丁，而是下载并解包一整个新版本。在这个过程中，它会用到临时”staging”目录，而 NVD 记录里对这两个目录的描述是：地址可预测、且可以通过 web 直接访问。

漏洞类型是 CWE-367，TOCTOU 竞态条件：软件先检查、过一会儿再执行，中间这段时间差就是攻击者的机会。在这里，时间差就是升级进行中的那几分钟——文件已经躺在 staging 目录里、攻击者能猜到地址、又能直接通过 web 够到，于是未经身份认证的攻击者可以在升级窗口内在服务器上执行代码。

这意味着攻击者不能随时动手，必须恰好撞上一次正在进行的升级。CVSS 里的复杂度评级是高，也正是这个原因。但”难打”不等于”没人打”：CISA 在 NVD 记录里的评估写的是利用状态 active、技术影响 total。它同时注明该漏洞不可自动化，大规模扫射式利用的可能性较低，更像是针对性下手。

漏洞由研究员 Umut Bayram 报告，CVE 由 Wordfence 担任编号机构分配。

影响范围：4.7 到 7.1.3，全分支

按 NVD 的记录，WordPress 核心从 4.7 到 7.1.3 的所有版本都受影响。WordPress 表示修复已经 backport 到所有仍在安全支持期内的分支，一路回溯到 4.7，不过部分老分支的回 port 还在进行中——老分支的用户别假设自己的版本号，要去对应分支的发布渠道核对。

7.1 分支的用户直接升到 7.1.4。开了自动后台更新的站点理论上自己会升，但不要假设，逐个站点核对版本号；托管主机和多站点集群尤其要手动盘点一遍。

7.1.4 里不只有这一个修复

这次安全发布顺带修了一批别的：

  • 多处存储型 XSS：Interactivity API、Customizer 选择性刷新、分类区块、播放列表和图片区块、评论分页区块、用户登录、隐私数据删除请求——攻击者提供的脚本会被存下来，在其他访客或管理员的浏览器里执行
  • Interactivity API 里的一处存储型拒绝服务
  • 未发布的 Customizer 变更可被未授权发现：还没发布的草稿改动能被不该看到的人翻出来
  • 一处 notes 读取权限问题
  • 更新了内置的根证书（跟随 eMudhra 吊销事件）

下一个大版本 7.2 计划在 12 月 8 日发布。

DBA 为什么要在乎一个 WordPress 漏洞

WordPress 背后多半是 MySQL 或 MariaDB。拿下 web 服务器之后，攻击者手里第一顺位的东西就是 wp-config.php 里的数据库凭据。一次未授权 RCE，约等于数据库账号密码按”已泄露”处理——这正是 DBA 的事，不是只跟站长有关。

该干什么，照着做

  1. 立即升级到 7.1.4（7.1 分支），老分支跟进各自的 backport；自动更新的也要核对版本号
  2. 排查历史升级时间点前后的日志：CISA 这次的要求附带了取证排查——打补丁堵住洞，不等于抹掉已经发生的入侵。翻 web 服务器和应用日志，重点看过去每次核心升级前后那段时间
  3. 看有没有异常：安装目录里多出来的文件、没见过的管理员账号、核心/主题/插件文件里你没动过的改动
  4. 有入侵迹象就按事件处理，不是只打补丁：从可信来源重建；轮换数据库凭据、wp-config.php 里的密钥、以及主机上存的其他 API 密钥
  5. 开放投稿或评论的站点，7.1.4 里的存储型 XSS 修复同样值得立即升

联邦机构的期限是 11 月 6 日，昨天已过。CISA 对联邦机构的要求是补丁加取证排查——这个组合动作，同样适用于你自己的站点。

原文作者: liups.com

原文链接: https://liups.com/posts/9aa98127/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议