新型 wp2shell WordPress 核心漏洞可让未认证攻击者执行任意代码

匿名 HTTP 请求可在 WordPress 网站上执行任意代码。该漏洞存在于 WordPress 核心中，因此即使是未安装任何插件的默认安装环境，也会受到影响。

在上周五之前，所有运行 WordPress 6.9 和 7.0 系列版本的网站均存在漏洞风险。随后，WordPress 发布了 6.9.5 和 7.0.2 两个安全更新，并通过其自动更新系统启动了官方所谓的 “强制更新（Forced Updates）” 机制，以促使受影响的站点尽快完成升级。

该漏洞由 Searchlight Cyber 攻击面管理（Attack Surface Management）部门 Assetnote 的安全研究员 Adam Kues 发现，并通过 WordPress 的 HackerOne 漏洞奖励计划进行了负责披露。研究团队随后发布了一篇名为 wp2shell 的技术文章，其中指出，该漏洞 “无需任何的前置条件，匿名用户即可利用”。

不过，Assetnote 暂时没有公开漏洞的技术细节，而是在 wp2shell.com 上提供了一个在线检测工具，方便网站管理员检查自己的 WordPress 实例是否受到影响。

WordPress 于 2026年7月17日发布了 6.9.5 和 7.0.2 版本，这两个版本修复了一个存在于核心代码中的预身份验证远程代码执行漏洞。攻击者无需登录，仅需发送匿名 HTTP 请求，即可攻击未安装任何插件的默认 WordPress 环境。

受影响版本包括 WordPress 6.9.0 至 6.9.4，但已在 6.9.5 中修复；以及 WordPress 7.0.0 至 7.0.1，但已在 7.0.2 中修复。

目前，WordPress 尚未说明，对于已关闭自动更新功能的网站，其所谓的 “强制更新” 机制是否仍会生效。因此，网站管理员不应假设补丁已经自动安装，而是应该主动确认当前运行的实际版本。与此同时，7.1 Beta 2 版本也已包含相同修复。此外，仍停留在 6.8 分支的网站同样收到了更新，不过 6.8.6 修复的是另一支安全团队发现的第二个 SQL 注入漏洞，与此次远程代码执行漏洞无关。

Searchlight 在文章中提到，全球已有超过 5 亿个网站使用 WordPress。不过，这一数字代表的是 WordPress 的整体安装规模，而非此次漏洞的实际影响范围。由于存在缺陷的代码仅仅是从 6.9 版本才开始引入，而 6.9 直到 2025 年 12 月 2 日才正式发布，因此所有受影响的网站使用的都是不到 8 个月前发布的新版本。目前，无论是 Searchlight 还是 WordPress 官方，都没有披露究竟有多少网站在使用这些受影响版本。

相比研究人员，WordPress 官方对漏洞类型的描述更加具体。官方发布说明称，该漏洞属于 “REST API 批处理路由（Batch Route）混淆与 SQL 注入问题，并最终导致远程代码执行”。 此次安全更新修复了一个严重漏洞和一个高危漏洞，但官方并未说明哪一个对应远程代码执行，哪一个对应 SQL 注入。

WordPress 的版本更新页面显示，7.0.2 共修改了三个核心文件，分别是 /wp-includes/rest-api/class-wp-rest-server.php、/wp-includes/class-wp-query.php 和 /wp-includes/rest-api.php，这三处修改涵盖了此次两个安全漏洞的修复。

值得注意的是，此次涉及的 REST API batch endpoint（批处理接口） 并非新功能。WordPress 自 2020 年 11 月发布的 5.6 版本起便已提供该接口，并一直公开其请求格式。然而，截至目前，官方尚未解释究竟是 6.9 版本中的哪些代码的更改导致该接口出现安全漏洞。

截至 7 月 18 日，无论是 WordPress 官方公告还是 Searchlight 的安全分析，都尚未为该漏洞分配 CVE 编号，也没有公布 CVSS 风险评分。因此，依赖 CVE 数据进行检测的漏洞扫描器、资产管理平台以及安全库存系统目前都无法识别这一漏洞。同时，美国网络安全和基础设施安全局（CISA）也必须等待 CVE 编号发布后，才能将其纳入已知被利用漏洞（KEV）目录。对于目前来说，可靠的做法是安全团队根据 WordPress 版本号判断是否存在风险，而不是依赖 CVE。

如果暂时无法立即升级，Searchlight 提出的所有缓解措施都围绕着阻止匿名用户访问 batch/v1 接口展开。这些措施都只是临时的方案，最终仍应尽快升级到官方修复版本，同时它们也可能影响正常的业务集成。

例如，可以在 Web 应用防火墙（WAF）中同时拦截 /wp-json/batch/v1 和 rest_route=/batch/v1 两种访问方式。研究人员特别强调，仅封锁 /wp-json 路径并不足够，因为攻击者仍可通过查询字符串形式访问相同接口。此外，还可以直接关闭 WordPress REST API，从而彻底禁止所有匿名 REST 请求；或者安装一个简单的临时插件，在 rest_pre_dispatch 阶段拦截并拒绝所有匿名的 /batch/v1 请求。

截至 7 月 18 日，尚未有公开报告显示该漏洞已被攻击者实际利用。由于目前既没有 CVE 编号，也没有公开的攻击特征或检测规则，安全行业对此漏洞的监测仍然具有局限性。

但是，大规模利用 WordPress 漏洞发起攻击早已成为网络犯罪中的成熟模式。就在今年 6 月，一个缓存插件漏洞导致攻击组织 WP-SHELLSTORM 根据其自身统计，成功入侵超过 1.7 万个 WordPress 网站。值得注意的是，该漏洞当时已经公开、已有补丁，而且只有在启用非默认配置时才会受到影响。

今年 5 月，当 Drupal 修复其核心中的匿名 SQL 注入漏洞后，Searchlight 在补丁发布当天便完成了漏洞分析，并公开了两个可工作的概念验证（PoC）。虽然那次分析针对的是其他厂商的漏洞，以及Searchlight 并没有义务以同样方式公开自己发现的 WordPress 漏洞，但这一案例说明，仅仅一天时间，研究人员便足以根据公开补丁逆向分析出漏洞原理。因此，此次 Searchlight 暂不公开技术细节，显然是希望为防御团队争取更多部署补丁的时间。

由于 WordPress 核心完全开源，7.0.1 与 7.0.2 两个版本的源代码均已公开存放在官方发布的仓库中，任何人都可以通过比较两个版本的差异来推断漏洞原理。这也是所有开源项目共同面临的一个困境：发布补丁的同时，也意味着向外界公开了分析漏洞的 “路线图”。项目维护者唯一能够控制的变量，就是补丁究竟能否在攻击者完成逆向分析之前，能够足够快地部署到大多数用户的网站上。

WordPress 已经在上周五采取了这一行动。接下来，攻击者是否开始针对 batch/v1 接口发起大规模扫描，将体现在相关访问流量中；而 WordPress 官方公布的版本分布统计，则能够反映出究竟有多少网站已经成功完成升级。最终，人们关注的往往只是其中一个数字是否领先于另一个。