跳过导航
返回列表
2026/11/7

WordPress 升级过程漏洞 CVE-2026-119977：利用尝试持续，影响范围与各环境的处置步骤

WordPress の更新中を狙う脆弱性 CVE-2026-119977：悪用の試みが続く、影響範囲と環境別の対処手順

WordPress 的 CVE-2026-119977 利用升级过程中的空档，影响 4.7 至 7.1.3，美国 CISA 已将其列入已被利用漏洞目录。10月28日发布的 7.1.4 和各分支修复版共修复22个问题。本文整理升级前的访问封锁、各环境的步骤、日文版和中文版的注意事项，以及如何检查是否被入侵。

分享

要点

  • WordPress：请升级到 7.1.4 或所在分支的修复版。CVE-2026-119977 利用升级过程中的空档实现远程代码执行，影响 4.7 至 7.1.3
  • 利用情况：CISA 于11月3日将其加入 KEV，Wordfence 拦截了超过24万次尝试。截至11月6日，我们没有查到公开的具体入侵案例
  • 日文版和中文版：日文安装包即使在同一分支内升级，也使用完整安装包。官方简体中文版的最新版本仍是 7.1，属于受影响版本
  • 升级前：在 Web 服务器上封锁对 wp-content/upgrade/ 的外部访问，确认返回 403 后再升级。如果无法马上设置，不要因此推迟升级
  • 升级后：确认版本，并检查 wp-content/upgrade/ 的残留文件、访问日志和管理员账号

关于本文

本文根据截至2026年11月6日23时30分（日本时间）的 WordPress 官方发布、CVE、NVD、CISA、Wordfence 以及各操作系统和服务的信息整理。发布情况会随时间变化，操作前请通过文末的官方链接确认最新信息。

严重程度的数值因发布方而异。本文都写明了是哪家机构的评级。

封锁规则和命令是根据各方文档和源代码整理的，其中一部分由我们自行编写，都没有在实际服务器上验证。应用后请务必确认结果。

第一步：先确认自己是否受影响

确认版本

  • 在管理后台的“仪表盘 > 更新”中查看
  • 使用 WP-CLI：wp core version --extra
  • 没有 WP-CLI：grep "wp_version =" wp-includes/version.php
  • 一台服务器上有多个站点（路径按实际环境修改）：find /var/www /home -type f -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} +
  • 在 WordPress.org 的状态列表中查询（修改其中的版本号）：curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep -E '"7\.1\.3" *:'。insecure 表示未修复，outdated 表示已修复的旧分支，latest 表示最新版

修复版本一览

  • 修复版本：7.1.4、7.0.8、6.9.11、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.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.35、4.8.34、4.7.39
  • 发布日期：全部是2026年10月28日。7.1.4 的官方文章写着旧分支修复仍在进行，但各分支的版本页面显示已在同一天发布
  • 目标版本：WordPress 只积极支持最新版本，旧分支的修复只是额外提供，目标应是 7.1.4
  • 4.6 及更早版本：没有安全更新。CVE 记录从 4.7 开始，但 Picus 称 2.7 至 4.6 也有同样的行为，不在 CVE 范围内不等于安全

升级使用的安装包

CVE 和 CISA 说明的对象是使用完整安装包的升级。实际使用哪种安装包，取决于站点语言和升级类型。以下是11月6日模拟请求 WordPress 更新 API 的结果，不是对实际站点的观察。

  • 日文安装包的站点：即使在同一分支内升级，仪表盘和自动更新都会提供日文完整安装包
  • 英文安装包但站点语言设为日文：仪表盘使用日文完整安装包，自动更新使用英文差分包
  • 英文版在同一分支内升级：通常使用差分包。差分包看来不含安装程序，但其内容未经确认。如果核心文件有修改或缺失，仪表盘和 WP-CLI 会改用更大的安装包
  • 跨分支升级：通常使用 no-content 等安装包。Picus 称这些也受影响，但 CVE 只写了完整安装包
  • 中文版站点：仪表盘会提供英文版 7.1.4（详见后文）。6.8 及更早版本的自动更新还会提供所在分支修复版的中文完整安装包

不要因为是差分包就认为安全。无论哪种情况，能封锁的话都请先封锁再升级。

CVE-2026-119977：利用升级过程空档的漏洞

