2026-11-09 01:10:41 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

WordPress升级窗口，藏着未授权的 Shell 那几秒，最危险

宝十八
宝十八

网络安全老宋

2026年11月7日 12:00
山东

去阅读

导语： 你好，我是网络安全老宋。安全攻防干货准时送达！

网络安全老宋// 漏洞预警 · CMS

// 漏洞预警 · CMS

升级窗口，藏着未授权的 Shell 那几秒，最危险

WordPress 核心升级时，暂存目录在公网暴露几秒，未登录就能跑代码。

CVE-2026-119977WordPress CoreTOCTOU

●一句话精华
升级的那几秒窗口，是黑客守株待兔的破绽——守门人先锁好门。

10 月 28 日，WordPress 发了 7.1.4，修掉一个被评级 8.1 的核心漏洞。补丁上线后不到几小时，攻击者就开始大规模扫描一个特定路径：wp-content/upgrade/。这不是某个插件的锅，是 WordPress 自己核心升级流程里留的口子——而且在那几秒的升级窗口里，黑客不用登录、不用任何权限，就能在服务器上跑代码。

这件事最反常识的地方在于，漏洞不在你网站跑着的代码上，而在\"更新代码\"的那几秒钟里。WordPress 为了把新版本文件铺到位，会先把它们解压到一个位于网站根目录下、能被 Web 直接打开的暂存目录，等逐文件替换完成才清理，而恰恰是这个\"先放进去、后替到位\"的时间差，给了未授权请求从缝隙里钻进去的机会。攻击者只要不停轮询，总能在替换完成前命中暂存目录里的 PHP 文件。

所以这篇文章不堆 CVE 列表，也不吓唬人，而是把\"升级窗口\"这件事拆开讲：它到底怎么被打穿、影响哪些版本、现在有没有人在打、你今天下班前能做哪几步。先说清楚一个关键点——目前还没有\"已经被攻陷\"的可靠证据，但\"没人得手\"从来不是\"不用修\"的理由，尤其当扫描已经在你门口发生时。

▲ 封面：核心升级解开暂存目录，Web 可达的几秒窗口，被未授权请求命中即 RCE

00先拆掉一个误会：不是插件，也不用登录

先把概念掰清楚。CVE-2026-119977 命中的是 WordPress Core，也就是你用 wp core 更新时那套核心程序，和装在上面的任何主题、插件都没关系。换句话说，你哪怕什么插件都不装、主题用的是官方默认款，只要版本在 4.7 到 7.1.3 之间，就在这条脆弱线上。

更省心也更要命的是，它的利用门槛里没有\"登录\"这一项——Wordfence 把它归类为网络可达、无需权限、无需用户交互，唯一的难度在于攻击时机必须卡在核心升级正在解压的那几秒。这就是为什么 CVSS 定在 8.1 而不是更高：不是危害小，是窗口太短、靠撞运气；可一旦你开着自动更新，这个窗口就会一次次重演，撞上的概率就被放大了。

把\"不用登录\"和\"核心程序\"叠在一起，性质就变了。

▲ 图1：同一条时间轴上，WordPress 替位流程与攻击者轮询重叠的那几秒，即为未授权 RCE 窗口

01原理拆解：TOCTOU 竞态，卡在解压与替位之间

这个漏洞的技术名很拗口，叫\"检查到使用的时间差\"（TOCTOU，CWE-367）。说人话就是：WordPress 在跑\"完整包\"升级时，会先把整个新版本解压到 wp-content/upgrade/ 这个目录，里面的安装器 PHP 文件已经落盘、可以被 Web 直接请求，但整批文件还没被逐项替换到正式位置。

攻击者要做的，就是在那几秒钟里不停去请求暂存目录下的 PHP，等到其中某个文件恰好\"已经在了、但还没被搬走或删掉\"的瞬间就执行它。因为请求是直接打在暂存 PHP 上、根本没经过 WordPress 的正常加载流程，所以你装的任何安全插件都看不到这次请求——它就像绕过前台、从后门直接进了机房。

