如果你欣赏我的工作，请考虑通过 USDT (TRC20)： TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN 支持本项目
wp2shell 是一个安全研究概念验证，演示了 WordPress 核心中一个结合以下漏洞的预认证漏洞链：
WP_Query SQL 注入该漏洞链演示了如何将这些漏洞组合起来，从未认证的 REST API 请求逐步推进到 SQL 注入、权限提升、管理员账户创建，最终实现认证后的远程代码执行。
[!WARNING]
仅限授权安全研究
本项目仅适用于：
- 漏洞研究
- 防御性验证
- 授权的渗透测试
- 安全实验室
- CTF 竞赛和教育环境
仅可对您拥有或已获得明确书面授权评估的系统进行测试。
未经授权，请勿将此项目用于第三方基础设施。
wp2shell 是一个统一的 WordPress 核心安全研究工具，用于调查以下两个漏洞之间的相互作用：```text
CVE-2026-63030
|
v
REST API Batch Route Confusion
|
v
Validation / Dispatch Confusion
|
v
CVE-2026-60137
|
v
WP_Query SQL Injection
|
v
Blind SQL Access
|
v
Application / Object-State Manipulation
|
v
Privilege Escalation
|
v
Administrator Account Creation
|
v
Authenticated Code Execution
该 PoC 以 Python 研究工具的形式实现，并使用 Python 标准库，无需第三方 Python 包。
---
# 漏洞链
该项目组合了 WordPress Core 的两个漏洞。```text
Unauthenticated Request
|
v
+----------------------+
| CVE-2026-63030 |
| REST Batch Route |
| Confusion |
+----------+-----------+
|
v
Validation Confusion
|
v
+----------------------+
| CVE-2026-60137 |
| WP_Query SQLi |
+----------+-----------+
|
v
Blind SQLi
|
v
Application-State Abuse
|
v
Privilege Escalation
|
v
Administrator Access
|
v
Authenticated RCE
```
重要的安全属性在于这两个漏洞之间的交互，
而不是任何一个漏洞的孤立影响。
---
# CVE-2026-63030
## REST API 批处理路由混淆
第一个漏洞影响通过 WordPress REST API Batch 端点处理请求的过程。
批处理实现会在按请求位置索引的并行结构中维护请求匹配和验证信息。
格式错误的子请求可能导致这些结构失去同步。
这会产生一种 off-by-one 调度条件，使得后续请求可以使用与另一个请求关联的处理程序或验证上下文进行处理。
概念上：```text
Request A
|
+-- validation entry
+-- matching entry
|
v
Malformed request
|
+-- internal state becomes desynchronized
|
v
Request B
|
+-- unexpected handler / validation context
```
该 PoC 会执行行为检查，以确定路由
混淆是否确实可达。
---
# CVE-2026-60137
## WP_Query SQL 注入
第二个漏洞影响 `WP_Query` 的 SQL 处理路径。
一旦路由混淆原语建立，攻击者控制的
输入即可到达易受攻击的查询路径。
该 PoC 通过盲差分测试演示由此产生的 SQL 注入。
研究功能包括：
* 布尔盲确认
* 可选的基于时间的佐证
* 数据库指纹识别
* 支持的标量提取
* WordPress 用户数据研究
---
# 利用链的工作原理
## 1. REST Batch 路由混淆
一个未经认证的请求到达 WordPress REST Batch 端点。
一个畸形的批次子请求会导致内部请求匹配和
验证状态失同步。
随后，后续请求可能会在非预期
上下文中被处理。
---
## 2. SQL 注入
路由混淆原语为第二个漏洞提供了所需的路径。
攻击者控制的值可到达易受攻击的 `WP_Query`
处理路径。
这创建了一个盲 SQL 注入原语。
---
## 3. 盲 SQL 提取
该 SQL 注入可用作布尔盲提取通道。
该 PoC 包含用于研究数据库信息和
受支持的 WordPress 用户信息的功能。
---
## 4. 应用状态操纵
该利用链使用由数据库控制的结果来影响 WordPress
应用对象及后续处理。
这为权限提升阶段提供了所需的原语。
---
## 5. Changeset 权限提升
该利用链使用 WordPress changeset 处理来建立
管理员执行上下文。
一个伪造的 `customize_changeset` 对象可参与
权限提升序列。
---
## 6. 钩子重入
该利用链通过应用请求生命周期重新进入 WordPress
请求处理。
这使得后续 API 处理可以在提权后的
上下文中进行。
---
## 7. 管理员账户创建
该研究 PoC 实现了预认证管理员创建
阶段。
这是 Mode 3 对安全验证有用的关键原因：它
演示了权限提升的影响，而无需继续进入
webshell/RCE 阶段。
---
## 8. 认证后代码执行
Mode 4 将研究利用链延伸到管理员创建之外，进入
认证后代码执行阶段。
此阶段只能在隔离实验室或明确
授权的评估中使用。
---
# 受影响版本
## 完整预认证利用链
| WordPress 版本 | 状态 |
| -------------- | ------------ |
| 6.9.0 – 6.9.4 | **受影响** |
| 7.0.0 – 7.0.1 | **受影响** |
| 6.9.5 | **已修复** |
| 7.0.2+ | **已修复** |
该 PoC 将 `6.9.0–6.9.4` 和 `7.0.0–7.0.1` 标识为文档记载的
完整利用链受影响版本。
## SQL 注入
SQL 注入组件的修复版本界限与
完整利用链不同。
该研究实现将 `6.8.6` 标识为 SQL 注入修复版本。
完整的未认证利用链还依赖于
存在漏洞的 REST Batch 行为。
在生产环境做出决策之前，请务必对照相关的官方
安全公告核实受影响版本和修复版本。
---
# 前提条件
该 PoC 记录了完整利用链所需的以下条件：
* WordPress REST API 可访问
* 无 Redis/Memcached 对象缓存
* 至少有一篇已发布的文章
其他部署组件可能影响可复现性：
* 反向代理
* Web 应用防火墙
* REST API 限制
* 安全插件
* 对象缓存
* HTTP 过滤
* 主机配置
即使 WordPress 安装版本处于该范围，
也并不意味着完整利用链在每个环境中都能生效。
---
# 功能
`wp2shell` 提供一个交互式菜单，包含以下
研究功能：```text
[1] Fingerprint + confirm vulnerability (non-destructive)
[2] Blind SQL extraction (fingerprint / dump users)
[3] Pre-Auth Admin creation
[4] Full RCE chain → admin creation + webshell
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
[6] Threaded scan over URL list
[7] Transport settings (proxy, TLS, timeout, delay)
[8] Change target URL
[0] Quit
```
---
# 交互式菜单
主菜单设计用于支持以下两种场景：
* 测试单个已授权的 WordPress 安装
* 测试已授权的 WordPress URL 列表
因此，该工作流既可用于单个研究目标，
也可用于更大规模的已授权评估数据集。
---
# 推荐模式 — 模式 3
## 为什么选择模式 3？
对于漏洞研究，**模式 3 是推荐模式，当
目标是演示安全影响而无需部署
webshell 时**。
模式 3 是：```text
Pre-Auth Admin Creation
```
PoC 将此阶段描述为：```text
Unauthenticated UNION SQLi → new WordPress administrator
```
并明确将其与完整的 webshell/RCE 阶段区分开来：```text
No password cracking.
No webshell.
Non-destructive admin only.
```
这使得 Mode 3 在您想要证明漏洞链能够达到管理员级别的入侵，同时避免额外的代码执行阶段时特别有用。
---
# Mode 3 — 预认证管理员创建
选择 Mode 3 将打开：```text
────────────────────────────────────────────────────────────
CREATE ADMIN — Pre-Auth Admin RCE Chain
────────────────────────────────────────────────────────────
⚠ Unauthenticated UNION SQLi → new WordPress administrator.
⚠ No password cracking. No webshell. Non-destructive admin only.
```
随后，PoC 会要求提供若干环境和输出选项。
## SQLite```text
→ Target uses SQLite? (WP-SQLite plugin) (y/N) [n]:
```
当授权目标使用 PoC 支持的 WordPress SQLite 配置时，将其设置为 `y`。
对于常规的 MySQL/MariaDB WordPress 安装，默认值为：```text
n
```
---
## 凭据验证
PoC 可选地通过尝试认证登录来验证生成的凭据，```text
→ Verify the generated credentials by logging in? (Y/n) [y]:
```
默认值为：```text
y
```
当你希望结果中包含确认，即
生成的管理员凭据确实能够通过身份验证时，这很有用。
---
## 输出文件
Mode 3 可以将结果保存到本地文件：```text
→ Output file (blank = skip, e.g. result.txt):
```
例如：```text
logs.txt
```
将此字段留空将跳过文件输出。
在进行跨多个目标的授权研究并希望保留结果以供后续分析时，输出选项非常有用。
---
## 混淆载体
该 PoC 提供两种载体变体：```text
→ Confusion carrier variant (posts/categories) [posts]:
```
可用选项：```text
posts
categories
```
默认值是：```text
posts
```
`posts` 变体是主要的文档化路径。
---
# 模式 1 — 指纹识别与确认
模式 1 是：```text
[1] Fingerprint + confirm vulnerability (non-destructive)
```
这是漏洞验证最安全的起点。
它侧重于确定目标是否表现出与漏洞链相关的行为条件。
检查阶段可以包括：
* WordPress 指纹识别
* REST 批量端点检查
* 路由混淆确认
* SQL 注入确认
* 布尔盲差分测试
* 可选的基于时间的佐证
当目标主要是以下内容时，使用模式 1：```text
"Is this target potentially vulnerable?"
```
rather than demonstrating administrator impact.
---
# Mode 2 — Blind SQL Extraction
Mode 2 是：```text
[2] Blind SQL extraction (fingerprint / dump users)
```
此模式通过盲注演示 SQL 注入
原语。
研究功能包括：