2026年9月22日，即国庆日假期前夕，WordPress 发布了安全更新 7.1.2，以修复 CVE-2026-87902。这个漏洞不在某个插件或主题中，而是在 WordPress 核心中，影响从 4.7.0 到 7.1.1 的每个版本。同一天 UTC 时间 11:49（利雅得时间下午 2:49），安全公司 Patchstack 发现了首次利用该漏洞的尝试；不到四小时后，又发现了首次尝试向网站服务器写入文件。

攻击如何在五天内扩散

随后攻击迅速扩散。根据 CrowdSec 于今天（9月28日）发布的报告，其网络在9月23日至27日期间，记录到来自 30,813 个不同 IP 地址、与该漏洞相符的 322,680 条攻击信号，并在9月27日达到峰值，当天为 124,154 条信号。沙特国家网络安全局（NCA）于9月23日发布了编号为 2026-7873 的严重级别警报，美国机构 CISA 于9月25日将该漏洞加入其已知被利用漏洞目录。

通俗地说，这个漏洞做了什么

当访客请求一个页面时，WordPress 会决定使用主题中的哪个模板文件来显示它。漏洞就出在这一步：未登录的攻击者可以把它指向服务器上位于主题文件夹之外的某个 PHP 文件，而 WordPress 会运行该文件。WordPress 给该漏洞的评分为 9.2 分（满分 10 分）；CISA 的评分为 8.1 分。

当 WordPress 安全公告和研究人员报告中提到的条件同时满足时，它就会变成对网站的控制：

  • 主题：当前启用的主题包含一个名称以 page- 开头的文件夹。公告列出的此类主题包括 Twenty Twelve、Twenty Fourteen、Neve、Hestia 和 Sydney。
  • 一项 PHP 设置：开启了 register_argc_argv。据 CrowdSec 称，这是官方 PHP Docker 镜像以及运行 8.5 之前版本 PHP 的 cPanel 服务器上的默认设置。
  • 一个辅助文件：服务器上存在 PEAR 的 pearcmd.php。攻击者利用它写入新的 PHP 文件，也就是一个在更新后依然存在的后门。

因此，这个漏洞对每个网站的影响并不相同，但 Security Affairs 这样总结：代码执行需要服务器配置恰好符合条件，而很多服务器恰好符合。企业主通常不知道启用的是哪个主题，也不知道服务器是如何配置的，所以稳妥的假设是：在被证明安全之前，网站都处于暴露状态。

为什么攻击在数小时而不是数周内到来

安全更新本质上就会暴露漏洞所在的位置，因为代码改动是公开的。Patchstack 表示，最早的攻击载荷与修复所封堵的模式完全一致，这意味着编写者是从修复本身入手，而不是独立发现的。最初的尝试请求的是普通的 WordPress 核心文件，例如 wp-login.php 和 wp-cron.php，以观察网站如何响应，然后才转向写入文件。

这些流量还带有自动化扫描器和已公开的概念验证代码的痕迹。对企业主来说，这意味着没有人专门挑选您的网站。这些工具会扫遍它们能触及的每一个 WordPress 网站，而被入侵的网站与干净的网站之间的区别，就在于更新是否比它们先到。

您的网站会自动更新吗？

很可能会，但不要想当然。WordPress 自 3.7 版本起就有自动后台更新，自 5.6 版本起，新安装的网站会自动更新次要版本和主要版本。7.1.2 的发布公告称，支持自动后台更新的网站将开始自动更新。

但只需在 wp-config.php 中加一行，就可以关闭自动更新。有些开发人员会故意关闭它，以免更新破坏定制主题；也有些主机服务商在自己那一端管理更新。一个多年前由自由职业者搭建、合同早已结束的网站，可能一直停留在旧版本上而无人察觉。检查方法如下：

  • 登录网站后台，打开“仪表盘”菜单下的“更新”页面，就能看到当前版本。
  • 安全版本是 7.1.2 或更高版本。如果您的网站使用较旧的分支，修复已覆盖直至 4.7 的每个分支，包括 7.0.6、6.9.9、6.8.10 和 4.7.37；完整清单见资料来源中链接的 WordPress 安全公告。
  • 请注意，WordPress 表示只有最新版本才获得积极支持。停留在旧分支上的网站虽然收到了这次修复，但已是在借来的时间里苟延残喘。关于新版本能为企业网站带来什么，我们在 WordPress 7.1：主要新功能 中做了介绍。

Elementor 也有问题：一个链接就足够

同一周，广受欢迎的 WordPress 页面构建器 Elementor 修复了一个仅存在于 4.3.0 和 4.3.1 版本中的漏洞。如果网站管理员在登录状态下打开一个精心构造的链接，攻击者就能创建一个由其控制的管理员账户，而这个链接可能通过电子邮件、聊天或评论送达。据 BleepingComputer 报道，这些版本运行在多达 200万 个网站上。修复随 4.3.2 版本于9月24日发布，截至该网站发稿时，尚未报告有活跃的利用。

请确保 Elementor 为 4.3.2 或更高版本，并将以下做法定为团队规定：登录网站后台时，不要打开消息或评论中的链接。

如果您的网站自9月22日以来没有更新过

  • 立即更新：如果开发人员担心更新会造成故障，Patchstack 表示，可以通过拦截 pagename 参数中的目录遍历尝试，或关闭 register_argc_argv，暂时封堵这条路径。这需要主机服务商或开发人员来做，而且不能替代更新。
  • 假设您的网站已被探测过：请开发人员或主机服务商查找没有人添加过的 PHP 文件，尤其是在 /tmp 和 /var/tmp 中；Patchstack 指出，poc87902.php 和 wp-pear-rce-flag.php 等文件是代码执行成功的迹象。
  • 如果发现了异常：请将其作为安全事件而非一次更新来处理。更改管理员账户、数据库和主机的密码，从干净的备份中恢复网站，然后再进行更新。
  • 如果网站存有客户数据：如果网站存储订单、联系表单或账户，那么沙特数据和人工智能管理局（SDAIA）关于个人数据泄露事件的指南要求，控制者在知悉可能对数据或数据所属个人造成损害的泄露后 72 小时内通知主管机构。

Origami 的观点

许多公司网站基于 WordPress 搭建，随后却被当作一本印刷宣传册来对待：开发人员交付，业主付款，没有人问由谁来保持更新。这个漏洞提醒我们，网站是运行在面向互联网的服务器上的一个活系统，而从修复发布到攻击者到来之间的间隔，如今是以小时计算的。真正的问题不是 WordPress 是否安全，因为它已经修复了漏洞，并把修复推送到了直至 4.7 的每个分支。真正的问题是，贵公司由谁负责安装它。

因此我们认为，网站维护合同应规定安装关键安全更新的最长时限，要求设立 staging 副本，在更新上线前先在其中测试，并保留存放在服务器之外的定期备份。如果更新总是因为主题的定制方式每次更新都会出问题而被推迟，那是网站搭建方式的问题，而不是 WordPress 的问题，值得在下一个漏洞出现之前修复。

结论：三个步骤

  • 今天：打开后台，确认版本为 7.1.2 或您所在分支的修复版本，并确认 Elementor 为 4.3.2 或更高版本。
  • 本周：请开发人员或主机服务商扫描服务器，查找陌生的 PHP 文件，并以书面形式确认自动更新已开启。
  • 本月：在维护合同中加入安装安全更新的最长时限，并指定负责此事的人员。

资料来源