WordPress 官方在 7.1.4 里的修法也直奔这个口子：把暂存目录名字随机化、加上索引守卫、并且阻止暂存配置数据被不安全地提升。简单说，就是让那个\"可预测、Web 可达\"的暂存目录，变得既猜不到、也访问不了。漏洞的根，是\"先放后替\"这个顺序，不是某个函数的笔误。

02影响面与在野利用：版本广，扫描凶，失陷待确认

影响范围比很多人以为的大：从 4.7.0 一直到 7.1.3，等于把当前还在维护的每个分支都覆盖了。官方一边发 7.1.4，一边把安全修复回迁到 4.7 起的所有老分支，所以不管你卡在哪个版本，都有对应的修复版可升——别拿\"我版本旧\"当不修的借口。

Wordfence 作为这个 CVE 的编号机构（CNA）给出的现场数据值得记住：补丁发布后数小时内，针对那个脆弱暂存路径的探测就出现了，第一天就拦下成千上万次利用尝试，但截至他们的通告，还没有任何\"确认被成功攻陷\"的案例。这既说明攻击者已经在广撒网，也说明真正打穿需要运气；可\"广撒网\"三个字，对开着公网管理、开着自动升级的站点来说，本身就是红灯。

CISA 已经在 10 月底前后把这个漏洞收进 Known Exploited Vulnerabilities（KEV）目录，按 BOD 26-04 给联邦机构下了限期修复令；多家国家级 CERT 也发了预警。具体列入日期各追踪源略有出入，措辞以 CISA 官方目录为准——但\"已被在野利用、需限期修\"这个定性，已经没有疑问。没确认失陷，不代表没人在敲你门。

▲ 图2：下班前 4 步自查——确认版本、立刻升级、查暂存访问、限制公网访问

03今天就能做的自查与处置清单

① 先确认版本。

后台看一下\"WordPress 版本\"那行字，落在 4.7–7.1.3 任一分支、且还没升到对应修复版（7.1 线升 7.1.4，老分支升各自的安全回迁版），就先把它圈出来。
* ② 立刻升级。

直接升到 7.1.4，或者你所在老分支的最新安全回迁版；如果是 wordpress.com 那种全托管、由平台统一维护更新的，平台侧会自动处理升级窗口，你不需要、也不应该手动去跑完整包升级，反而避开了这个口子。
* ③ 查暂存目录是否曾被访问。

翻一遍 Web 访问日志，看 wp-content/upgrade/ 这个路径有没有来自不可信网络的 GET 请求；有，说明已经被扫到，即便没失陷，也该当作\"曾暴露\"来处置。
* ④ 限制外部访问。

在 Web 服务器层（Nginx / Apache）对 wp-content/upgrade/ 加一层拒绝公网访问的规则，哪怕暂时升不了级，也先把这扇临时打开的门从街上搬回院子里。
* ⑤ 给自动升级排个维护窗口。

自动更新本身要保留，但与其让它默默在公网环境里反复重演窗口，不如把升级动作放到内网或维护时段、并配合上面的访问限制来跑。

边界说清楚：上面的动作是\"升级固件 + 收敛暴露面 + 查日志\"，属于运营动作，不涉及对任何第三方系统的未授权探测或修改。

04延伸：自动更新放大了窗口，更新过程也是攻击面

这件事最该让运维警醒的，不是某一个 CVE，而是\"更新过程\"本身长期被当成可信环节。我们盯着运行时漏洞、盯着插件后门，却很少去想：当核心程序自己正在解压、正在替换、正在重启的那几秒，它正处在一种\"半旧不新、部分文件已落地却还没归位\"的脆弱态，而恰恰是这种过渡态，最容易被竞态和 TOCTOU 一类手法钻空。自动更新把这种过渡态从\"偶发\"变成了\"定期重演\"，等于给攻击者一个可预测的作案时间。

再往深一层看，WordPress 这次的修法——随机化目录名、加索引守卫——其实给所有自己做升级、热更新、灰度发布的系统提了个醒：凡是\"先把新文件落到可被访问的位置、再异步替位\"的设计，都得补一道\"替位完成前外部不可达\"的闸门，否则下一次踩坑的，可能就是你正在用的另一套发布流程。