这个月换了个方向——出事的是 WordPress 核心本身，而且已经在被打了。
先说结论，不绕：
🔴 WordPress 核心有一个高危漏洞正在被批量利用。影响 4.7.0 到 7.1.1，将近十年内的版本全在内。9 月 22 日已经发布修复，现在还在跑旧版本的站，立刻去更。
下面把这件事拆开讲。包括一个几乎没人说清楚、但你必须知道的事：不是所有站都会被"执行代码"。
一、这次到底出了什么事
漏洞编号 CVE-2026-87902，由安全研究者 Robert Ressl 通过 WordPress 的 HackerOne 项目报告，2026 年 9 月 22 日公开并修补。
出问题的位置是 WordPress 核心的页面模板解析。简单说，WordPress 在处理一个页面的模板时，会把用户请求里的一个参数拼进文件路径，但没有校验这个参数里有没有 ../ 这种"往上跳目录"的东西。
正常页面路径不会带这个。有人恶意的带上，就能让服务器去加载主题目录之外的任意一个可读的 PHP 文件。
攻击者还用一个双重编码的小技巧（%252e%252e%252f 来表示 ../），绕过了 WordPress 原有的点号替换过滤。
📊 影响范围：WordPress 核心 4.7.0 – 7.1.1，未认证即可触发
修复版本是 7.1.2，同时向所有仍受支持的分支做了回移：
|
|
|
|---|---|
| 7.1.x | 7.1.2 |
| 7.0.x | 7.0.6 |
| 6.9.x | 6.9.9 |
| 6.8.x | 6.8.10 |
| 5.x / 4.9.x / 4.8.x / 4.7.x |
|
| 4.6 及更早 |
|
⚠️ 老站注意：从 4.x、5.x 直接跨大版本升到 7.x，别直接在生产环境点。先确认两件事——PHP 版本够不够，主题和插件在新版本上还跑不跑得起来。不然你修完了漏洞，站先崩了，一样得挨客户骂。
二、这个漏洞麻烦在哪：补丁当天就有人在打
这是我觉得最该让你重视的部分。
一般漏洞从公开到被大规模利用，中间通常有个窗口期，几天到几周不等。这次基本没有窗口期。
它每天的数据是这样的：第一天 14,938 条，最后一天 124,154 条。攻击来源从 237 个涨到 23,321 个。
⚠️ 这个增长曲线说明一件事：你面对的不是"某个黑客盯上了你"，是全网无差别的批量扫描。 "我站小，没人看得上"这个理由，在这类攻击面前完全失效——脚本不看你是谁，只看你有没有响应。
已经观测到的攻击痕迹包括：往服务器写 wp-pear-rce-flag.php、poc87902.php 这类文件，以及 /tmp/ 目录下的可疑上传文件。
三、说清楚：不是所有站都会被"执行代码"
这一段是我想认真讲的，因为满网的报道都在喊"WordPress 爆 RCE，所有站中招"，这个说法不准。
这个漏洞有两个层次，严重程度和触发条件完全不同：
第一层：读取任意文件——所有未修补的站都成立
攻击者能让服务器加载主题目录之外的 PHP 文件。这一层不需要任何前提条件，只要是未修补的版本，就能被利用。
光这一层就够致命了——服务器上能读的 PHP 文件，他都能读。 而这里面最要命的一个叫 wp-config.php，里面装着你的数据库账号密码、各种密钥。
数据库到手，你的客户名单、订单、会员信息就都在别人手上了。
第二层：远程执行代码（RCE）——需要特定的前提
要让"读文件"升级成"在服务器上跑代码"，得同时满足几个条件：
💡 好消息是：这几个条件同时满足的情况不算普遍，所以真正被完整拿下（拿到代码执行权限）的站，比被扫描的站少得多。
坏消息是：满足条件的主题不少。已知受影响的包括 WordPress 自带的 Twenty Twelve 和 Twenty Fourteen，以及 Neve、Hestia、Sydney 这些装机量很大的第三方主题。
所以正确的判断是：
🔴 别被"所有站都会被 RCE"吓到，但也别因此就不更新。 光是第一层"任意文件读取"，就足以让你的数据库密码落到别人手里。
四、今天该做什么（从急到缓）
① 先更 WordPress 核心
对一下版本号。你在 4.7 到 7.1.1 之间的任何分支，都在范围内。WordPress 默认开启后台自动更新，很多站其实已经自己更好了——但要手动确认一遍，别假设。
② 更不了的话，先拦 WAF
如果你有 Cloudflare 之类的 WAF，加一条规则：拦截 pagename 参数里带路径穿越特征的流量。
别只写一个 ../，各种编码变体都要覆盖：
../..%2f%2e%2e%2f%252e%252e%252f
（最后一个就是攻击者用来绕过过滤的双重编码形式。）
这条规则很安全——真实的页面别名里永远不会出现 / 和 . 拼在一起的跳目录特征，所以不会误伤正常访客。
③ 关掉 register_argc_argv，删掉 pearcmd.php
这两步是专门针对 RCE 那一层的。如果你用不上 PEAR（绝大多数站都用不上），直接删。这一步能把风险从"代码执行"降回"信息泄露"。
④ 查一遍文件系统有没有陌生的 PHP 文件
重点看这几个位置：网站根目录、wp-content/ 下、/tmp/、/var/tmp/。注意找 wp-pear-rce-flag.php、poc87902.php 以及形如 luci_*.php、zeta_*.php 的文件。
这一步很关键——如果你已经在 9 月 22 日之后被打了，现在补更新也只是止血，不是清除。得先确认有没有被留后门。
⑤ 顺手把插件也过一遍
9 月这一波插件雷区也不少：
|
|
|
|
|---|---|---|
| Teddy Bear Customize Addon |
|
无修复，已从 wp.org 下架，直接删 |
| Bluehost 插件
|
|
|
| The Events Calendar
|
|
6.17.4.1+ |
| ThemeREX Addons |
|
|
| Post Grid and Gutenberg Blocks |
|
|
| MPG |
|
|
⚠️ 遇到 Teddy Bear Customize Addon 这种"没有修复版本"的，别等，直接删。留着它就是留一个已知的洞。
上表是这轮比较值得注意的几个，不是完整清单。处置前建议到 Wordfence、Patchstack 或 WPScan 的漏洞库上按你的插件名再核一遍——插件的漏洞状态变动很快，我不希望你只看一份二手整理就动手。
五、为什么这种事总在 WordPress 上发生
说两句题外话。
这次漏洞影响范围横跨将近十年的版本，听着离谱，但想想 WordPress 的处境就明白了：它要背着十几年的历史包袱，还要让老站能在新 PHP 上跑起来。这种"既要向前兼容、又要向后兼容"的代码，最容易在边角处长出这种问题。
另一件事更值得注意。
WordPress 官方有个叫 "Protect The Shire" 的计划。 从 2026 年 6 月 5 日起，所有插件和主题的发布都要先过一道 6 小时冷却期——这期间，多个 AI 模型加上 Jetpack Scan 会对代码改动做交叉分析，合成一个风险分：
2026 年 7 月 28 日，这套系统真拦下过一个后门——涉事插件约 2 万装机量。因为改动还在冷却期内，带毒的版本从头到尾没被分发出去。从 Wordfence 通知官方到插件被关闭下载，只用了 26 分钟。
这个机制值得知道，因为它意味着：大部分情况下，你的插件自动更新是有人替你把过关的。
但再好的自动化也覆盖不了一件事：你后台那个装了三年、作者早就不更新、你也从来不看的插件。
说到底，WordPress 的安全从来不是"装上就完事"，而是"你这个月看过它没有"。
回到眼前。这次的事其实很简单：
核心更新，插件清理，查一遍文件。 三件事，今天晚上就能做完。
不做的话，你的站在那 3 万个 IP 的名单里，只是时间问题。
资料来源（都可自行核对）：
漏洞状态和攻击规模每天在变，动手处置前请以官方公告为准。