企业官网建设流程全解析

最新内容请微.信搜索公.众.号阅读

针对 WordPress 核心 6.9.0-6.9.4 / 7.0.0-7.0.1 版本中存在的 CVE-2026-63030 REST /batch/v1 路由混淆和 CVE-2026-60137 author__not_in SQLi 漏洞的非破坏性检测器 + Docker 实验室

https://github.com/dinosn/wp2shell-lab

WordPress 核心中的预身份验证远程代码执行检测工具

https://wp2shell.com/

2026 年 7 月中旬，WordPress 领域遭遇了名为“wp2shell”的严重漏洞：这是 CMS 核心中的一个预身份验证远程代码执行(RCE) 漏洞，可能会影响超过 5 亿个网站。

该漏洞由两个不同的标识符（CVE-2026-60137和CVE-2026-63030）跟踪，它源于 /batch/v1 REST 端点管理中的一个缺陷，该缺陷允许未经身份验证的攻击者操纵子请求的验证，直至获得 SQL 注入，并由此在服务器上执行任意代码。

本文的目的纯粹是为了教育。我们的目标是逐步重现从发现漏洞到在实验室中完全攻陷 WordPress 实例的整个过程，以便了解攻击机制、其真正的危险性以及及时应用安全补丁的重要性。

所描述的所有活动均在一个隔离且受控的实验室中进行，该实验室使用专门的 WordPress 安装，没有实时数据，专门用于漏洞分析。

发现：社区怎么说，CVE怎么说

该文章重点介绍了这一发现：“WordPress 发出最高警报：核心代码存在严重的远程代码执行漏洞，5 亿个网站可能易受攻击。” 清晰地阐述了问题的严重性。

全球网络安全紧急警报：WordPress 核心代码曝出高危 RCE 漏洞，5亿个网站面临沦陷风险

文章提供了指导分析所需的关键信息：

• 漏洞名称：wp2shell（WordPress核心中的远程代码执行预认证漏洞）
• 标识符：CVE-2026-60137和CVE-2026-63030
• 紧急补丁版本：7.0.2、6.9.5 和 6.8.6
• 影响：未经身份验证的攻击者完全控制了网站

这些公开信息为验证我们的实验室安装是否属于易受攻击的版本提供了起点。

实验室版本验证

第一个操作步骤是通过管理面板（wp-admin → 更新）检查测试目标上实际安装的 WordPress 版本。

图 2 – 实验室目标报告版本为 6.9.1，被小组宣布为“最新版本”，但仍在易受攻击的范围内。

WordPress 控制面板显示“您拥有最新版本的 WordPress”，版本号为 6.9.1。需要注意的是，该实验室特意与互联网隔离，因此此消息仅仅反映出与 WordPress.org 服务器的连接中断，而不是自动更新机制的真正故障。

然而，出于另一个原因，这些数据仍然对教育目的有用：它表明，仅仅在仪表板上显示“已更新”字样，而不主动检查最新的安全公告，并不能保证不存在已知的漏洞，尤其是在版本发布之后才发现这些漏洞的情况下。

来自公开概念验证的反馈

为了确认 6.9.1 版本确实属于易受攻击的范围，我们查阅了 GitHub 上的公共Icex0/wp2shell-poc存储库，其中详细记录了完整的 RCE链。

图 3 – PoC 中公布的受影响版本表： 6.9.0–6.9.4 范围（包括实验室的 6.9.1）为“受影响”。

数据库中报告的表格证实了之前的假设：

• <= 6.8.5 → 不受影响
• 6.9.0 – 6.9.4 → 受影响（我们的版本 6.9.1 也属于此范围）
• 7.0.0 – 7.0.1 → 受影响

PoC 文档还解释了技术根本原因：/batch/v1 REST 端点未经身份验证，在一次调用中执行多个子请求，依赖于对每个子请求进行单独验证。

serve_batch_request_v1() 函数和验证逻辑构建了两个并行数组（请求匹配项和验证结果），然后在分发时使用相同的偏移量对它们进行索引。

当子请求的路径通过 wp_parse_url() 进行规范化失败时，它仍然会被添加到验证结果数组中，但不会添加到匹配数组中：这两个数组之间的这种错位是该漏洞的核心，它允许恶意请求“继承”先前合法请求的验证结果并执行它。

侦察

有了理论验证，我们便开始对实验室目标进行主动侦察阶段，使用 PoC 提供的 Python 脚本进行初步检查。

图 4 – wp2shell.py 脚本在侦察模式下的输出：通过 RSS 生成器识别版本，检测两个 CVE（通过 REST 路由混淆实现的简单 SQLi 和 RCE），枚举活动主题。

输出结果清晰地显示了指纹识别过程：通过 RSS 源（/?feed=rss2）中公开的生成器被动识别出版本 6.9.1，之后该工具报告存在两个关联的漏洞：

