wp2shell: Unauthenticated RCE in WordPress Core — Patch Every Site Now

A pre-authentication remote code execution flaw in WordPress Core, dubbed wp2shell, lets attackers seize unpatched sites with a single crafted HTTP request. No credentials, no plugins, no special configuration required. With WordPress powering the majority of African business websites, this one demands action today.

Hadrian and Searchlight Cyber are urging WordPress administrators to update immediately after publishing technical details of the flaw, which lives in the platform’s built-in REST Batch API. Adam Kues of Searchlight Cyber first reported the issue and released a public checker, holding back the technical breakdown until a patch was available. That grace period ended when Hadrian published its root-cause analysis on 20 July.

What Makes wp2shell Dangerous

Most WordPress vulnerabilities hide in plugins or themes. wp2shell sits in Core itself, in the batch/v1 REST endpoint that ships enabled by default. Reconstructing the bug from the security patch released on 17 July, Hadrian found an indexing mismatch during request validation: request objects and their permission checks fall out of alignment, so a crafted batch request gets processed under the wrong authorization context.

The result is unauthenticated code execution on the web server. “In practice, that means full control of the site and its content, access to the database and whatever credentials or personal data it holds, and a way into the surrounding hosting environment,” the researchers said.

The vulnerable endpoint answers at both /wp-json/batch/v1 and /?rest_route=/batch/v1. The second path works even on deployments without URL rewriting, which describes most shared hosting setups across the continent.

Who Is Affected

WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable. The fix ships in 6.9.5 and 7.0.2. Version 6.8.6 carries the same hardening, though earlier 6.8.x releases are not affected by this specific flaw.

Working exploits tend to follow within days once technical details go public for a bug this accessible. The analysis is now out, and the vulnerable population numbers in the tens of millions of sites globally.

Why African Enterprises Should Treat This as Urgent

WordPress runs an outsized share of the African web: SME storefronts, fintech landing pages, NGO portals, government service sites, and the campaign microsites agencies spin up and forget. Patch cadence on the continent is often measured in months, not days. Many of these sites sit on shared hosting, where one compromised neighbour can expose the entire box.

Hadrian’s advice deserves emphasis: inventory everything. Staging sites, forgotten campaign pages, the event microsite nobody has logged into since 2024. If it runs a vulnerable WordPress version and the REST API is reachable, it is a shell waiting to happen. A shell on a forgotten subdomain is a foothold into the rest of the business.

What To Do Now

1. Patch to WordPress 6.9.5 or 7.0.2 immediately. Verify the update actually completed. Failed auto-updates leave the old code in place while reporting success.
2. Inventory every WordPress deployment. Include staging environments, campaign sites, and subdomains. Anything running 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 is exposed.
3. Block the batch endpoints where patching lags. Restrict /wp-json/batch/v1 and /?rest_route=/batch/v1 at the web server or WAF until the update lands.
4. Review REST API exposure generally. Most brochure sites do not need the REST API open to the world. Disable or restrict it where it serves no business function.
5. Check for signs of compromise. Look for unexpected admin users, modified core files, unfamiliar scheduled tasks, and outbound connections from the web server to unknown hosts.

Where Network-Layer Security Fits

Patching fixes wp2shell. It does not fix the structural problem: application-layer flaws arrive faster than most organisations can patch them. The compensating control is to shrink what an attacker can reach in the first place.

eHawu’s zero-trust network architecture restricts which devices and users can reach administrative and API surfaces at the network layer, before a request ever touches WordPress. Management planes, staging environments, and internal APIs sit behind encrypted tunnels that do not respond to unauthenticated internet traffic at all. Every packet travels under AES-256-GCM with perfect forward secrecy, so when an application-layer flaw like wp2shell lands, the blast radius stays small. The attacker’s reach stops at what the network explicitly allows.

Patch today. Then check how much of your infrastructure answers to anyone on the internet with a crafted request. If the answer makes you uncomfortable, eHawu was built for it.