WordPress 核心漏洞 wp2shell，波及超 5 亿网站

2026 年 7 月，网络安全研究机构 Searchlight Cyber 的安全研究员 Adam Kues 公开了一个 WordPress 核心级漏洞，编号为 wp2shell。这是一个预身份验证远程代码执行（Pre-Authentication RCE）漏洞，攻击者无需登录、无需安装任何插件，直接在原生安装的 WordPress 实例上即可实现远程攻击。

由于全球有超过 5 亿个活跃网站运行在 WordPress 上，这一漏洞的影响范围有多大就不必细说了吧。

漏洞概况

wp2shell 为什么危险程度高，因为其攻击门槛极低。与绝大多数 WordPress 安全事件不同，这次的问题出在 WordPress Core 本身，而非第三方插件或主题。攻击者不需要任何前置条件，匿名用户即可在默认安装的 WordPress 上完成远程代码执行。

为了给全球站点管理员留出足够的修补窗口，Searchlight Cyber 目前没有公开漏洞的技术细节，但已提供了在线检测工具，供管理员自查站点是否受影响。

受影响版本一览

WordPress 版本范围	是否受影响	修复版本
< 6.9.0	不受影响	---
6.9.0 -- 6.9.4	受影响	6.9.5
7.0.0 -- 7.0.1	受影响	7.0.2

如果站点运行在 6.9.0 到 6.9.4 之间的版本，需要升级到 6.9.5；运行在 7.0.0 或 7.0.1 的站点则需要升级到 7.0.2。6.9.0 以下的版本不受此漏洞影响。

为什么 wp2shell 值得高度关注

过去几年，WordPress 的安全问题大多集中在插件生态上，比如某个下载量百万级的插件出了 SQL 注入或 XSS 漏洞，管理员卸载或更新插件就可以解决。但 wp2shell 的情况完全不同。

第一，漏洞位于 WordPress Core。 也就是说无论站点安装了什么插件、使用了什么主题，只要 WordPress 版本在受影响范围内，就可能被利用。

第二，这是一个预认证漏洞。 攻击者不需要拿到任何账号密码，也不需要通过社会工程学或钓鱼获取管理员凭证，直接对着目标站点发起攻击即可。这种零交互攻击面一旦被自动化武器利用，大规模扫描和批量入侵只是时间问题。

第三，影响基数太大。 WordPress 在全球 CMS 市场中占据约 43% 的份额，活跃站点数以亿计。即使假设只有 10% 的站点处于受影响版本范围内，受威胁的站点数量也是千万级别的。

完整修复与缓解方案

方案一：直接升级 WordPress（推荐）

升级是解决问题的最佳途径。WordPress 7.0.2 和 6.9.5 已经包含了针对 wp2shell 的修复补丁。

进入 WordPress 后台 → 仪表盘 → 更新，确认当前版本号，并执行更新操作。如果站点启用了自动更新机制，建议登录后台确认更新是否已经被自动应用。

方案二：安装 Disable WP REST API 插件

如果因为兼容性测试或其他原因暂时无法升级，可以先安装 Disable WP REST API 插件。这个插件会禁止未认证用户访问 WordPress REST API，从而切断 wp2shell 的攻击路径。

需要注意的是，这可能影响站点中依赖 REST API 的功能（比如某些前端渲染框架、headless WordPress 架构或第三方对接），安装后应做一轮功能回归测试。

方案三：通过 WAF 防火墙拦截特定路径

如果站点前面部署了 WAF（Web Application Firewall），可以添加规则拦截以下两个请求模式：

拦截 URL 路径：

bash 复制代码

/wp-json/batch/v1

拦截查询参数：

ini 复制代码

rest_route=/batch/v1

两个规则必须同时配置。只拦截其中一个不足以防御此漏洞，因为 WordPress REST API 支持通过 URL 路径和查询参数两种方式访问同一个端点。

以 Nginx 为例，可以在 server 配置块中添加：

bash 复制代码

# 拦截 wp2shell 漏洞相关的 batch API 路径
location ~* /wp-json/batch/v1 {
    deny all;
    return 403;
}

# 拦截通过查询参数访问 batch API 的请求
if ($query_string ~* "rest_route=/batch/v1") {
    return 403;
}

如果使用的是 Apache 且开启了 mod_rewrite，可以在 .htaccess 中添加：

bash 复制代码

# 拦截 batch API 路径请求
RewriteEngine On
RewriteRule ^wp-json/batch/v1 - [F,L]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]

方案四：部署自定义安全插件（官方推荐）

Searchlight Cyber 提供了一段可直接部署的 WordPress 插件代码，作为应急措施使用。这段代码的逻辑是拦截所有未认证用户对 /batch/v1 端点的请求，已登录用户不受影响。

将以下代码保存为 disable-batch-api-for-unauth.php，通过 SSH 或 FTP 上传到 WordPress 站点的 wp-content/plugins/ 目录，然后在后台插件页面启用。

php 复制代码

