wp2shell-check

Non-intrusive checker for CVE-2026-63030 / CVE-2026-60137 ("wp2shell"), a pre-authentication RCE chain in WordPress core (REST API batch-route confusion → SQL injection → RCE).

• Affected: WordPress 6.9.0–6.9.4, 7.0.0–7.0.1, 7.1 beta (full RCE chain); 6.8.0–6.8.5 (SQL injection only, CVE-2026-60137).
• Fixed in: 6.8.6, 6.9.5, 7.0.2.

What it does

• Fingerprints the WordPress version remotely (readme.html, homepage <meta name="generator">, /feed/ generator tag).
• Classifies each target as vulnerable / patched / unknown based on the version ranges above.
• Checks whether the vulnerable REST route (/wp-json/batch/v1, ?rest_route=/batch/v1) is reachable — a secondary signal for whether a WAF/REST-API mitigation is already in place.

What it does NOT do

It sends no SQL injection or RCE payload. The full exploit chain hasn't been independently verified here, and firing untested injection payloads at production sites can cause real damage even when "just testing". Treat this as safe triage, and confirm ground truth with wp core version on the host or an authenticated vendor scanner.

Only run this against systems you are authorized to test.

Usage

python3 wp2shell_check.py https://site1.example.com https://site2.example.com
python3 wp2shell_check.py -f targets.txt -o report.csv --workers 8
python3 wp2shell_check.py -f targets.txt --insecure   # internal self-signed certs

targets.txt: one URL/hostname per line, # for comments.

Exit codes: 2 = vulnerable found, 1 = version undetermined for at least one target, 0 = all patched.

Notes on false negatives

A 404 on the batch route doesn't always mean "patched" — it can also mean a WAF/CDN or a security plugin is blocking anonymous REST API access in front of an otherwise vulnerable install (check response headers/body for WAF fingerprints). Only an upgrade to a fixed version actually removes the vulnerable code.

Requirements

Python 3.8+, standard library only (no extra dependencies).