该 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 注入
原语。

研究功能包括：

* 数据库指纹识别
* 数据库版本
* 数据库用户
* 数据库名称
* 支持的标量 SQL 表达式
* WordPress 用户信息

请仅在授权环境中使用此模式，因为它演示的是
数据访问影响，而不仅仅是检测漏洞。

---

# 模式 3 — 预认证管理员创建

模式 3 是：```text
[3] Pre-Auth Admin creation
```
该模式展示了该链的权限提升影响。

重要区别在于：```text
Mode 3
    |
    +-- Pre-authentication chain
    +-- Administrator creation
    +-- Optional login verification
    +-- No password cracking
    +-- No webshell
```
对于需要在不部署 webshell 的情况下证明该漏洞具有管理员级影响的安全研究人员来说，这是首选模式。

---

# 模式 4 — 完整 RCE 利用链

模式 4 是：```text
[4] Full RCE chain → admin creation + webshell
```
这会将攻击链从管理员创建扩展到经过身份验证的代码执行。从概念上讲：```text
Unauthenticated
      ↓
Route Confusion
      ↓
SQL Injection
      ↓
Privilege Escalation
      ↓
Administrator Creation
      ↓
Administrator Authentication
      ↓
Webshell
      ↓
Code Execution
```
此模式应仅限于隔离实验室和明确授权的渗透测试。

对于常规漏洞验证，模式 3 更可取，因为它无需部署 webshell 即可展示管理员影响边界。

---

# 模式 5 — 辅助汇点 SQL 注入

模式 5 为：```text
[5] Facilitated sink SQLi (WordPress 6.8.x / custom)
```
这种模式旨在用于研究涉及 SQL 注入汇点的场景，该场景位于完整的预认证链之外。

它对以下研究人员非常有用：

* WordPress 6.8.x 环境
* 自定义配置
* 独立研究 SQL 注入原语
* 漏洞复现
* 防御性验证

---

# 模式 6 — 线程化 URL 扫描

模式 6 是：```text
[6] Threaded scan over URL list
```
此模式适用于涉及多个 WordPress 目标的授权评估。

该工具无需手动逐个测试 URL，而是可以使用工作线程处理 URL 列表。

从概念上讲：```text
urls.txt
   |
   +-- URL 1
   +-- URL 2
   +-- URL 3
   +-- URL 4
   +-- ...
   |
   v
Threaded vulnerability checks
   |
   v
Results
```
扫描功能可以使用以下选项：

* 工作线程数
* 确认延迟
* 可选版本证明
* JSON 报告输出
* 混淆载体变体

仅对您拥有明确授权的 URL 列表使用此功能。

---

# 单目标与 URL 列表

`wp2shell` 可以通过两种通用方式使用。

## 单个 WordPress 目标

在研究单个安装时使用单个目标。

典型使用场景：

* 本地实验室
* 预发布环境
* 客户批准的渗透测试
* 漏洞复现
* CVE 验证

目标应为 WordPress 基础 URL。

---

## URL 列表

对于多个已授权目标，模式 6 可以处理 URL 列表。

示例概念文件：```text
https://wordpress-lab-01.example
https://wordpress-lab-02.example
https://wordpress-lab-03.example
https://wordpress-lab-04.example
```
线程化扫描器随后可以处理该列表并记录结果。

扫描实现还支持用于保留发现的输出/报告选项。

---

# 模式选择指南

| 目标                                   | 推荐模式       |
| -------------------------------------- | -------------- |
| 检查目标是否存在漏洞                   | **模式 1**     |
| 演示 SQL 注入                          | **模式 2**     |
| 演示管理员级别的攻击影响               | **模式 3**     |
| 演示完整的 RCE 攻击链                 | **模式 4**     |
| 独立研究 SQLi 汇点                     | **模式 5**     |
| 测试经过授权的 URL 列表                | **模式 6**     |
| 配置代理/TLS/超时/延迟                 | **模式 7**     |
| 更改当前目标                           | **模式 8**     |

### 推荐的研究工作流程

