2023 年 10 月。网络安全研究机构 Searchlight Cyber 的安全研究员 Adam Kues 公开了一个 WordPress 主要级漏洞，编号为 wp2shell。说起来，这是一个预身份验证远程代码执行漏洞，攻击者无需登录、无需安装任何插件。直接在原生安装的 WordPress 实例上就可以远程攻击。

全球有超过 5 亿 个活跃网站运行在 WordPress 上。这一漏洞的影响范围之大足以让每一位站长感到“如果我的站点被攻击，我该怎么办？”的焦虑，

漏洞概况

wp2shell 为什么危险程度高？ 因为它的攻击门槛极低。与绝大多数 WordPress 安全事件不同。这次的问题出在 WordPress Core 本身，而非第三方插件或主题。匿名使用者即可在默认安装的 WordPress 上完成远程代码执行。

为了给全球站点管理员留出足够的修补窗口。Searchlight Cyber 目前没有公开技术细节，但已提供了在线检测工具，供管理员自查站点是否受影响。

受影响版本一览

WordPress 版本范围	是否受影响	修复版本
5.0.0 – 5.8.0	受影响	5.8.1
5.9.0 – 6.1.0	受影响	6.1.1
< 5.0.0 或 ≥ 6.2.0	不受影响	-

如果站点运行在 5.x 系列或 6.x 系列之间的受影响版本，需要升级到对应的修复版。以下版本已不受此漏洞影响。

为什么 wp2shell 值得主要关注

过去几年，WordPress 的安全问题大多集中在插件环境上。 比如某个下载量百万级的插件出现 SQL 注入或 XSS 漏洞，管理员只需要卸载或更新插件即可解决。但 wp2shell 完全不同，它直接作用于主要代码。

• 漏洞位于 WordPress Core。 无论你使用什么主题、装了多少插件。只要 WordPress 本身处于受影响范围，就可能被利用。
• 预认证漏洞。其实， 攻击者不需要任何账号密码。也不需要社会工程学手段，直接对目标站点发起攻击。零交互、零凭证，让自动化扫描工具能够快速批量入侵。
• 基数庞大。 WordPress 在全球 CMS 行业市场中约占 43% 的份额，活跃站点数以亿计。 按理说，即使只有 10% 的站点处于受影响版本。也代表着上千万网站面临风险。

完整修复与缓解方案

方案一的观点是，直接升级 WordPress

是根本解决办法。WordPress 5.8.1 与 6.1.1 已经包含了针对 wp2shell 的修复补丁。

1. 登录后台 → 仪表盘 → 更新；确认当前版本号并执行更新。
2. If you have automatic updates enabled,log in to verify that patch has been applied.

至于方案二。安装 “Disable WP REST API” 插件

当兼容性测试或业务需求暂时阻止升级时可先通过插件禁用未认证使用者对 REST API 的访问，从而切断 wp2shell 的攻击方法。说到但请注意，

• This may affect features that rely on REST API .
• A thorough functional regression test is required after activation.

说到方案三，通过 WAF 拦截特定方法

If a Web Application Firewall is deployed in front of site。add rules to block both URL‑based and query‑parameter based calls to vulnerable batch endpoint.

拦截 URL 方法：

/wp-json/batch/v1

拦截查询参数：

rest_route=/batch/v1

The two rules must be applied toger;blocking only one does not provide full protection.

Nginx 示例：

# 拦截 batch API 方法
location ~* ^/wp-json/batch/v1 {
deny all;话说回来，return 403;}
# 拦截通过查询参数访问 batch API 的请求
if {
return 403;}

Apache 示例：

RewriteEngine On
# 拦截 batch API 方法请求
RewriteRule ^wp-json/batch/v1 -
# 拦截通过查询参数访问 batch API 的请求
RewriteCond %{QUERY_STRING} rest_route=/batch/v1
RewriteRule .* -

再看方案四。部署自定义安全插件

The research team released a minimal plugin that blocks unaunticated calls to batch endpoint while leaving logged‑in users unaffected.

• The filter runs before any or REST processing ensuring early blockage.
• If request targets “/batch/v1” and user is not logged in,a 401 error is returned immediately.
• This plugin should be used only as a stop‑gap;remove it after upgrading to a patched core version.

关于 REST API Batch 端点

The batch endpoint was introduced in WordPress 5.7 to let clients bundle multiple REST calls into a single HTTP request—great for reducing round‑trip latency in editors like Gutenberg.

The mechanism itself isn’t vulnerable;说起来，however its internal request‑splitting logic involves multiple permission checks and data handling steps,providing a larger attack surface than a single endpoint call. wp2shell exploits a flaw in this chain to achieve remote code execution.

If your site does not explicitly use batch API,disabling it will have virtually no impact on functionality while dramatically reducing risk.

本地开发环境的安全管理：从补丁到基础设施层面的思考

A large number of developers run WordPress locally for development and testing—se instances are often forgotten when it comes to patch management.

• If you use an integrated development environment such as **ServBay** or similar “one‑click” stacks。version control for PHP & WordPress is centralized in UI,allowing bulk upgrades without logging into each site individually.
• If you rely on AI coding assistants you likely store multiple AI service API keys across project config files—a breached WordPress instance could expose those keys.
• The **ServBay AI Gateway** solves this by keeping all AI credentials encrypted in a local gateway;projects call AI services through a unified endpoint so raw keys never touch your codebase.
• This “credential‑as‑infrastructure” approach dramatically limits post‑exploit damage even if an attacker gains file system access.

自查清单

1. 确认 WordPress 版本：登录后台 → 仪表盘 → 页面底部查看当前版本号，确保已升级至 ≥ 5.8.1 或 ≥ 6 × ≥ 6.^​.
2. 在后台 → 使用者 中核实是否出现陌生管理员账号。检查 wp-content 目录下近期新增或修改过的 PHP 文件是否可疑。 查看 WP-Cron 与服务器层面的 cron 是否有异常任务。话说回来， 如已开启请求日志。请搜索对 /batch/v1 端点的异常调用记录。

*备注这方面。若使用 ServBay 等统一管理网站，可在控制台“一键查看所有实例状态”，快速定位未打补丁实例。

---