WordPress wp2shell 漏洞复盘

摸鱼大王 2026-07-18

397

折腾

前言

今天看到有一条公众号文章热度挺高，标题——WordPress REST API 批处理路由混淆与 SQL 注入远程代码执行漏洞，CVSS 9.8。我自己就是 WordPress 搭建的博客，这种「未授权 RCE」级别的洞，先看一眼。

看完原文又去翻了一圈官方公告和研究团队原文，发现公众号里看到的只提了一个 CVE，实际是两个 CVE 串在一起的链条利用。而且影响范围也比原文写的更广——6.8 分支也中招。这里记一下，免得后面自己又忘了。

漏洞概览：wp2shell

这次漏洞代号 wp2shell，由 Searchlight Cyber 的安全研究团队 Adam Kues 报告。核心是 WordPress 核心代码里两个问题串起来：

CVE-2026-63030：REST API /batch/v1 端点的路由混淆。处理批量子请求时，serve_batch_request_v1() 构建了 $matches（处理程序）和 $validation（验证结果）两个并行数组。但当子请求路径在 wp_parse_url() 解析失败时，该子请求只被追加到 $validation，没进 $matches，数组错位了，后续子请求就被错配到别的处理程序上。
CVE-2026-60137：借着上面的错位，攻击者把 GET 参数（如 author_exclude）塞进内层 POST 请求里。这个参数到了 WP_Query 时没经过净化就直接拼到 SQL 语句里，形成布尔型 + 时间型盲注。

光 SQL 注入已经够烦了，但作者把链拉满了：通过注入读数据库 → 拿到管理员密码哈希 → 离线破解 → 后台上传恶意插件 → 任意代码执行。从「未授权」一路到「拿 shell」，这就是 wp2shell 名字的由来。

CVSS 9.8，攻击复杂度低，无需任何权限，无需用户交互，通过网络直接可达。500万+ WordPress 站点都在射程内。

影响范围

去 WordPress 官方公告一看，6.8 分支也受影响（只中了第一个 CVE，没中第二个，但也得修）。完整范围如下：

WordPress 6.8.0 - 6.8.5（仅 CVE-2026-60137）
WordPress 6.9.0 - 6.9.4（两个 CVE 全中）
WordPress 7.0.0 - 7.0.1（两个 CVE 全中）
WordPress 7.1 beta1（两个 CVE 全中）

6.8 之前的版本不受影响。安全版本是 6.8.6 / 6.9.5 / 7.0.2 / 7.1 beta2。

我自己的站是 7.0.1，正好在坑里。

技术原理

这块我边看边记，方便理解。REST API 的 batch 端点允许一次请求里塞多个子请求，本意是减少 HTTP 往返。处理逻辑大概是这样：

遍历每个子请求，用 wp_parse_url() 解析它的 path。
根据解析结果，把对应的处理程序追加到 $matches，把验证结果追加到 $validation。
两个数组按下标一一对应，后续按 $matches[i] 取处理程序，$validation[i] 取验证结果。

当 wp_parse_url() 解析失败时（比如构造了畸形的 path），代码只往 $validation 追加，没往 $matches 追加。$matches 少了一个元素，下标全错位。第 N 个子请求拿到的处理程序，其实是第 N+1 个的。

攻击者就利用这个错位：把一个本该走 A 处理程序的请求，送到本该走 B 处理程序的逻辑里。B 处理程序恰好接受 author_exclude 这种 GET 参数，并把它喂给 WP_Query。WP_Query 没对这个参数做类型/格式校验，直接拼进 SQL。注入就成立了。

盲注虽然慢，但稳。一点点把 wp_users 表里的 user_pass 字段 dump 出来，拿到 phpass 哈希，离线爆破。WordPress 默认用户名 admin 加弱口令哈希，破解不算难。拿到管理员账号后，后台「上传插件」上传个伪装成 .zip 的恶意插件，激活，shell 就落地了。

修复

官方 7 月 17 日发了强制自动更新，受影响版本的站点大部分应该已经自动升上去了。手动升级的话：

7.0 分支 → 升到 7.0.2
6.9 分支 → 升到 6.9.5
6.8 分支 → 升到 6.8.6
7.1 测试分支 → 升到 7.1 beta2

后台「更新」页面点「立即更新」，或去 WordPress.org 下载 7.0.2 手动覆盖。升级前备份数据库和文件，别偷懒。

如果暂时没法升级（比如改过核心代码、插件兼容性没测完），先做应急：

WAF 拦截：在 Nginx 或 WAF 层拦掉 /wp-json/batch/v1 和 ?rest_route=/batch/v1 两条路径。我是直接在 Nginx 加了几行：

# 拦掉匿名访问的 batch API
location ~ ^/wp-json/batch/v1 {
    if ($http_authorization = "") {
        return 403;
    }
}

# 拦掉 rest_route 查询参数形式
if ($arg_rest_route ~* "^/batch/v1") {
    return 403;
}

插件禁用：装个 Disable WP REST API 之类的插件，直接禁掉匿名用户的 REST API 访问。风险是可能影响部分依赖 REST API 的功能（比如区块编辑器、某些插件的回调）。
Searchlight Cyber 的应急插件：研究团队放了个自定义插件 disable-batch-api-for-unauth.php，放到 wp-content/plugins/ 下启用，强制 REST Batch API 需身份验证。比全局禁用 REST API 影响面小。

这几个都是临时措施，可能影响合法业务，升级到安全版本后记得撤掉。