这究竟是如何工作的

本 PoC 与公开的 wp2shell 漏洞利用有何不同

所有 PoC 都利用了相同的两个缺陷 - REST 批量路由混淆（CVE-2026-63030）和 author__not_in SQL 注入（CVE-2026-60137）- 并采用相同的双重嵌套批次结构。 它们之间的区别在于所选择的远程代码执行（RCE）路径、环境前置条件， 以及安全默认设置。本文档具体说明了本仓库中的实现在这一格局中所处的位置。

简要概述

1. 在存在持久化对象缓存时依然有效。 公开的基于 UNION 的 PoC 使用 已填充基集的注入形式：这一系列所共享的全链实现在那里会出现假阴性， 而单文件统一工具将“无持久化对象缓存”列为明确的前置条件。本仓库的清空基集形式 恰恰能在这些主机（常见的托管 WordPress 环境）上保持 UNION 通道 - 以及整个预认证 RCE 桥接 - 的存活。参见 §1。
2. 默认可安全地对生产环境运行。 除非明确要求，check 不发送任何 SQL 载荷； 所有流量都可以携带归因标记；shell 命令写入目标的一切内容事后都会自动移除。 参见 §3。

对比表

[1] 仅将时间盲注/盲注作为读取通道；UNION 伪造文章原语存在于桥接内部，但未作为提取预言机（extraction oracle）暴露。 [2] 朴素的可用性探测（0) UNION SELECT …）在对象缓存的水合过程中被静默丢弃，available() 返回 false，整个预认证桥接中止 - 见 §1。 [3] 该项目自己的 README 在前置条件中列出了“无持久化对象缓存（Redis/Memcached）”。 [4] 在 Sploitus 上镜像的公开变体（链接见下文）：盲读加上 INTO OUTFILE 投放器作为 RCE 步骤，使用 per_page=-1 分类载体。 [5] OUTFILE RCE 路径不依赖伪造文章渲染，因此对象缓存无法阻止它 - 真正构成阻碍的是 MySQL FILE 权限和共享的可写目录。托管主机几乎从不向 WordPress 数据库用户授予 FILE 权限，而且通常会设置 secure_file_priv。

1. 对象缓存问题（真正的差异点）

UNION 伪造文章原语取决于 WP_Query 返回行的方式：

• 整行模式 - SQL 返回完整的 wp_posts 行；通过 UNION 注入的行直接成为 WP_Post。伪造的文章得以渲染。
• 拆分（仅 ID）模式 - SQL 仅返回 ID，随后每个 ID 通过（持久化）对象缓存/数据库 进行水合。伪造行的 ID 不存在，因此水合过程会静默丢弃它。没有报错，也没有伪造文章。

在具有持久化对象缓存的主机上，已填充的基结果集会迫使 WP_Query 进入拆分模式。公开 PoC 使用的标准探测 -

0) UNION SELECT <forged row> -- -

• 使基集保持已填充状态（post_author NOT IN (0) 匹配每一行），因此在对象缓存之后，伪造行会蒸发消失：可用性探测出现假阴性，available() 返回 false，整个预认证桥接在一个实际上完全可利用的主机上被报告为“已失效”。公开的统一工具通过将*“无持久化对象缓存”*列为硬性前置条件来记录相同的边界。

本仓库则改为清空基集：

1) AND 1=0 UNION ALL SELECT <forged row> -- -

基集为零行时，伪造行是唯一的行；查询保持整行模式；永远不会执行水合查找。在对象缓存主机上 - 这是大多数托管 WordPress 生产环境 - 一个注入的关键字（AND 1=0）就是“UNION 通道失效”与“完整预认证 RCE”之间的全部差别。诊断、探测矩阵（per_page × 注入形式）。

范围说明：盲注/时间盲注读取通道不受对象缓存影响（在 SQL 中计数行不涉及伪造文章的水合），因此每个 PoC 的盲注读取在任何地方都有效。对象缓存对其他 PoC 造成的破坏仅限于依赖 UNION 的部分：带内提取和 SQLi 到管理员桥接。

案例研究中记录的第二条相关经验：当两个通道都可用时，以带内 UNION 读取为准 - 生产环境中的时间盲注预言机在抖动下对一个值产生了位翻转，而带内读取则明确无误地确定了该值。

2. RCE 路径的选择

公开 PoC 中存在三条预认证 RCE 路径：

本仓库实现了该桥接：它不需要 WordPress 已拥有之外的任何数据库权限，在数据库层和 Web 层之间无任何共享时也能正常工作，并且不会留下任何可供 FILE 权限路径依赖的文件。代价是复杂性 - 该桥接是一个七行的投毒文章图（poisoned post graph）- 而这正是 §1 中对象缓存假阴性曾经隐藏该路径的地方。

3. 面向授权使用的安全默认设置

专为在授权下对生产系统运行而构建，而不仅仅是实验室：

• check 默认非破坏性 - 被动指纹探测加上良性的标记批次；除非给出 --confirm-sqli，否则不发送任何 SQL 载荷。修补之后，消失的标记三元组兼作修复验证。
• 归因标记 - 每条命令都带 --user-agent，使所有漏洞利用流量在日志中可识别（公开工具默认不具备这一经验法则）。
• 自动清理 - Webshell 在随机路径下进行令牌锁定，并能自我移除；桥接创建的管理员随后被删除，其内容重新分配给借用的管理员账户。清理失败会显著报告，而不会被静默吞没。
• 请求计数 - 每条命令都会打印它发送的请求数量。

4. 本仓库不声称的内容

• 没有新漏洞。这两个缺陷都是公开披露的 CVE；双重嵌套批次结构、author_exclude → author__not_in 汇聚点、伪造 WP_Post 的 UNION 原语以及自定义器桥接（customizer-bridge）概念都是公开的技术（来源已在下方注明）。
• 没有新的利用原语。与公开领域相比的增量是：带有生产环境证据的清空基集对象缓存修复、面向生产环境安全的默认设置，以及检测文档 - 追求的是健壮性和操作安全性，而非技术的新颖性。
• IoC 字符串是随意选取的。登录前缀、插件别名、Shell 标记和 User-Agent 值在每个变体以及每次运行中都各不相同；

参考

• Icex0/wp2shell-poc - 本仓库同源系列所共享的全链实现 - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - 首个公开 PoC；免破解管理员创建技术的起源 - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - 六个公开 PoC 的单文件统一工具，附带 Docker 实验室和 版本×数据库矩阵（记录了对象缓存前置条件） - https://github.com/0xsha/wp2shell
• OUTFILE 变体（盲读 + INTO OUTFILE 投放器），镜像于 Sploitus - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• 公开 PoC 和检测工具的精选列表（供防御者参考） - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf；WordPress 7.0.2 发布公告 - 参见 README.md 中的参考。