wp2shell_scanner

Non-intrusive detection scanner for recent WordPress core vulnerabilities — including the wp2shell pre-authentication RCE chain.

wp2shell_scanner.py fingerprints a WordPress site's core version and reads its publicly advertised REST API surface, then classifies each tracked core CVE independently against the detected version. Verdicts are branch-aware — e.g. a 6.8.x site is correctly reported as exposed to the SQL-injection CVE but not to the full RCE chain. It detects only: no exploit payload is ever sent. Single file, one dependency (requests), CI-friendly exit codes, and client-ready HTML / JSON / e-mail reports.

⚠️ Authorised use only. Scan systems you own or are explicitly authorised (in writing) to test. The scanner sends an identifying User-Agent so blue teams can attribute the traffic — it does not hide.

Tracked vulnerabilities (WordPress core)

The wp2shell RCE chain = CVE-2026-63030 + CVE-2026-60137 together → pre-auth remote code execution on a default install. The scanner reports the chain as exposed only when both CVEs classify as vulnerable for the detected version.

Branch nuances the scanner gets right:

• 6.8.x carries the SQL injection (CVE-2026-60137) only — not the RCE chain.
• On the 6.9 branch, CVE-2026-3906 (Notes) is fixed in 6.9.2, but the wp2shell chain is not closed until 6.9.5. So 6.9.2/6.9.4 read patched for the Notes bug yet remain vulnerable to the RCE chain — the scanner therefore only recommends 6.9.5 or later on that branch, never 6.9.4.

Operationally important: technical write-ups and a working PoC for wp2shell are already public. Version detection is now the absolute minimum — the priority is patching. Updating closes the vulnerable path but does not remove a backdoor planted before the patch — hence the compromise-assessment step in the report.

Scope

This is a core-version scanner. Plugin and theme CVEs — the large majority of the WPScan / Patchstack catalogue — require a live, curated feed and per-plugin version enumeration, and are intentionally out of scope here. Within its lane (recent WordPress core CVEs), it aims to be precise and branch-accurate rather than to duplicate a commercial vulnerability database.

What the scanner does

• Passive WordPress fingerprinting across four public version vectors:
  • <meta name="generator"> on the homepage
  • /readme.html
  • RSS / Atom feed <generator> tag
  • /wp-links-opml.php (OPML)
• Cross-checks the vectors. If they disagree on the version, or a pre-release build (beta/RC/alpha) is seen, the verdict is forced to UNKNOWN — the scanner never reports a possibly-false Patched from conflicting evidence.
• REST API surface discovery — reads /wp-json/ to see whether WordPress advertises the batch/v1 namespace in its REST index. This confirms the namespace is registered, not that the endpoint is reachable through a WAF. No batch request and no payload are sent.
• Per-CVE verdict — the detected version is classified independently against each tracked CVE (branch-aware), plus outputs:
  • a client-ready HTML report (print → PDF),
  • a JSON record (pipeline/EAV-friendly),
  • a draft notification e-mail.

What it explicitly does not do

It does not exploit anything. No SQL-injection payload, no batch-route-confusion request, no attempt to execute code or read data. Detection is version-based plus a passive read of the publicly advertised API surface.

Install

pip install requests

Usage

# single target
python3 wp2shell_scanner.py -t https://site.example --authorized

# list of targets (one per line, # comments allowed)
python3 wp2shell_scanner.py -T scope.txt --authorized -o ./reports

# preview the output formats with synthetic data — no network, no auth needed
python3 wp2shell_scanner.py --demo -o ./reports

Flags

The --authorized flag is an explicit authorisation gate — live scans refuse to run without it.

Exit codes (CI-friendly)

Configuration

The notification e-mail recipient is the CSSLTD_CONTACT constant near the top of the script (default [email protected]). Edit it to your own intake address.

Verdicts

Example output

The examples/ directory contains synthetic (--demo) output for a fictional vulnerable host (example.com, WordPress 6.9.1 — exposed to all three tracked CVEs):

• wp2shell_report_example.com.html — the client-ready HTML report
• wp2shell_example.com.json — the JSON record
• wp2shell_email_example.com.txt — the draft notification e-mail

These are generated from fabricated data to illustrate the report format. They are not the result of scanning any real site.

Remediation (as emitted in the report)

1. Take a verified backup (DB + full file tree) first.
2. Update WordPress core to a release that clears every tracked CVE — 6.8.6 / 6.9.5 / 7.0.2 — or later on the matching branch. (On 6.9, only 6.9.5+ is clear — 6.9.4 still has the wp2shell chain.)
3. Confirm the site and admin still work.
4. Assume compromise if the host was exposed while vulnerable — run a compromise assessment across themes, plugins, uploads/, wp-config.php, wp-cron, and admin accounts; run file-integrity checks against known-good core.
5. Add defence-in-depth at the edge (WAF rules, restrict /wp-json/batch/v1).
6. Rotate secrets (auth salts, admin/DB passwords, API keys) if compromise is suspected.
7. Re-scan to confirm the verdict now reads Patched.

References

• WordPress GitHub Security Advisory — wp2shell RCE chain (GHSA-ff9f-jf42-662q)
• WordPress GitHub Security Advisory — author__not_in SQLi (GHSA-fpp7-x2x2-2mjf)
• WordPress GitHub Security Advisory — Notes REST API (GHSA-6x83-fcf5-r65g)
• NVD — CVE-2026-63030 · NVD — CVE-2026-3906
• Rapid7 — ETR: CVE-2026-63030 wp2shell
• VulnCheck — WP2Shell (CVE-2026-63030 & CVE-2026-60137)
• WordPress releases (safe targets: 6.8.6 / 6.9.5 / 7.0.2)

Disclaimer

This tool is for authorised security testing only. You are responsible for ensuring you have permission to scan any target. Unauthorised scanning may be unlawful. The authors accept no liability for misuse.