对于大多数安全评估而言：```text
Mode 1
  ↓
Confirm vulnerability
  ↓
Mode 3
  ↓
Demonstrate administrator impact
```
只有在明确要求并授权完全代码执行验证时，
才继续进入 Mode 4。

---

# Mode 7 — 传输设置

Mode 7 是：```text
[7] Transport settings (proxy, TLS, timeout, delay)
```
此部分控制工具使用的 HTTP 传输行为。

支持的研究设置包括：

* 代理配置
* TLS 行为
* 请求超时
* 请求延迟
* 连接/重试行为

在测试位于以下环境后方的 WordPress 安装时，这些选项非常有用：

* 代理
* TLS 配置
* 慢速连接
* 限流基础设施
* 受控实验室环境

---

# 模式 8 — 更改目标 URL

模式 8 是：```text
[8] Change target URL
```
这允许更改当前选定的目标，而无需
重新启动整个交互式工作流。

在授权的实验室安装之间切换时，这很有用。

---

# 检测逻辑

该 PoC 使用行为检查，而不是仅仅依赖
WordPress 版本字符串。

## REST 批量检测

该工具验证 REST Batch 端点是否可达。

## 路由混淆检测

该工具可以使用：

* 响应标记
* 结构化响应行为

结构化方法检查某个针对一个 REST 集合的请求是否
被当作另一个集合来处理。

## SQL 注入检测

该工具可以执行布尔型盲差分检测。

基于时间的信道还可以用作佐证。

---

# 技术链条

完整的研究链条可总结如下：```text
1. REST API reachable
          |
          v
2. Batch route confusion
          |
          v
3. Validation / dispatch confusion
          |
          v
4. SQL injection reaches WP_Query
          |
          v
5. Blind SQL channel
          |
          v
6. Application-state manipulation
          |
          v
7. Changeset privilege escalation
          |
          v
8. Administrator context
          |
          v
9. Administrator account creation
          |
          v
10. Authenticated code execution
```
---

# 路由变体

该 PoC 支持两种混淆载体变体：```text
posts
categories
```
默认是：```text
posts
```
The `posts` variant is the primary documented end-to-end carrier.

The `categories` variant provides an alternative route-confusion path
for research.

---

# SQLite 支持

PoC 包含对使用 WordPress SQLite 配置的环境的 SQLite 兼容性支持。

模式 3 将该选项暴露为：```text
Target uses SQLite? (WP-SQLite plugin)
```
默认：```text
n
```
使用:```text
y
```
当授权目标使用支持的 SQLite 配置时。

---

# 安装

该 PoC 使用 Python 的标准库。

无需第三方 Python 包。

所需环境：```text
Python 3.x
```
克隆仓库并在隔离或明确授权的环境中
运行研究工具。

---

# 项目结构

推荐的仓库结构如下：```text
wp2shell/
│
├── wp2shell.py
├── README.md
├── LICENSE
└── screenshots/
```
主要研究实现是：```text
wp2shell.py
```
---

# 安全影响

成功的漏洞利用链可能导致：

* 未认证的 SQL 注入
* 数据库信息泄露
* WordPress 用户信息暴露
* 权限提升
* 管理员账户创建
* WordPress 完全管理访问权限
* 已认证的任意代码执行
* 可能导致操作系统级失陷，具体取决于托管
  环境

因此，完整攻击链的影响远大于
单个漏洞独立考虑时的影响。

---

# 防御检测

管理员应调查涉及以下内容的可疑活动：

* WordPress REST Batch 端点
* 异常的嵌套批量请求
* 格式错误的批量请求路径
* 可疑的查询参数
* 意外的管理员账户创建
* 意外的 `customize_changeset` 活动
* 意外的插件安装
* 意外的 PHP 文件
* 可疑的插件修改
* 类似 WebShell 的行为

审查：```text
Web server logs
        +
WordPress logs
        +
Database audit logs
        +
File integrity monitoring
```
especially around the time of suspected exploitation.

---

# 缓解措施

主要缓解措施是将 WordPress 升级到已修复版本。

受影响的安装还应：