发生了什么

  • 内容：WordPress 升级时，会把新文件解压到 wp-content/upgrade/ 的工作目录。修复前，这段时间内外部有可能访问工作目录中的安装程序
  • 影响：可能被未经认证的攻击者在服务器上执行代码。修复前，工作目录中生成的 wp-config.php 会覆盖正式的 wp-config.php，存在让站点连接到攻击者数据库的路径
  • 利用条件（Wordfence）：需要同时满足：使用含安装程序的安装包升级、工作目录可被公开访问、路径可被猜到或发现、在清理之前完成。Wordfence 的测试中，时间窗口只有几秒
  • 路径的可预测性：按 Picus 的整理，5.9 至 7.1.3 的路径可以预测；4.7 至 5.8 带有6位随机字符，路径必须先泄露
  • 升级失败的残留：如果升级失败后工作目录仍然存在，可能无需抢时间就被攻击（Imunify360）
  • 修复内容：工作目录名加入16位随机字符，保留 wp-content/upgrade/index.php，并且不再复制工作目录中的 wp-config.php

升级到修复版时，最后一次运行的仍是旧的升级程序。各安全厂商对这次升级的危险性看法不一，但 Wordfence 建议不要推迟，尽快升级。

严重程度评级不同的原因

  • Wordfence（CNA）：CVSS 3.1 为 8.1（High）。NVD 显示的也是这个值
  • WordPress：Low（没有 CVSS 数值）
  • Red Hat：Important
  • CISA 的 SSVC：利用状态 active，可自动化 no，技术影响 total
  • 如何理解：一旦成功影响很大，但成功很难，所以评级不同。Wordfence 称在测试中非常难以利用，Patchstack 也认为称不上实用，而报告者 Picus 称已构建出可用的攻击链。不过考虑到 CISA 已列入目录，请不要降低升级的优先级

利用情况（截至11月6日）

  • CISA KEV：11月3日加入。美国联邦机构的处理期限是11月6日。是否用于勒索软件为“未知”
  • Wordfence 的观测：从10月28日到11月5日的文章发布时，共拦截了超过24万次尝试，10月30日的峰值超过7.4万次。其中多数是自动化的反复访问，拦截次数并不等于入侵次数
  • 实际受害：没有查到说明具体入侵案例的一手信息。CISA 也没有公布攻击细节
  • 概念验证代码：GitHub 上有自称概念验证代码的公开仓库，但其效果未经验证。请不要运行内容不明的代码
  • 日本的动向：JPCERT/CC 没有发布专门的安全警报，但11月5日的 Weekly Report 提到了此事。也没有查到 IPA 的警报。没有查到日本国内公开的受害情况

同时修复的主要漏洞

WordPress 7.1.4 共修复22个问题。截至11月6日，能确认有 CVE 编号的只有 CVE-2026-119977。

  • GHSA-83c2-c4pc-wmp3（WordPress 评级 High）：Interactivity API 的存储型 XSS 和拒绝服务。需要投稿者及以上权限，影响 6.4 及以后版本
  • GHSA-p2r6-rwjp-phv3（Medium，Wordfence 5.3）：未经认证即可查看未发布的定制器修改。影响 4.9 及以后版本
  • GHSA-9vrg-x932-q57q（Medium，Wordfence 6.4）：定制器的存储型 XSS。需要投稿者及以上权限，管理员打开预览时触发。影响 5.0 及以后版本
  • GHSA-j255-3x8q-7q7g（Medium，Wordfence 6.4）：评论分页等区块的存储型 XSS。需要投稿者及以上权限，影响 5.9 及以后版本
  • 其他：还修复了 Categories 区块、Image 和 Playlist 区块、Script Modules、Notes、个人数据删除页面、多站点用户页面等问题
  • 根证书：内置证书（composer/ca-bundle 1.6.0）也已更新
  • Gutenberg 插件：24.3 及以后版本包含修复。7.2 测试版请使用 Beta 4

更早的修复也要注意。CVE-2026-87902 已在 7.1.2 和各分支修复版（7.0.6、6.9.9、6.8.10 等，直到 4.7.37）中修复，CVE-2026-63030 已在 7.0.2 和 6.9.5 中修复。这些分支上更旧的版本同样缺少这些修复，两者都已列入 CISA KEV。

