Backend · PHP

A Pre-Auth RCE in WordPress Core Puts 500 Million Sites at Immediate Risk

By ServBay · Jul 18, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

A pre-auth RCE in WordPress Core means every unpatched default install is exploitable with zero interaction. With over 500 million active sites, even a single-digit percentage of unpatched instances represents tens of millions of reachable targets for automated mass exploitation.

Summary

A core-level pre-authentication RCE vulnerability, designated wp2shell, affects default WordPress installations without requiring any plugins or user credentials. The flaw sits in the REST API batch endpoint processing chain, giving anonymous attackers a direct path to remote code execution. Versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable; patches ship in 6.9.5 and 7.0.2.

Mitigation options include upgrading immediately, blocking the /batch/v1 endpoint via WAF rules or a custom plugin, or installing a REST API disabler. Most standard WordPress sites do not rely on the batch endpoint, so blocking it carries low functional risk. Searchlight Cyber has withheld technical exploit details but released an online detection tool for site operators.

The incident also surfaces a secondary risk for developers who run local WordPress instances alongside coding agents. API keys stored in plaintext project configs become harvestable if a local site is compromised, pushing credential management down to the infrastructure layer as a necessary hardening step.

Takeaways

— WordPress Core versions 6.9.0–6.9.4 and 7.0.0–7.0.1 contain a pre-authentication RCE vulnerability in the REST API batch endpoint.

— Attackers need no login, no plugin, and no user interaction to exploit a default WordPress installation.

— Upgrading to WordPress 6.9.5 or 7.0.2 applies the official patch.

— Blocking the /wp-json/batch/v1 path and the rest_route=/batch/v1 query parameter via WAF rules cuts off the attack surface.

— A custom plugin that rejects unauthenticated requests to /batch/v1 provides an emergency mitigation without affecting logged-in users.

— Most standard WordPress sites do not call the batch API endpoint directly, so disabling it carries minimal functional impact.

— Local development WordPress instances are equally vulnerable and often overlooked in patch cycles.

— Plaintext AI service API keys in project config files become a secondary target if a local WordPress site is compromised.

Conclusions

wp2shell breaks the pattern of WordPress security incidents living in the plugin ecosystem; a core bug shifts the responsibility from plugin authors to every site operator running a vulnerable version.

The batch API endpoint was introduced for editor performance, but its complex processing chain created an attack surface that most sites never needed to expose.

Withholding exploit details while shipping a detection tool is a pragmatic disclosure strategy that buys patching time without leaving operators blind.

Local development environments are treated as low-risk by default, yet they often hold the same code, configs, and now API credentials as production, making them a soft underbelly in the agent-coding era.

Concepts & terms

Pre-Authentication RCE

A remote code execution vulnerability that can be triggered without logging in or providing any credentials, making it exploitable by anonymous attackers with no prior access.

REST API Batch Endpoint

A WordPress feature introduced in version 5.6 at the path /batch/v1 that allows multiple REST API calls to be bundled into a single HTTP request, reducing network round trips for the block editor.

rest_pre_dispatch filter

A WordPress hook that fires before a REST API request is processed, allowing plugins to intercept and reject requests based on custom logic such as authentication checks.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