PoC
I spent the last day independently reverse-engineering wp2shell, the newly disclosed pre-authentication WordPress Core vulnerability chain involving CVE-2026-63030 and CVE-2026-60137. Full discovery and disclosure credit belongs to Adam Kues and Searchlight Cyber—I did not discover the vulnerability; I reconstructed it from the publicly available WordPress patches, reproduced it in a controlled lab environment, and implemented an independent PoC.
I began by diffing WordPress 7.0.1 against 7.0.2 and analyzing the three security-related commits. The first issue was an SQL injection sink in WP_Query::get_posts(): author__not_in was sanitized only when supplied as an array, allowing a scalar string to reach the post_author NOT IN (...) SQL construction. The patched version normalizes it through wp_parse_id_list().
Under normal REST processing, this should not be exploitable because author_exclude is validated as an array of integers. The critical delivery primitive was in serve_batch_request_v1(), where the request, route-match, and validation arrays could become desynchronized when a malformed subrequest failed to parse the URL. This caused one subrequest to be validated against its intended route but executed using another subrequest’s handler—effectively creating REST route confusion.
A single confusion was not enough because the anonymous handler reaching author_exclude is GET-based, while the batch schema rejects GET subrequests. The chain therefore required applying the confusion twice: first to execute a request as the batch handler itself, creating an inner batch that bypassed the outer method restriction, and then again to deliver the unsanitized scalar value into the vulnerable query path.
To validate this, I built a loopback-only Docker lab containing vulnerable WordPress 7.0.1 and patched 7.0.2 installations on the same PHP/Apache base with MariaDB. I added instrumentation to log the executed REST handlers, final WP_Query SQL, and database errors, then ran a differential test matrix against both versions.
The result was a clean split: the vulnerable version reached the injected post_author NOT IN (...) query path, while the same request on 7.0.2 was stopped by the corrected batch matching logic. I also confirmed the complete SQLi-to-RCE path under deliberately non-default laboratory conditions where the database had file-write privileges, and the webroot was writable.
The PoC is intentionally lab-only and non-weaponized: it refuses external targets, requires an explicit acknowledgment flag, supports dry-run mode, produces a JSON verdict, uses a fixed harmless proof action, and removes its artifacts afterward. No reverse shell, mass scanning, credential extraction, or arbitrary command interface.
Full root-cause analysis, source-level patch diff, request-flow diagrams, vulnerable-versus-patched evidence, detection guidance, and the reproducible laboratory will be published soon.
#wp2shell #WordPress #VulnerabilityResearch #AppSec #ExploitDevelopment #CyberSecurity #RedTeam
Post summary
The author reconstructed and documented a lab‑only PoC for the CVE‑2026‑63030/CVE‑2026‑60137 WordPress vulnerability chain, providing detailed technical analysis yet providing no evidence of active exploitation or functional exploit code.
