WordPress严重RCE在野利用 立即升级7.1.2

一、事件回顾：9.2分核心漏洞，披露几小时就被打上门

2026年9月22日，WordPress官方发布7.1.2安全更新，修复核心漏洞CVE-2026-87902。该漏洞CVSS评分为9.2，影响4.7.0至7.1.1的所有版本，近十年内的站点几乎全部在范围内。研究者Nicolas Krassas公开了技术细节，安全厂商随后在全球蜜罐中观察到探测流量，并在数小时内看到攻击者从扫描升级为尝试写入恶意PHP文件、执行系统命令。这是典型的“公开即武器化”：从补丁发布到大规模自动化利用，中间没有留出任何缓冲时间。

二、漏洞原理：模板解析少了一次路径校验

漏洞出在页面模板的解析链路上。WordPress在决定用哪个模板渲染页面时，会通过get_page_template()处理候选模板路径，但这条链路没有调用validate_file()做路径合法性校验。攻击者无需登录，只要构造经过双重URL编码的请求参数，就能让站点把服务器上本不该当作模板加载的本地PHP文件当成页面模板，形成本地文件包含。

这只是前置条件，能否升级为远程代码执行取决于两点：主题目录下存在以page-开头的特定目录结构，以及服务器上存在路径可预测、权限可读的PHP文件。研究者给出的组合是利用pearcmd.php——它允许通过查询字符串注入参数，从而把本地文件包含变成任意代码执行。安全厂商同时提醒，若暂时无法升级，可先排查主题目录并关闭register_argc_argv选项，减少这类利用链成立的土壤。

需要强调的是，条件触发不等于安全。互联网上的自动化扫描器不会替你判断站点是否满足全部前提，它只会把所有站点都扫一遍；而这次攻击者的动作已经从探测是否存在漏洞推进到直接写文件、直接执行命令，说明真实入侵已经发生。

三、检测与修复：先补丁，再查有没有被进来

第一步是升级。把WordPress核心更新到7.1.2，并确认更新真实落地——不少站点因为文件权限、缓存或镜像层的问题，后台点了升级但核心文件没变。升级后建议核对版本号与核心文件校验值，并检查是否有旧版本残留目录。

第二步是排查利用痕迹。重点看9月22日以来的Web访问日志，检索带有双重URL编码特征、模板路径穿越以及访问主题目录下PHP文件的请求；再对站点目录做文件完整性比对，找出新增或近期被改动的PHP文件，尤其是上传目录、缓存目录下突然出现的可执行文件；对可疑文件检查是否包含eval、base64_decode与POST参数拼接之类的典型WebShell特征。

第三步是收敛暴露面。WordPress是互联网上被自动化攻击最密集的CMS之一，长期不打补丁等于把服务器钥匙挂在门口。建议把核心、主题、插件的更新纳入例行流程，插件只从官方目录安装，停用并删除不用的主题与插件；管理后台限制访问来源或加二次认证；给站点目录做写权限最小化，让攻击者即使拿到执行入口也难落地。WAF可以争取时间，但不能替代补丁，厂商规则是否覆盖本次漏洞需要自行核实。

四、对青海政企的建议

WordPress在青海的单位里并不少见：不少政企、学校、医院和园区用开源CMS搭官网、信息公开站或专题站，很多是多年前外包做的，上线后无人维护，版本停在老版本。这类站点在本次漏洞里正是最危险的一类——既满足“老版本”的条件，又通常缺少日志、备份和更新机制。

建议在本周内做四件事。一是清点资产：把主域名、二级域名、历史遗留站点全部列出来，确认哪些在用WordPress，别漏掉已经“没人管但还在公网上运行”的站点。二是更新到7.1.2并验证，无法升级的站点按上文关闭register_argc_argv、调整主题目录结构，或直接临时下线。三是查日志与文件：核对9月22日以来的访问日志和站点目录变更，发现可疑PHP文件先取证再清理，不要直接删掉。四是补制度：把CMS版本纳入资产台账与月度巡检，明确责任人，按等保要求留存日志与整改记录，测评时这些记录就是证据。

最后提醒一点：这类高危漏洞的修复窗口已经以小时计，等收到“友商通知”或测评整改单再行动，往往已经晚了一步。对没有专职安全人员的中小单位，最务实的做法是先把互联网暴露的站点收进台账，再按暴露面排优先级，一个季度做一次更新与巡检。