事件概述：一次“趁你升级时动手”的攻击
WordPress 核心更新流程曝出未认证远程代码执行漏洞（CVE-2026-119977）。10 月 28 日，WordPress 官方发布 7.1.4 安全版本，并向 4.7 以来的每一个维护分支回移了修复；10 月 29 日官方安全公告（GHSA-4w3m-c66w-69mg）上线；10 月 31 日 Wordfence 分配 CVE 编号并给出 CVSS 3.1 8.1 的评分；11 月 3 日，CISA 将该漏洞列入已知在野利用漏洞目录（KEV），要求联邦民事机构在 11 月 6 日前完成修复。国内奇安信 CERT 也发布了风险通告（QVD-2026-102501），确认漏洞已在野利用，PoC 与技术细节已公开。
攻击流量比 KEV 收录出现得更早。据 Wordfence 披露，其防火墙规则在 10 月 28 日 20:30 UTC（补丁发布约三小时后）下发，9 分钟后即出现首次命中；前 21 小时内有超过 18500 次请求直指暂存安装器路径，24 小时累计拦截 62969 次。更值得注意的是攻击者的打法：两个最大来源对一组小站点持续轮询约 14.5 小时，其余来源则轮换暂存目录名与版本号变体——这不是在赌某一个站点中招，而是在等全网任意一次更新开始。
漏洞原理：升级那几秒，暂存目录门户大开
WordPress 的核心升级分增量包与完整包两种方式，出问题的是完整包。执行整包升级时，WordPress 会先把新版本文件解压到 wp-content/upgrade/ 下一个基于包名生成的临时目录，解压完成后再逐项替换到位。问题恰恰出在这个窗口期：临时目录位于站点文档根之下，Web 服务器可以直接访问；解压过程中里面的 PHP 文件已经落盘，但整个替换流程还没走完；更关键的是，这份暂存拷贝里带着 WordPress 安装器 wp-admin/setup-config.php，而暂存目录里并没有已存在的 wp-config.php 来阻断安装器运行。
于是，未认证的攻击者只要在“解包完成到清理完成”之间的那几秒里请求到暂存路径，就能与这份暂存的 WordPress 交互并推进到 PHP 代码执行。这是一个典型的时间检查到时间使用（TOCTOU）竞态条件（CWE-362）。公开的 PoC 显示，攻击者向暂存安装器提交配置表单即可在暂存拷贝中写入 wp-config.php，而这份拷贝随后会被更新程序的 copy_dir 覆盖到站点根目录——相当于借升级流程本身把攻击者可控的配置“正大光明”写进站点。利用无需任何账号和用户交互，但需要卡准时机，这也是评分中攻击复杂度较高的原因。
影响范围：4.7 起全分支，老站点别侥幸
受影响的包括 WordPress 4.7 至 7.1.3 的全部维护中分支，最新发布的 7.1.0–7.1.3 首当其冲。官方修复版本已按分支回移：7.1 线升到 7.1.4，7.0 线升到 7.0.8，6.9 线升到 6.9.11，6.8 线升到 6.8.12，6.7 线为 6.7.11，6.6 线为 6.6.11，6.5 线为 6.5.14，更早分支各有对应安全版，完整清单以官方公告为准。4.6 及更早版本已不在官方安全覆盖范围内，使用这类版本的站点需要尽快制定迁移计划。
需要特别提醒两类部署方式：一是开启自动后台更新的站点，默认走的就是完整包升级，站点管理员往往在不知情中就进入了攻击窗口；二是容器化部署，据安全社区通告，官方镜像仓库中并没有 7.0.8、6.9.11、6.8.12 这些回移版本的标签，基于旧镜像构建的服务建议直接升级到 7.1.4 重新构建。此外，如果自动更新因 PHP 执行超时或文件系统权限报错而中断，那个可预测的暂存目录会永久留在磁盘上，暴露窗口将从几秒变成无限长。
评分分歧背后：别被 Low 误导
这个漏洞存在一个容易让人放松警惕的细节：WordPress 官方在 GHSA 公告中将其评为 Low，而 Wordfence 的 CVE 记录给出的是 CVSS 8.1 High。两种评分描述的其实是同一条未认证代码执行路径——Low 权衡的是单站点那几秒的窗口期，High 权衡的是攻击者赢得窗口后的后果。结合 KEV 收录和真实攻击流量来看，威胁是实打实的，不建议因为官方评级是 Low 就放缓处置。
还有两个比漏洞本身更值得记住的“陷阱”。其一，补丁并不保护携带它的那次更新：执行解包的仍然是旧版更新器代码，7.1.4 保护的是下一次升级。其二，中断的自动更新会把窗口从几秒拉成无限长。这也解释了为什么攻击流量在补丁发布当天就大规模出现——他们在赌的就是“以为已经装上”和“更新中途失败”这两种状态。
为什么普通用户和中小企业要关注
WordPress 支撑着全球约 43% 的网站，从个人博客、企业官网到电商平台都在用它。对自建站点的站长和中小企业运维来说，很少有人会盯着“升级那几秒”，但攻击者在盯着。一旦 Web 进程权限被拿下，数据库连接凭据、用户数据、插件与主题文件都可能暴露，后续可能是挂马、SEO 投毒、植入后门，或者把服务器当成进一步渗透内网的跳板。对没有专职安全团队的中小企业而言，一次失守往往同时意味着数据泄露、业务中断和合规整改压力。
对只维护、不升级的存量老站也要再说一句：4.6 及更早的版本已经没有官方补丁，而互联网上的扫描和利用尝试不会因此停下，迁移到受支持的分支本身就是安全处置的一部分。
排查思路：四步自查
第一步，核对后台「更新」页显示的实际版本号，不要想当然地认为自动更新已经装上——托管面板的版本记录与站点实际运行的版本有时并不一致。第二步，检查 wp-content/upgrade/ 目录是否存在残留暂存目录，尤其是经历过更新中断的站点；发现残留应先按失陷线索排查，而不是直接删除。第三步，翻 Web 访问日志，重点核对升级窗口前后对 wp-content/upgrade/、setup-config.php 的请求，以及任何来自外部的 wp-admin 安装器访问；命中不等于失陷，但结合站点更新记录的时间线，它们是重要的调查线索。第四步，使用 wp core verify-checksums 校验核心文件完整性（只读检查，安全无副作用），顺带排查陌生管理员账户、异常外联和近期新增的 PHP 文件。
修复与缓解建议
根本修复是升级：立即将站点升级到所在分支的修复版本（7.1.4 或对应回移版本），不要跨分支跳跃升级，兼容性风险更大。升级前备份数据库与文件并确认恢复流程可用，建议在低峰期操作并评估业务影响，保留回滚窗口。官方明确提醒，不要用手改核心更新器文件的方式替代正式补丁。
在升级前和升级后，都建议在 Web 服务器层封掉暂存目录：Nginx 可使用 location ~* ^/wp-content/upgrade/ { deny all; } 并禁止该目录下的 PHP 执行，Apache 使用对应的 .htaccess 规则；有 WAF 的站点应拦截对 setup-config.php 及 wp-content/upgrade 路径的异常请求。这也是官方给出的临时缓解措施，即使打完补丁也建议长期保留。使用 Wordfence 的用户应确认防火墙已启用 Extended Protection 模式，让防火墙在 WordPress 之前拦截直接的 PHP 请求——据 Wordfence 说明，免费版规则存在约 30 天延迟，不要把保护窗口完全押在免费规则上。更新中断过的站点，升级完成后要确认暂存目录已被清理、没有残留的可执行 PHP 文件。
后续观察
KEV 给出的联邦修复期限是 11 月 6 日，按照攻击者“等全网任意一次更新开始”的打法，针对暂存路径的扫描和利用尝试还会持续相当一段时间。建议站长关注 WordPress 官方安全公告频道，使用托管主机或面板的用户则要主动确认服务商的补丁版本与实际部署时间，而不是被动等待。更长期的认知是：升级动作本身也是攻击面——把更新窗口期纳入日常运维的监控项，为自动化更新配置中断告警，才能在下一个“趁你升级时动手”的漏洞出现前少一点被动。
（本文信息以 WordPress 官方公告、CISA KEV 目录及 Wordfence、奇安信 CERT 等机构通告为准；具体修复版本清单与服务器配置示例请在操作前以官方文档核对。）
暂无评论内容