• WP < 7.0.2 – 易受攻击的 SQL 注入漏洞 (CVE-2026-60137)，已在 6.9.5 版本中修复。
• WordPress 7.0.2 之前的版本存在 REST API 批量路由混淆和 SQL 注入远程代码执行漏洞 (CVE-2026-63030)，已在 6.9.5 版本中修复。

当前活动主题（Twenty Twenty-Five）及其版本和已启用目录列表也已列出：这些背景信息对于更广泛的调查很有用，但对于使用 wp2shell 来说并非核心信息。

漏洞利用：从 SQL 注入到交互式 Shell

在展示漏洞利用之前，有必要进行方法论上的澄清：公开的 PoC 脚本在其原始版本中编写用于在 Linux 服务器上执行命令（如代码中的注释“for linux server (original)”所示，shell 使用 shlex.quote 和 printf 构建，以分隔输出）。

然而，实验室目标运行在 Windows 环境下的 XAMPP 堆栈上：因此，命令执行部分已相应地进行了调整（“适用于 Windows 服务器”），删除了与 cmd.exe 不兼容的典型 Linux shell 结构。

这是一个最小的修改，仅限于客户端命令执行包装器，不会以任何方式改变漏洞逻辑或 SQLi-to-RCE 链，但对于使 PoC 适应测试目标的操作系统是必要的。

图 5 – PoC 代码摘录：注释行“# for linux server (original)”和实际使用的“for windows server”分支，已针对实验室的 XAMPP/Windows 目标进行了调整。

此外，还进行了一项更改，即打印将要创建的用户的自动生成的密码。

在第一次运行时，使用 –confirm-sqli 选项，脚本实际上会通过在批处理路由上发送探测并检查 HTTP 响应和预期标记来确认漏洞，直到通过对伪读帖子执行 UNION 来确认 SQL 注入。

漏洞确认后，实际的攻击阶段随即开始，脚本以 shell 模式运行。值得注意的是，攻击无需凭据即可启动：从创建管理员用户到加载 webshell，整个过程仅使用预身份验证的 SQL 注入到远程代码执行 (RCE) 链。

图 6 – 利用顺序：通过 SQLi 自动创建管理员，进行身份验证，将 webshell 部署为插件，并在目标系统上打开交互式 shell。

终端观察到的序列如下：

• 未提供凭据：脚本尝试使用 SQLi 到自定义程序的“桥接”进行预授权创建管理员。
• 创建名为 wp2_1d2f1c9bc43a 的管理员用户，密码为随机生成。
• 使用新创建的凭据自动进行身份验证
• 将包含 webshell 的插件 (wp2shell_f4bd897b.php) 部署到 wp-content/plugins 目录
• 打开交互式 shell：whoami 和 dir 命令确认服务器上任意代码执行成功，系统用户为 desktop-787pguq\admin

这一步骤是演示的核心：通过未经身份验证的 HTTP 请求，您可以在几秒钟内无需任何手动交互，以 Web 进程的权限执行命令。

面板端验证：利用漏洞创建的用户和插件

为了更全面地了解情况，还可以从合法管理员的角度观察攻击的影响，方法是使用被盗用的用户名访问 wp-admin 面板。

图 7 – 用户部分显示了新的管理员帐户 wp2_1d2f1c9bc43a，该帐户完全由漏洞利用脚本创建，没有任何手动操作。

新的管理员帐户出现在“用户”部分，其电子邮件地址为伪造的 (@wp2shell.invalid)，由漏洞利用过程自动生成。第二个帐户 (wp2shell) 是测试安装的合法管理员。

图 8 – 插件部分证实了“wp2shell”插件的存在，该插件被描述为“临时命令运行器”：伪装成合法插件的 webshell。

在插件部分，有一个名为 wp2shell 的插件，其简洁的描述是“临时命令运行器”：这是漏洞利用程序加载的 webshell，伪装成普通插件，并像其他扩展程序一样激活/停用。

对于事件响应专业人员来说，这个细节尤其具有指导意义：名称不寻常、描述通用的未知插件通常是 WordPress 网站取证分析期间需要查找的第一个入侵指标。

重构的路径清晰地展示了一个看似仅限于鲜为人知的 REST 端点 (/batch/v1) 的漏洞，如何通过一系列验证错误演变为完整的系统入侵：从 SQL 注入到创建管理员账户，再到通过 webshell 执行任意命令。整个过程无需受害者提供任何凭据或进行任何交互，这也解释了安全社区为何对 wp2shell 漏洞的发现如此重视。

从防御角度来看，有三点需要注意。首先，WordPress 控制面板显示的“已更新”状态并不能绝对保证软件没有漏洞。即使系统显示版本已是最新版本，也务必积极关注安全公告（例如 Red Hot Cyber 发布的公告），并验证软件版本，尤其是在发布后发现严重 CVE 漏洞的情况下。

其次，将多个操作聚合到单个调用中的 REST 端点（批量端点）在验证期间需要特别注意，因为即使并行数据结构之间存在最小的错位，也可能造成灾难性的后果。

第三，即使名称和描述看似无害，出现未识别的插件也应引起怀疑，并触发网站完整性检查。