WordPress 更新时也会被攻击？7.1.4 修复了什么，站长该怎么查

问题出在更新的那几秒

给网站打补丁，通常是在关闭攻击入口。但 WordPress 刚修复的一个问题，恰好出现在打补丁的过程中：受影响站点使用完整安装包更新核心时，会把新文件先解压到一个临时目录；如果这个目录能从公网访问，又允许执行 PHP，攻击者就可能趁更新尚未结束进入临时安装程序。

WordPress 10 月 28 日发布的 7.1.4 修复了这一问题。安全公司 Wordfence 随后报告，防护规则上线后的 21 小时里，记录到超过 18,500 次针对临时安装路径的请求；部分来源持续反复探测。这个数字是它观察到的请求，不是成功入侵的网站数量。

这里有个容易误解的地方：这不是说旧版 WordPress 放在那里、随便来一个请求就必然中招。攻击者还得碰上特定的更新过程，并赶在临时文件被清理前完成操作。只是窗口短，不代表可以不更新。

临时文件为什么会变成入口

站点进行完整包更新时，需要先把下载的新版本解压，再把文件复制到正式位置。受影响版本会在 wp-content/upgrade 下使用可预测的临时目录；完整包里包含 WordPress 安装程序。如果 Web 服务器允许外部请求访问这份临时副本，PHP 又会执行其中的安装脚本，攻击者就有机会在极短的时间里与它交互。

Wordfence 列出的条件包括：更新使用含安装程序的完整包、临时目录可从外部通过 Web 和 PHP 访问、目录路径可预测或已被发现，以及攻击在清理文件前完成。它在实验环境中观察到的窗口通常只有数秒；反复自动请求可以增加撞上窗口的机会，但仍不等于必定成功。

7.1.4 改变了暂存目录处理方式，并加入额外保护。这里的缺陷属于 WordPress 核心更新流程，不是某个插件漏洞，也不要和前一阵的 PHP2Shell 两个 PHP 核心漏洞混为一谈。

我应该更新到哪个版本？

先登录 WordPress 管理后台，在“仪表盘 → 更新”中确认站点当前核心版本。开着自动更新不代表每个站点都已成功安装：权限、托管商策略或更新失败都可能让实际版本停留在旧版。如果使用 WP-CLI，也可以在站点根目录运行下面的只读版本查询。

7.1 分支的修复版是 7.1.4；WordPress 和 Wordfence 列出的旧分支修复还包括 7.0.8、6.9.11、6.8.12 等，一直回移到 4.7.39。不要因为自己的版本号小于 7.1.4，就忽略同分支后续安全修复；对照官方公告核对具体分支。WordPress 说明 4.6 及以前版本不再获得安全更新，仍应规划迁移到受支持版本。

wp core version

更新本身有窗口，怎么办

如果你能管理 Web 服务器或上游访问控制，并且知道站点实际安装路径，可以在更新前评估临时限制外网对该站点 wp-content/upgrade/ 的访问，完成更新后再检查业务和管理功能。多人共用服务器、反向代理、子目录安装或其他工具依赖该路径时，应先确认匹配范围与回退方式；不要把一条网上规则直接套到整台服务器。

这是降低暴露的补充措施，不是修复，也不要为了研究配置一直拖着不更新。Wordfence 研究负责人在原文评论中认可有能力的管理员先做限制，同时提醒普通站长不应因配置困难而耽误升级。没有服务器权限的站长可以请托管商协助，并尽快确认安全更新已安装。

若使用 Wordfence，其针对这个问题的规则面向不同版本的提供时间不同；该公司还提醒，直接请求 PHP 文件时需核查防火墙是否启用 Extended Protection。不要仅因安装了插件就假定规则已经覆盖，更不能用它代替核心更新。

更新之后，看哪些异常

如果站点曾长时间处于受影响版本，检查 Web 日志中指向 wp-content/upgrade/ 下 PHP 文件的异常请求，并与更新时间、服务器日志及告警关联；再核对是否出现不认识的管理员、插件或 PHP 文件。日志里出现一次请求只说明有人访问或尝试访问，不能单凭这一条就认定攻击成功。

若确有异常，不要只删掉一个可疑文件就结束：先保留相关日志和文件证据，按站点的应急流程隔离、分析并处理可能泄露的账号和密钥。WordPress 更新后也应确认页面、后台、插件和备份状态正常。

关于编号和风险评级

Wordfence 将该问题标为 CVE-2026-119977，并给出 CVSS 8.1；截至本次核对，WordPress 自己的 GitHub 安全公告仍显示没有已知 CVE、严重程度为 Low。两个来源的编号和评级状态存在差异，本文使用 WordPress 公告编号 GHSA-4w3m-c66w-69mg 定位问题，不把分数差异当作漏洞不存在的依据。