1. 审查所有管理员账户。
2. 移除未授权的管理员账户。
3. 审查最近安装或修改的插件。
4. 审查 WordPress REST API 日志。
5. 审查 Web 服务器访问日志。
6. 搜索意外的 PHP 文件。
7. 检查插件目录是否有未授权的修改。
8. 若怀疑遭到入侵，轮换凭据。
9. 审查数据库完整性。
10. 移除持久化机制。
11. 在适当时，从可信来源重新安装受感染的 WordPress 组件。

---

# 负责任的研究工作流程

对于正常的授权评估，建议的流程如下：```text
                 START
                   |
                   v
          ┌─────────────────┐
          │     MODE 1      │
          │ Detect / Confirm│
          └────────┬────────┘
                   |
             Vulnerable?
              /          \
            No            Yes
            |              |
           STOP            v
                    ┌───────────────┐
                    │    MODE 3     │
                    │ Admin Impact  │
                    └───────┬───────┘
                            |
                     Need full RCE?
                       /          \
                     No            Yes
                     |              |
                    STOP            v
                             ┌───────────────┐
                             │    MODE 4     │
                             │ Full RCE Lab  │
                             └───────────────┘
```
模式 3 通常是首选的影響演示点，因为它
无需部署 WebShell 阶段即可建立管理员级别的入侵证明。

---

# 研究 vs 生产环境

该项目仅用于受控的安全研究。

请勿将该工具视为通用互联网扫描器。

对于生产环境：

* 取得书面授权。
* 定义目标范围。
* 定义允许的操作。
* 优先采用非破坏性验证。
* 在收集到足够证据后停止。
* 保留日志和证据。
* 遵循适用的漏洞披露流程。

---

# 致谢

漏洞研究 / 发现：

**Adam Kues**
Assetnote / Searchlight Cyber

项目：

**wp2shell**

研究实现将漏洞链识别为：```text
CVE-2026-63030
+
CVE-2026-60137
```
---

# 参考资料

* CVE-2026-63030
* CVE-2026-60137
* GHSA-ff9f-jf42-662q
* GHSA-fpp7-x2x2-2mjf
* WordPress Core
* WordPress REST API
* WordPress `WP_Query`

---

# 免责声明

本仓库包含演示影响 WordPress Core 的漏洞链的安全研究。

本软件及文档仅供以下用途使用：

* 教育目的
* 安全研究
* 漏洞验证
* 防御性测试
* 授权渗透测试

作者不对未经授权或恶意使用本材料的行为承担任何责任。

**仅可测试您拥有所有权的系统，或已获得明确授权的系统。**

---

# 关键词```text
wp2shell
WordPress
WordPress Core
WordPress Security
WordPress Vulnerability
WordPress RCE
Pre-Auth RCE
Pre-Authentication RCE
CVE-2026-63030
CVE-2026-60137
REST API
REST Batch
REST API Batch
Route Confusion
WP_Query
SQL Injection
SQLi
Blind SQL Injection
Privilege Escalation
Administrator Creation
Remote Code Execution
RCE
Proof of Concept
PoC
Security Research
Penetration Testing
```
---

## 仓库主题

推荐的 GitHub 仓库主题：```text
wp2shell
wordpress
wordpress-core
wordpress-security
wordpress-vulnerability
wordpress-rce
cve
cve-2026-63030
cve-2026-60137
poc
proof-of-concept
rce
sql-injection
sqli
blind-sqli
rest-api
security-research
penetration-testing
privilege-escalation
```
---

## 项目摘要```text
wp2shell is a WordPress Core pre-authentication vulnerability-chain PoC
combining CVE-2026-63030 (REST API Batch route confusion) and
CVE-2026-60137 (WP_Query SQL injection), demonstrating the progression
from unauthenticated access to SQL injection, privilege escalation,
administrator creation, and authenticated code execution.
```
I'm ready to translate the provided content, but the input section for chunk 93 of 94 appears to be empty. No text was supplied after "INPUT:". Please provide the actual Markdown content for this chunk, and I'll translate it according to your rules.```
disclaimer: this project is for educational purposes only
```