Each host is checked for CVE-2026-63030 (wp2shell). A timing check looks for the pre-auth batch-route issue.
Read-only against the REST batch endpoint. No shell is opened.
Results
report.json: which hosts look vulnerable, which do not, and any check errors.
Target
WordPress hosts, one URL or domain per line. Default http://localhost.
Overview
wp2shell is the pre-auth remote code execution chain in WordPress Core: a
route-confusion desync in the REST batch processor (CVE-2026-63030) lets a SQL
injection in the posts endpoint that WordPress normally blocks (CVE-2026-60137)
through. It hit CISA's Known Exploited list within days of the July 2026
disclosure, and it needs no plugins, no configuration, and no login. This
workflow takes a list of WordPress hosts and tells you which of them the chain
actually fires on. It sends the nested-batch payload, confirms the route
confusion by its two error markers, then proves the injection with a calibrated
time oracle rather than assuming a version number is enough. Every host comes
back sorted into exploitable or not, so a fleet-wide advisory turns into an
evidenced fix list for offensive security.
Pipeline
Read the target list: the WordPress hosts, URLs, or ranges to check.
Each target is probed against /?rest_route=/batch/v1. The nested-batch
payload has to return both the parse_path_failed and rest_batch_not_allowed
markers, which is the route-confusion desync of CVE-2026-63030; a host missing
either is recorded as not wp2shell and skipped. The probe runs distributed
across the fleet, so the whole list is tested in one pass.
On a host that shows the markers, the injection is confirmed with a timing
oracle: a SLEEP-based payload through the author_exclude parameter is
calibrated against true and false conditions, and the host counts as
vulnerable only when the true condition is measurably slower.
The per-target results are collected and written to a report with the
exploitable hosts, the timing evidence, and the fleet vulnerability rate.
Inputs
Target list. The WordPress hosts to check, as domains or URLs, one per
line. Point it at scope you are authorised to test.
Outputs
Exploitable host list. The targets where both the route-confusion markers
and the blind SQLi fired, separated from the ones that did not.
Per-target evidence. For each host: whether the markers were present,
whether the SQLi was confirmed, and the calibrated timing that decided it, so
a finding can be checked rather than taken on trust.
Final report. The exploitable set, the counts, and the vulnerability rate
across the whole list, in one file you can hand to whoever owns remediation.
Sample output
Illustrative, in the record shape the workflow emits. Real runs name live hosts,
so the targets here are documentation domains.
Each target comes back with its markers, whether the SQLi was confirmed, and the
timing that decided it. A host that fails the marker check is set aside rather
than probed further:
It is a route-confusion logic flaw in the WordPress REST API batch processor
(/wp-json/batch/v1), introduced in WordPress 6.9. On its own it desynchronises
the batch validator, and chained with the CVE-2026-60137 SQL injection it becomes
wp2shell, an unauthenticated path to remote code execution. This workflow tests
for the chain rather than describing it, so treat the run output as the authority
on which of your hosts are affected.
Which WordPress versions are affected?
WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, plus the 7.1 betas.
The fix ships in 6.9.5 and 7.0.2. Versions before 6.9 do not have the batch
processor path and are not affected. Because it confirms the flaw by behaviour,
this check does not depend on the version string a host advertises.
Does it drop a shell, or just detect the flaw?
It confirms exploitability and stops there. It proves the route confusion and the
blind SQL injection with a timing oracle; it does not go on to create an
administrator, upload a plugin, or execute code. The output is evidence that a
host is exploitable, not a compromised host.
Does it need credentials for the target?
No. The chain is pre-auth, so the check runs exactly as an unauthenticated
attacker would, with no login to the target and no WordPress account.
Can I run this against a host I do not own?
Run it only against scope you are authorised to test. It sends a real injection
payload to confirm the flaw, which is an intrusive act, not a passive scan.
Related workflows
Scan WordPress for Known CVEs.
Reach for this instead when you want a WordPress host's full posture, its core
and plugin versions and known CVEs, rather than a yes or no on this one chain.
ASN-Wide Vulnerability Scan. Reach for this
when you do not have the host list yet and need to turn an ASN into its live
hosts before checking any of them.