wp2shell: patch WordPress, then check who got there first

02 Technical BreakdownFor engineers

Right, the nitty-gritty. wp2shell chains two CVEs. The first, CVE-2026-63030, is a route-confusion flaw in the REST batch endpoint, /wp-json/batch/v1, which lets a visitor bundle several API calls into a single request. Think of the batch handler as a bouncer checking a whole group's IDs in one go. It runs two loops: the first validates every subrequest and records matched route handlers in two parallel arrays, the second executes them. If a subrequest fails early (say, a malformed path), the code appends the error to the validation array but continues before appending to the matches array. The two arrays are now off by one, the bouncer has lost track of which ID belongs to which guest. Every later subrequest gets executed using the handler matched for the request after it. Net effect: you can validate one request and execute it as another, which bypasses parameter sanitisation on every batch-enabled endpoint.

The second, CVE-2026-60137, is a SQL injection in WP_Query's author__not_in handling (the code behind the posts endpoint's author_exclude parameter). Pass an array and every element is forced through absint, pass a scalar string and it is interpolated straight into the SQL, untouched. Normally the API's parameter validation only lets the array form through, but the batch desync lets us borrow a different route's validation and skip that check entirely. Two neat tricks make it weaponisable: the batch API rejects GET subrequests, but the method check is itself parameter validation, so a recursively nested batch request desyncs a second time to smuggle the GET in; and a UNION-based injection then lets the attacker return fully forged wp_posts rows.

From a read-only SQLi to code execution is where the chain gets properly absurd, and credit where due, the model worked this bit out faster than the human could untangle it. The short version: forged post rows poison WordPress's in-memory post cache, the oEmbed feature can be prodded into persisting those fake posts as real database rows, a cycle-detection gadget in post-parent handling forces a database write that doesn't clobber the fields the attacker controls; a forged customize_changeset row with user_id 1 makes WordPress briefly assume the administrator's identity; and a fake post with status parse and type request fires the parse_request hook, replaying the original batch request from scratch, this time as admin. One subrequest in that batch creates a new administrator account. Log in, upload a plugin zip, shell. Full details, and they're worth reading, are in Searchlight's writeup (linked in References).