Pre-Auth SQL Injection in WordPress Core via Batch API Desync

CVE-2026-63030 and CVE-2026-60137 stem from an array-indexing bug in WordPress's REST batch endpoint (/wp-json/batch/v1). serve_batch_request_v1() tracks sub-requests in two parallel arrays — one for validation, one for dispatch handlers — indexed by the same offset. When a sub-request's path fails wp_parse_url(), an error is recorded in the validation array but skipped in the handler array, desynchronizing the two and causing every subsequent sub-request to be dispatched to the wrong handler.

By nesting batch requests twice, an attacker can get the posts handler to process a categories request. Since the categories schema doesn't define the author_exclude parameter, it passes validation untouched and flows into WP_Query::author__not_in, where it's sanitized only if it's already an array — a plain string bypasses that check and is interpolated directly into SQL. The result: unauthenticated database reads via boolean oracle, and file writes (hence RCE) on installations where the MySQL user has FILE privilege.

An educational PoC accompanying the disclosure also demonstrates a materially faster extraction method than classic blind boolean SQLi: using the X-WP-Total response header as a per-character bitmask oracle, combined with the fact that route confusion bypasses the batch API's inner size limit. This cuts a 34-character phpass hash extraction from roughly 224 requests down to about 3. The bugs were fixed in WordPress 6.9.5 and 7.0.2, and the case is a reminder that validation and dispatch logic must stay indexed against a single source of truth.