TL;DR: wp2shell chains a WordPress REST API route-confusion flaw and a blind SQL injection into unauthenticated remote code execution across affected core versions, with active exploitation already observed and fixes available in 6.9.5 and 7.0.2, according to Escape. Version checks alone are not enough here; inventory, direct exploit validation, and rapid patch confirmation are the controls that matter.
NHIMG editorial — based on content published by Escape: wp2shell unauthenticated RCE chain in WordPress core
Questions worth separating out
Q: What breaks when WordPress route confusion removes the authentication boundary?
A: When route handling can desynchronise request context, the platform may evaluate authentication on one logical request while executing another.
Q: Why does SQL injection still appear in modern applications?
A: SQL injection persists because the fix is well known but not universally applied across legacy code, dependency code, and developer shortcuts.
Q: How should teams handle WordPress sites that are spread across many business units?
A: Treat them as one governed estate with many owners, not as isolated projects.
Practitioner guidance
- Inventory every WordPress property continuously Build a live list of marketing sites, docs portals, campaign microsites, and acquired domains, then tie each asset to an owner and patch status so no site can fall out of view.
- Validate exploitability on the live endpoint Run a safe timing-based test against /wp-json/batch/v1 and confirm whether the site accepts the route-confusion path instead of relying on version strings or banner checks.
- Patch and verify forced update completion Move affected installs to 6.9.5, 7.0.2, or 6.8.6 as applicable, then verify that automatic updates actually completed on every exposed property.
What's in the full analysis
Escape's full analysis covers the operational detail this post intentionally leaves for the source:
- Live exploit checks that confirm whether the batch route-confusion path and blind SQL injection are actually reachable on your asset.
- Asset-surface coverage across discovered WordPress properties so teams can see which sites are vulnerable, not just which versions appear exposed.
- Proof-of-exploit evidence from DAST and AI Pentesting to help triage remediation and separate theoretical exposure from confirmed compromise risk.
- Version-specific remediation guidance for affected branches, including the patch levels and interim containment options.
👉 Read Escape's analysis of the wp2shell WordPress core RCE chain →
wp2shell RCE chain in WordPress core: what teams need to know?
Explore further
wp2shell is a governance failure as much as a code flaw. The exploit works because a default attack surface was left reachable, then trusted too much once request context drifted. That is a familiar pattern in web estates that lack continuous asset inventory and path-level exposure testing. Practitioners should treat CMS access paths as governed attack surface, not static infrastructure.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
A question worth separating out:
Q: What should teams do immediately when a WordPress core RCE chain is exposed?
A: Contain first by reducing exposure to the vulnerable batch route, then patch affected versions and verify completion on every reachable site. After that, hunt for signs of privilege abuse such as new administrator accounts, suspicious files, and anomalous request patterns. If compromise is possible, treat the site as a platform incident, not just a vulnerability.
👉 Read our full editorial: wp2shell exposes unauthenticated WordPress RCE through route confusion