WP2Shell Detector and Validation PoC

CVE coverage: CVE-2026-63030 and CVE-2026-60137 Intended use: Authorized security testing, defensive validation, and disposable localhost labs only

WP2Shell is a WordPress Core vulnerability chain combining a pre-authentication REST API batch-route confusion bug (CVE-2026-63030) with a WP_Query author__not_in SQL injection primitive (CVE-2026-60137). This repository provides a Python proof-of-concept scanner and safe validator so defenders can fingerprint affected WordPress installations, confirm the vulnerable behavior in an isolated lab, and verify remediation — without needing to extract data or achieve code execution.

Overview

This project fingerprints WordPress installations and validates the two vulnerability primitives associated with the WP2Shell WordPress Core vulnerability chain:

• CVE-2026-63030 — REST API batch-route confusion.
• CVE-2026-60137 — incomplete sanitization of WP_Query::author__not_in, which can result in SQL injection when attacker-controlled input reaches the parameter.

When both conditions are present, an unauthenticated request may reach the vulnerable SQL construction through the WordPress REST API batch endpoint. Public advisories describe the combined impact as potentially leading to remote code execution.

This repository should be used only on systems you own or are explicitly authorized to test. Prefer an isolated Docker or virtual-machine lab bound to 127.0.0.1.

---

Safety Notice

The current source file contains state-changing functionality, including database-data extraction attempts, file-write attempts, authentication workflows, administrator creation, plugin upload, and command execution.

• WordPress fingerprinting.
• Version assessment.
• Local source-tree version checks.
• Safe route-confusion validation.
• Non-destructive timing-based SQL injection confirmation in an isolated lab.
• Reporting, evidence collection, and remediation.

---

Vulnerability Summary

CVE-2026-63030 — REST API Batch-Route Confusion

WordPress affected releases can lose alignment between internal arrays used to track:

• Parsed batch requests.
• Matched REST route handlers.
• Validation results.

When a malformed batch member is accepted into one internal array but not another, later requests can become associated with the wrong handler. A request may therefore be validated as one route but executed using another route's callback.

Security impact:

• REST request/handler desynchronization.
• Validation against the wrong route schema.
• Unexpected nested batch execution.
• Pre-authentication reachability of otherwise constrained code paths.
• When combined with CVE-2026-60137, potential SQL injection and further compromise.

CVE-2026-60137 — author__not_in SQL Injection

The affected WP_Query implementation does not consistently normalize author__not_in before using it to construct an SQL NOT IN (...) condition.

The parameter normally expects a list of integer author IDs. If a scalar string reaches the vulnerable query construction without the intended REST-schema validation, unsafe SQL structure can survive into the database query.

Security impact:

• Blind SQL injection.
• Boolean or timing-based database oracle.
• Potential disclosure of WordPress database contents.
• Increased impact when chained with CVE-2026-63030.

---

Affected Versions

WordPress branch	Affected	Fixed release
6.8.x	CVE-2026-60137 only: 6.8.0–6.8.5	6.8.6
6.9.x	Both issues: 6.9.0–6.9.4	6.9.5
7.0.x	Both issues: 7.0.0–7.0.1	7.0.2
7.1 prerelease	Beta 1 affected	Beta 2
Earlier than 6.8	Not affected by these two CVEs	N/A

WordPress released fixes on July 17, 2026 and enabled forced automatic updates for affected installations because of the severity.

---

Vulnerability Workflow

Unauthenticated client
        |
        v
WordPress REST batch endpoint
        |
        v
Malformed batch member creates request/handler misalignment
        |
        v
Later request is validated against one route
but dispatched using another route's handler
        |
        v
Scalar author_exclude reaches WP_Query as author__not_in
        |
        v
Unsafe value reaches SQL NOT IN (...) construction
        |
        v
Blind SQL timing or Boolean oracle
        |
        v
Potential database compromise
        |
        v
Potential application-level compromise and RCE

The detector should stop after confirming the route-confusion and SQL-injection primitives. It does not need to extract data or execute commands to establish that an affected installation is vulnerable.

---

Detection Workflow

Phase 1 — Normalize the target

The tool:

1. Adds a default http or https scheme if missing.
2. Normalizes the WordPress installation path.
3. Rejects unsupported URL schemes and embedded credentials.
4. Applies redirect, proxy, TLS, and timeout policies.

Phase 2 — Identify WordPress

The scanner checks for:

• wp-content/ references.
• wp-includes/ references.
• WordPress generator metadata.
• REST API discovery links.
• WordPress REST index structure.
• The wp/v2 namespace.
• Optional feed and readme.html fingerprints.

Phase 3 — Determine the version

Version evidence can come from:

• HTML generator metadata.
• Feed generator metadata.
• WordPress core asset query strings.
• HTTP generator headers.
• readme.html.
• A local wp-includes/version.php file.

Evidence is scored and reconciled. Conflicting remote version indicators lower confidence.

Phase 4 — Check batch-route exposure

The scanner attempts to discover /batch/v1 through:

/?rest_route=/
/wp-json/

The route can be addressed using either:

/?rest_route=/batch/v1
/wp-json/batch/v1

Phase 5 — Safe route-confusion probe

The safe probe contains:

1. A deliberately malformed internal path.
2. A request to an invalid post ID with a harmless nested public GET.
3. A following /batch/v1 request.

A vulnerable server returns an outer 207 Multi-Status response in which the invalid post request is processed as a nested batch request.

The detector reports:

route-confusion-observed

when it sees:

• The expected parse_path_failed marker.
• A second outer response with status 207.
• A nested responses array showing that the harmless internal request ran.

Phase 6 — Timing-based SQLi confirmation

A non-destructive SQLi validator should send paired requests that differ only by a constant Boolean condition:

False control -> no deliberate database delay
True test     -> deliberate database delay

The validator must:

• Accept the expected outer HTTP 207.
• Parse both the outer and nested batch envelopes.
• Verify the malformed-request markers.
• Ensure the SQLi-bearing nested request returned a valid response.
• Collect multiple true and false samples.
• Randomize or interleave sample order.
• Compare medians rather than a single request.
• Report insufficient measurements as inconclusive.

A repeatable gap between true and false samples confirms that attacker-controlled input reached SQL evaluation. No database contents need to be selected or extracted.

---

Requirements