<?php
/**
 * Plugin Name: Disable Unauthenticated REST Batch API
 * Description: Requires an authenticated WordPress user for REST batch requests.
 * Version: 1.0.0
 * Requires at least: 5.6
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Reject anonymous requests to the core REST batch endpoint.
 *
 * @param mixed           $result  Pre-calculated dispatch result.
 * @param WP_REST_Server  $server  REST server instance.
 * @param WP_REST_Request $request Current REST request.
 * @return mixed|WP_Error
 */
function wporg_require_authentication_for_rest_batch( $result, $server, $request ) {
    $route = untrailingslashit( $request->get_route() );

    if ( '/batch/v1' !== $route || is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_batch_authentication_required',
        'Authentication is required to use the batch API.',
        array( 'status' => 401 )
    );
}

add_filter( 'rest_pre_dispatch', 'wporg_require_authentication_for_rest_batch', -1000, 3 );

代码解读：

rest_pre_dispatch 是 WordPress REST API 在实际执行请求前的一个过滤钩子，优先级设为 -1000，确保这个安全检查在其他过滤器之前执行
untrailingslashit() 去除路由末尾可能存在的斜杠，避免因路径格式差异导致拦截失效
如果请求路由为 /batch/v1 且用户未登录，直接返回 WP_Error，HTTP 状态码 401
已登录的管理员或编辑正常使用 batch API 不受影响

这个插件适合作为临时应急手段，在完成版本升级后建议卸载。

关于 REST API Batch 端点

WordPress 在 5.6 版本中引入了 REST API batch 功能（端点路径为 /batch/v1），允许客户端在一次 HTTP 请求中打包多个 REST API 调用。设计初衷是减少网络往返次数，提升前端编辑器（如 Gutenberg 块编辑器）的性能。

这个机制本身并不是安全漏洞，但批量请求的处理链路比单次请求更加复杂，涉及权限验证、请求拆分、响应聚合等多个环节。wp2shell 正是利用了这条链路中的某个缺陷实现了远程代码执行。

对于不依赖 batch API 的站点（绝大多数标准 WordPress 站点都不直接调用这个端点），在临时缓解期间关闭此端点几乎不会产生功能影响。

本地开发环境的安全管理：从补丁到基础设施层面的思考

wp2shell 事件说明了一个被一直忽视的问题，大量 WordPress 站点运行在开发者的本地环境中进行开发和测试，而这些本地实例的安全更新同样不能被忽略。

如果使用的是本地集成开发环境工具（比如 ServBay 这类AI原生开发管理平台、数据库、PHP 版本的一站式工具），WordPress 的安装和版本管理通常由工具统一托管。这类工具在处理安全事件时有一个优势，管理员可以在一个控制面板中看到所有本地站点的 PHP 版本和 WordPress 版本状态，批量完成升级操作，而不必逐个站点登录后台去点更新按钮。

更进一步来看，现在越来越多的开发者开始使用 Coding Agent（如 Claude Code、Cursor、Codex）来辅助开发和维护 WordPress 站点。在这种工作模式下，API 密钥的安全管理成了另一个不容忽视的环节。开发者手里通常会有多个 AI 服务的 API key 散落在不同的项目配置文件中，一旦某个 WordPress 站点被入侵，攻击者可能通过遍历文件系统找到明文存储的 API 密钥。

ServBay 的 AI Gateway 就是为了解决这个问题而存在的，它把所有 AI 服务的 API 密钥集中在本地网关中加密保管，各个项目和工具通过统一入口调用 AI 服务，密钥本身不会写入项目代码或配置文件。而且还能自己创建虚拟密钥。

即使某个 WordPress 实例遭到入侵，攻击者也拿不到 AI 服务的原始密钥。这种把凭证管理从应用层下沉到基础设施层的做法，可以有效降低凭证泄露后的影响范围。

自查清单

在完成修复后，建议对站点做一轮完整的安全自查：

确认WordPress版本 --- 登录后台查看仪表盘右下角的版本号，确认已升级到 6.9.5 或 7.0.2 以上
使用官方检测工具 --- 访问 Searchlight Cyber 提供的 wp2shell 在线检测页面，输入站点域名进行扫描
检查用户列表 --- 在后台 → 用户中查看是否有不明管理员账号被创建
审计文件变更 --- 检查 wp-content 目录下是否有近期出现的可疑 PHP 文件
检查定时任务 --- 通过 WP-Cron 或服务器级 cron 检查是否有异常的定时任务被添加
审计 REST API 日志 --- 如果站点启用了请求日志，检查是否有对 /batch/v1 端点的异常调用记录

总结

wp2shell 是近年来 WordPress 生态中出现的核心级漏洞之一。它不依赖插件、不需要认证、攻击面覆盖所有默认安装的受影响版本。好消息是 WordPress 官方响应速度很快，6.9.5 和 7.0.2 已经包含修复补丁。

对于站点管理员来说，立刻升级是第一选择。如果短时间内无法升级，按照上文提供的 WAF 规则或自定义插件方案做临时缓解，也能有效阻断攻击路径。

对于使用本地开发环境管理多个 WordPress 实例的开发者来说，这次事件也是一个提醒：本地站点的安全维护同样需要被纳入日常运维流程中。统一的环境管理工具和集中的凭证管理策略，能够在安全事件响应时提升效率。