wp2shell 漏洞利用调查研究分析

最新内容请微.信搜索公.众.号阅读针对 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-labWordPress 核心中的预身份验证远程代码执行检测工具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亿个网站面临沦陷风险文章提供了指导分析所需的关键信息漏洞名称wp2shellWordPress核心中的远程代码执行预认证漏洞标识符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 源/?feedrss2中公开的生成器被动识别出版本 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 目录打开交互式 shellwhoami 和 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 端点批量端点在验证期间需要特别注意因为即使并行数据结构之间存在最小的错位也可能造成灾难性的后果。第三即使名称和描述看似无害出现未识别的插件也应引起怀疑并触发网站完整性检查。