风险最高的环境

  • 使用日文安装包并开启自动更新的站点：无人值守的升级也使用完整安装包
  • 无法在 Web 服务器上封锁的站点：在 WordPress 内部运行的防火墙挡不住这种攻击，因为工作目录中的副本不加载站点的插件（Patchstack）。Wordfence 防火墙需要开启 Extended Protection，这条规则要到11月27日才提供给免费版
  • 升级失败后一直没处理的站点：工作目录可能还留着
  • 自动更新已停止的站点：修复无法送达，一直停留在旧版本
  • 多人投稿的站点：另外21个问题大多需要投稿者及以上账号

处置一：升级前封锁外部访问

Wordfence 的文章作者建议能够马上设置的运维人员先封锁，同时提醒不要为了研究方法而推迟升级。封锁只是临时措施，另外21个问题不会因此修复。

  • nginx：在 server 块中加入 location ^~ /wp-content/upgrade/ { return 403; }，然后运行 nginx -t 和 nginx -s reload
  • Apache 虚拟主机：加入以下3行（路径按实际环境修改）
  • <Directory "/var/www/html/wp-content/upgrade">
  • Require all denied
  • </Directory>
  • Apache 生效：运行 apachectl configtest，然后运行 apachectl -k graceful
  • 共享主机的 .htaccess：在 WordPress 目录的 .htaccess 中，在 # BEGIN WordPress 上方加入以下2行
  • RewriteEngine On
  • RewriteRule ^wp-content/upgrade/ - [F]
  • OpenLiteSpeed：使用上面的 RewriteRule 写法，开启 .htaccess 自动加载并重启
  • Caddy：在站点块中加入 respond /wp-content/upgrade/* 403，然后运行 sudo systemctl reload caddy
  • IIS：在 web.config 的 <denyUrlSequences> 中加入 <add sequence="/wp-content/upgrade/" />。返回的是404而不是403，日志中记为404.5
  • Bitnami 虚拟机：.htaccess 可能不生效。请用上面的 <Directory> 写法加入 /opt/bitnami/apache/conf/vhosts/htaccess/wordpress-htaccess.conf，路径写成 /opt/bitnami/wordpress/wp-content/upgrade，然后运行 sudo /opt/bitnami/ctlscript.sh restart apache
  • 路径注意：安装在子目录的站点，nginx 和 Caddy 规则要加上前面的路径。工作目录建在 WP_CONTENT_DIR 下，所以 Bedrock 是 /app/upgrade/
  • 不要放在目录内：在 wp-content/upgrade/ 里放 .htaccess 或 index.php 没有用，修复前的升级程序会把它们删除
  • 确认：运行 curl -I https://example.com/wp-content/upgrade/probe.php，确认返回 403。Apache 的 <Directory> 在目录不存在时可能返回404，这个结果不能作为确认。通过 ProxyPassMatch 把 PHP 交给 PHP-FPM 的环境中 <Directory> 不起作用，请改用 <Location "/wp-content/upgrade/">、Require all denied 和 </Location>，安装在子目录的站点要加上前面的路径

处置二：升级

  1. 备份文件和数据库
  2. 设置上面的封锁并确认结果
  3. 升级。后台使用“仪表盘 > 更新”；WP-CLI 留在同一分支用 wp core update --minor，升级到最新版用 wp core update，然后运行 wp core update-db（多站点用 wp core update-db --network）
  4. 确认版本
  • WP-CLI 注意：加上 --version 或 --locale 会使用完整安装包。--force 可能把新版本降级，请不要使用
  • 数据库：在同一分支内升级，不需要运行数据库升级
  • 手动升级：官方步骤是备份、停用插件、解压安装包、删除旧文件（保留 wp-config.php 和 wp-content 等）、上传新文件、访问 /wp-admin/
  • PHP 最低版本：7.1.4 和 7.0.8 需要 PHP 7.4，6.6 至 6.9 分支需要 7.2.24，6.3 至 6.5 分支需要 7.0，5.2 至 6.2 分支需要 5.6.20，4.7 至 5.1 分支需要 5.2.4
  • 4.6 及更早版本：我们建议不要使用旧的升级程序，而是手动替换为受支持的版本
  • PHP 本身：升级 WordPress 不会修复 PHP 本身。10月的 PHP 修复已在这篇文章中整理

自动更新没有送达的站点

7.1.4 的官方文章说，支持后台更新的站点会自动更新，但没有提到强制更新。请务必确认。

  • 在后台的“工具 > 站点健康”中查看后台更新的结果
  • 检查配置：grep -nE "DISALLOW_FILE_MODS|AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISABLE_WP_CRON" wp-config.php
  • 如果 WordPress 目录或上级目录中有 .git、.svn、.hg、.bzr，自动更新会停止
  • 检查过去的失败记录：wp option get auto_core_update_failed --format=json（多站点用 wp site option get auto_core_update_failed --format=json）
  • 设置了 DISABLE_WP_CRON 又没有系统 cron 的站点，自动更新不会运行

中文版的注意事项

  • 全新安装：https://cn.wordpress.org/latest-zh_CN.zip 是 7.1，属于受影响版本。公开站点请不要使用，建议从 https://downloads.wordpress.org/release/wordpress-7.1.4.zip 开始，再把站点语言选为中文（这是我们的建议）
  • 现有站点：封锁后从“仪表盘 > 更新”升级。截至11月6日，API 提供的是英文版 7.1.4
  • 没有构建的版本：7.1.1 及以后、7.0.5 及以后、6.9.8 及以后没有简体中文构建。6.8.12 及更早的版本有
  • WP-CLI：使用 wp core update --minor 或 wp core update，不要加 --version=7.1.4
  • 校验和：没有简体中文校验列表的版本，请使用 wp core verify-checksums --locale=en_US。如果还留有中文版文件，可能出现不一致
  • 繁体中文：最新构建是 7.0.8，没有 7.1 分支。但 https://tw.wordpress.org/latest-zh_TW.zip 仍是 7.0.4，属于受影响版本，请不要使用

各系统与环境的修复版本和步骤

  • Debian 13：6.8.12+dfsg1-0+deb13u1（DSA-6596-1）。运行 sudo apt update 和 sudo apt install --only-upgrade wordpress，用 dpkg-query -W wordpress 确认
  • Debian forky、sid：7.1.4+dfsg1-1
  • Debian 12：6.1.9+dfsg1-0+deb12u1 截至11月6日未修复。我们建议迁移到 Debian 13，或官方版本的修复版。Debian 11 及更早版本同样未修复
  • Ubuntu：官方仓库的 wordpress 是 jammy 5.8.3、noble 6.4.3、resolute 6.7.2，没有查到修复版。Ubuntu 的 CVE 页面无法读取，状态未确认。请用 apt-cache policy wordpress 确认，公开站点建议改用官方版本的修复版
  • Fedora：Fedora Rawhide（fc46）和 Fedora 45 的稳定仓库已有 7.1.4-1。Fedora 44 和 43 的 6.9.11-1 截至11月6日还在测试中。如果 sudo dnf upgrade --refresh wordpress 没有更新，请加上 --enablerepo=updates-testing
  • RHEL 系（EPEL）：Red Hat 不提供 WordPress。EPEL 的修复版截至11月6日还在测试中，可用 sudo dnf upgrade --refresh --enablerepo=epel-testing wordpress 更新
  • Arch Linux：wordpress 7.1.4-1。运行 sudo pacman -Syu
  • Gentoo：www-apps/wordpress 有 7.1.4、7.0.8、6.9.11、6.8.12、6.7.11、6.6.11、6.5.14、6.4.14，都是测试关键字
  • FreeBSD：www/wordpress 的 main 分支是 7.1.4，但 2026Q4 季度分支是 7.1.2，尚未修复。VuXML 没有 WordPress 条目，所以 pkg audit 查不出来
  • 官方 Docker 镜像：wordpress:7.1.4 和 wordpress:latest 是修复版。更换镜像不会更新现有数据卷，请用 docker exec <容器名> grep wp_version wp-includes/version.php 确认，并在站点内部升级。wordpress:7.0、wordpress:6.9、wordpress:6.8 已停止更新，仍受影响
  • Bitnami 容器：bitnami/wordpress:latest 是 7.1.4，基础系统是 Photon。Helm chart 的默认值是旧版本，请明确指定镜像。bitnamilegacy/wordpress 已停止更新
  • Composer、Bedrock：roots/wordpress 已有 7.1.4。Bedrock 默认关闭自动更新，需要运行 composer require roots/wordpress -W，确认 composer.lock 中是 7.1.4 或更新版本后再部署
  • 1Panel：应用已更新到 7.1.4，但数据卷中的站点可能没有变化。请在应用目录中运行 grep "wp_version =" data/wp-includes/version.php，版本旧的话在站点内部升级
  • Softaculous：列表中还有未修复的旧版本。全新安装时请只选修复版
  • WP Toolkit（cPanel、Plesk）：请逐个站点确认版本和自动更新设置
  • AWS Lightsail：现有实例由用户自己更新。请先做快照，封锁后再升级。11月19日起，新建实例不能再选 Bitnami 的 WordPress 蓝图
  • Azure App Service：默认开启次要版本自动更新，但请在 wp-admin 中确认版本
  • Pantheon：修复已发布，但要在控制台的 Code 标签运行 Apply Updates，并部署到 Test 和 Live 后才会到达正式环境
  • WP Engine：一般政策是尽快应用安全更新，但没有查到关于 7.1.4 的具体说明
  • Kinsta、WordPress.com：没有查到这次的应对说明。请确认版本，如果不是修复版请联系服务商
  • Windows、macOS：没有服务器用的官方安装包。brew upgrade wp-cli 只更新命令行工具，不会更新站点的 WordPress

日本的共享主机

  • ConoHa WING：10月29日发布通知，10月30日更新了该通知。新安装为 7.1.4。现有站点如果开启了自动更新会陆续更新，否则需要自己更新。通知中“没有利用报告”的说法早于 CISA 列入目录
  • お名前.com レンタルサーバー：10月29日发布通知。现有站点如果开启了自动更新会陆续更新，否则需要自己更新。通知中“没有利用报告”的说法同样早于 CISA 列入目录
  • ロリポップ！：11月6日查看的通知列表只到10月24日，早于这次修复，无法据此判断
  • エックスサーバー、シンレンタルサーバー、スターサーバー、さくらのレンタルサーバ、mixhost、KAGOYA：在11月6日查看的通知列表中，没有看到关于这次修复的通知。各家列表覆盖的范围不同，服务器端有没有采取措施也无法确认

请不要认为服务商已经处理，请在“仪表盘 > 更新”中确认版本。

升级后一定要确认的事项

  • 版本：逐个站点对照修复版本一览。即使开启了自动更新也要确认
  • 修复是否生效：grep -n get_working_dir_name wp-admin/includes/class-wp-upgrader.php 有输出，就说明是修复后的升级程序
  • PHP 缓存：在 opcache.validate_timestamps=0 的环境中，通过 WP-CLI、软件包或手动方式升级后，请重新加载 PHP-FPM 或 Apache。命令行的 php -i 可能与 Web 端的设置不同
  • 残留文件：运行 find wp-content/upgrade -name "*.php" | sort。修复后的正常状态是只有 index.php，或者没有输出。如果有 wp-config.php 或其他 PHP 文件，请进行调查
  • 清理残留：确认没有正在进行的升级（core_updater.lock 和 auto_updater.lock 未设置）后，删除 index.php 以外的内容。不要动 wp-content/upgrade-temp-backup/
  • 访问日志：用 grep -E 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log* 这样的命令查找对工作目录 PHP 文件的访问。路径按实际环境修改，压缩日志请用 zgrep。确认封锁时自己发出的 probe.php 请求也会显示出来。日志中没有记录，也不能证明安全
  • 管理员：用 wp user list --role=administrator --format=csv 检查有没有陌生账号
  • 插件：用 wp plugin list 和 wp plugin verify-checksums --all 检查有没有陌生插件或篡改
  • 核心文件：运行 wp core verify-checksums --include-root（需要 WP-CLI 2.8.0 及以上）。插件和上传的文件不在检查范围内
  • 数据库连接目标：用 grep -nE "DB_(NAME|USER|HOST)" wp-config.php 确认指向自己的数据库。这条命令不会显示密码
  • 怀疑被入侵时：隔离站点并保全日志，从可信的备份恢复，并更换数据库、管理员、API 的认证信息以及 wp-config.php 的密钥

官方信息（一手资料）

免责声明

本文根据截至2026年11月6日的公开信息，由 Two Sheep株式会社整理，不保证各产品的运行或安全性。操作前请务必确认各提供方的最新信息。文中的公司名称和产品名称均为各公司的商标或注册商标。文中提到的企业仅作为信息来源或说明对象，不代表与我们存在交易关系。

如需在数据中心现场重启服务器、操作控制台或更换设备，欢迎咨询我们的远程代维服务。

分享