gichirimaku/wp2shell-PoC · 上手攻略
- 仓库：gichirimaku/wp2shell-PoC
- 链接：https://github.com/gichirimaku/wp2shell-PoC
- 分类：engineering（安全研究 / WordPress 漏洞 PoC）
- 作者：spark
- 更新：2026-10-21
⚠️ 合法性前置声明：本篇只做防御侧的技术分析与安全加固指南。README 原文亦声明该工具"仅供教育或漏洞赏金目的，在受控环境之外的未授权使用被严格禁止"。本文不提供针对真实目标的攻击步骤、载荷构造或绕过方法；所有命令示例仅用于你自己拥有或已获得书面授权的目标的检测与验证。请先确认你的授权范围。
一、它是什么
wp2shell-PoC 是针对 WordPress 核心的一个 pre-auth RCE（远程代码执行）漏洞链的公开 PoC，562 star，Python 编写，最近提交 2026-10-20。它组合了两个 CVE：
- CVE-2026-63030 — REST API Batch 端点的路由混淆（route confusion）
- CVE-2026-60137 — WP_Query 的 SQL 注入
两者组合起来构成一条无需认证即可攻陷 WordPress 并远程执行代码的完整链条。作者声明完整分析见 https://wp2shell.com/。
二、它解决什么问题（漏洞机制拆解）
这条链的设计相当精巧，值得从防御角度完整理解。它分五步：
第 1 步：Batch 路由混淆（CVE-2026-63030）
/wp-json/batch/v1 会并行处理多个子请求。内部用按位置索引的 $matches 和 $validation 两个平行数组。当一个子请求的路径格式错误（比如 http://）时，它被 append 到 $validation 但因为 continue 语句没有被 append 到 $matches——两个数组就此错位。
结果是：后续的请求会被派发给"下一个请求"本该走的 handler，从而绕过 schema 校验和权限检查。
第 2 步：嵌套 Batch 打通 SQLi（CVE-2026-60137）
两次嵌套 batch 调用：
- 外层 batch 绕过 method allow-list（正常情况下 GET 是被挡的）
- 内层 batch 把一个标量 author_exclude 字符串送到 GET /wp/v2/posts——因为错位，它被路由到了校验之外，WP_Query 把这个未净化的字符串直接插值进 SQL
结果是一个 UNION 基础的盲注。
第 3 步：缓存投毒
SQLi 返回伪造的 WP_Post 对象，WordPress 会把它们缓存在内存里。这些假文章内含 [embed] 短代码，触发 WordPress 从伪造引用中创建真实的 oembed_cache 数据库行。
第 4 步：Changeset 提权
攻击者用 SQLi 在内存中伪造一个 customize_changeset 文章，其 JSON 里带 "user_id": 1。一个环检测 gadget 触发 wp_update_post() 而不覆盖 post_content，从而保留攻击者载荷。应用该 changeset 会临时以管理员身份运行。
第 5 步：Hook 重入 → 造管理员账号
一个伪造的文章触发 parse_request hook（status=parse、type=request），用管理员角色重放整个 batch 请求。这次 POST /wp/v2/users 子请求成功，创建一个新的管理员账号。最后登录该账号上传恶意插件，获得命令执行。
三、受影响版本与修复
README 给的版本表（⚠️ 以下为仓库自述，正式处置请以 WordPress 官方安全公告为准）：
| 版本 | 状态 |
|---|---|
| WordPress 6.9.0 – 6.9.4 | Vulnerable |
| WordPress 7.0.0 – 7.0.1 | Vulnerable |
| WordPress 6.9.5 | Fixed |
| WordPress 7.0.2+ | Fixed |
四、核心用法（防御侧：检测与验证）
工具只要求 Python 3.8+，从仓库目录运行。
4.1 漏洞检测（只发良性探测）
# 单目标检测（无其他模式时的默认模式）
python3 wp2shell.py http://你的授权目标
# 显式指定检测模式
python3 wp2shell.py http://你的授权目标 --check
这一模式发送一个良性的 batch 标记探测，只检测路由混淆 bug，不执行 SQLi 载荷。判定信号是：易受攻击的目标返回 HTTP 207，并带有 parse_path_failed、block_cannot_read、rest_batch_not_allowed 这一组错误特征。
4.2 SQLi 确认（仅在确认目标已授权后）
python3 wp2shell.py http://你的授权目标 --check --confirm-sqli
会先尝试 UNION 反射，失败则回退到基于时间的探测。
4.3 提取技术（工具支持三种）
工具默认 --technique auto，按此顺序尝试：
| 技术 | 原理 | 适用条件 | 代价 |
|---|---|---|---|
union |
UNION 伪造 WP_Post 行，从 REST 响应读回 title（\|\|HEX(value)\|\|） |
目标反射数据 | 每个值 1 次请求，最快 |
error |
EXTRACTVALUE/UPDATEXML 报错泄漏 | 目标开启 WP_DEBUG_DISPLAY 并反射 MySQL 错误 |
约 15 字节/请求 |
blind |
布尔二分搜索，读 X-WP-Total 头作真假信号 |
无任何数据反射时 | 每字符约 8 次请求 |
也可用 --technique union|error|blind 强制指定。
4.4 完整 flags 表
| Flag | 说明 |
|---|---|
--check |
运行漏洞检测（无其他模式时的默认） |
--read |
通过 SQLi 提取数据 |
--shell |
在服务器上执行命令 |
--query |
read 模式下的自定义 SQL |
--preset |
预定义查询预设（users / config / versions） |
--technique |
提取技术：union / error / blind / auto |
--confirm-sqli |
检测后发送 SQLi 确认载荷 |
--cmd |
shell 模式执行的命令（默认 id） |
--interactive, -i |
交互式 shell |
--user / --password |
带凭证的 shell 模式所用的管理员账号 |
--proxy |
HTTP/HTTPS 代理 |
--timeout |
请求超时秒数（默认 30） |
--verbose, -v |
详细输出 |
4.5 工具的"负责任"设计
有两点值得肯定，值得抄进团队规范：
- webshell 自动清理。上传的 webshell 用随机路径 + 每次运行的 token，shell 会话结束后自动删除。
- 临时管理员自动清理。pre-auth 桥接创建的管理员账号，在 shell 会话结束后自动删除。
- read 路径只读。
--read系列的提取路径明确声明"read-only and do not write to the database"。
另外注意 --check（默认模式）是完全良性的——这是它可以安全用于资产自查的原因，也是本篇推荐你在自有资产上唯一应该使用的模式。
五、典型适用场景
- WordPress 站点管理员自查。升级到 6.9.5 / 7.0.2+ 之前，先跑一遍
--check确认自己的站点不在受影响范围。 - 漏洞赏金计划中的授权测试。这是作者声明的用途，也是这类 PoC 最正当的用法。
- 蓝队检测规则建设。第 4 步里那组错误特征串（
parse_path_failed+block_cannot_read+rest_batch_not_allowed+ HTTP 207）本身就是很好的检测特征，可以直接写进 WAF 规则或 SIEM 告警。 - 安全研究者理解批量端点这类设计缺陷。这个"平行数组按位置索引 + continue 导致错位"的模式是 Web 框架里反复出现的经典 bug 类型。
六、坑与注意
- ⚠️ 伦理与法律风险是首要问题。这是 pre-auth RCE，任何未经授权的使用都可能构成未授权访问计算机系统的犯罪行为。作者自己的声明也明确了"受控环境之外严格禁止"。请务必先取得书面授权。
- 漏洞编号可能变化。CVE-2026-63030 / CVE-2026-60137 与本文抓取自 2026-10-20 的仓库自述。正式处置必须以 WordPress 官方安全公告（wordpress.org/news）为准，不要只看第三方 PoC 仓库。
- 检测特征可能被补丁改变。一旦修复，
--check的错误特征串就不再出现。这既是好消息（说明修好了）也意味着不能靠"没检出"就完全放心——仍需确认版本号。 --read/--shell的伤害是不可逆的。虽然工具做了自动清理，但--read --preset users会读取密码哈希，--shell会在真实服务器上执行任意命令。审计日志里会留下痕迹，也可能触发主机侧的 WAF/IDS 告警。- 探测本身也可能被计入风控。即便是良性
--check，批量请求/wp-json/batch/v1也会被目标站点记录。如果目标不是你的，很可能直接进黑名单。 - 自清理 ≠ 无痕迹。webshell 文件被删了，但
wp_users里的管理员记录、oembed_cache 里的垃圾行、变更日志、文件修改时间都可能留下痕迹。PoC 跑过的机器不能再信任。 - 这个链条设计得很深。从路由混淆到 changeset 提权再到 hook 重入，中间任何一环被单独修复都可能断链——但也可能只断一环而留下残余风险。因此"升级到 Fixed 版本"是唯一可靠的对策，不要试图靠 WAF 规则单独防。
八、与同类对比
| 维度 | wp2shell-PoC | 通用扫描器（ nuclei 等） | 商业漏洞扫描 SaaS |
|---|---|---|---|
| 覆盖范围 | 单条特定链路的深度利用 | 大量模板的广度覆盖 | 依赖厂商规则库更新 |
| 技术深度 | 完整五步链：混淆→SQLi→缓存投毒→提权→hook 重入 | 通常只做检测不利用 | 检测为主 |
| 使用门槛 | 低（单脚本、Python 3.8+） | 低 | 无（托管服务） |
| 风险 | 极高（真实 RCE 能力） | 中（多数模板只探测） | 低 |
| 合法用途 | 授权测试 / 赏金 / 自有资产自查 | 自有资产巡检 | 自有资产巡检 |
| 社区参考 | slcyber.io、Picus Security 均有技术分析 | 大 | 闭源 |
九、防御方应该做什么（本篇真正的重点）
- 立即确认版本。6.9.5 和 7.0.2+ 之前的所有版本都受影响。跑
wp core version检查。 - 在 WAF/日志里加检测规则：对返回 HTTP 207 且 body 含
parse_path_failed且含block_cannot_read的/wp-json/batch/v1请求告警——这是本条链最早期、最容易被抓到的信号。 - 审计
wp_users表：查找来源不明的管理员账号，特别是user_registered异常、user_url为空、从未发过内容的账号。 - 审计 oembed_cache 表：这个漏洞链会往里塞伪造的行，异常条目是入侵痕迹。
- 检查
wp-content/plugins/目录：查找来源不明、无对应插件设置记录的 PHP 文件。 - 不要试图靠禁用 batch 端点当长期方案——它会被绕过，也可能破坏正常功能。升级才是正解。
十、一句话推荐结论
如果你运营 WordPress 站点——立刻核对版本，6.9.5 / 7.0.2 是安全线；如果你做安全研究——这是一条设计相当漂亮的漏洞链，平行数组错位这个模式值得反复咀嚼；如果你只是想"试试看"——请不要，pre-auth RCE 的法律风险不是"我只是想学"能覆盖的。
本文信息源：GitHub README（2026-10-20 main 分支）、https://wp2shell.com/（README 指向的完整 advisory，未抓取）、organized/repo_cards/4512-gichirimaku-wp2shell-poc.md。第三方分析参考：slcyber.io、Picus Security。未运行任何 PoC 代码。CVE 编号与版本表均为仓库自述，须以 WordPress 官方公告复核。