What is affected
This is a core vulnerability, not a plugin one. No amount of plugin hygiene protects you.
Sites on 6.8.x are not exposed to the full chain — the batch-API flaw was introduced in 6.9 — but they still need 6.8.6 for the SQL injection half.
How the chain works
Two flaws, neither of which is enough on its own. CVE-2026-63030 is a logic bug in the REST API batch processor, at/wp-json/batch/v1. Validation and execution run in two separate loops. When wp_parse_url() fails on a sub-request path, the error is appended to the validation array but not to the matches array. The two arrays fall out of alignment, and from that point on every subsequent sub-request is dispatched under the wrong handler.
That misalignment is the whole trick: a request gets executed by a handler that never validated its parameters.
CVE-2026-60137 is an SQL injection in the author__not_in parameter of WP_Query, scored 5.9 on its own — the kind of finding that would normally sit in a backlog.
Chained, the routing confusion delivers unvalidated parameters into the injectable query. The published path goes from there to creating an administrator account, and from an administrator account to code execution through the plugin installer. Full site takeover, no credentials at any step.
This is a good illustration of why a medium-severity finding is not a low-priority one. CVE-2026-60137 alone is a 5.9. Given a routing bug to pair with, it becomes half of a 9.8.
Timeline, and why it matters
- 17 July 2026 — public disclosure via a GitHub Security Advisory. Public proof-of-concept exploits appeared on GitHub within hours.
- 21 July 2026 — CISA adds both CVEs to the Known Exploited Vulnerabilities catalog.
- 22 July 2026 — full technical write-up of the chain published.
Updating
WordPress.org pushed forced automatic updates to affected installations that had auto-updates enabled. Do not assume this covers you — sites with auto-updates disabled, sites under version control, and sites where the core files are not writable were not updated. Check what you are actually running:Take a backup before updating, not after. If the update goes badly you want a rollback point; if you turn out to have been compromised, you want a copy of the evidence.
Checking whether you were hit
Patching closes the door. It does nothing about anyone already inside. Three checks, in order of usefulness: Unexpected administrator accounts. The published chain creates one. Look at every account with elevated rights and the date it was created.wp-content.
wp-content/uploads is essentially never legitimate.
If any of these turn something up, treat the site as compromised: restore from a backup predating the first suspicious event, then update, then rotate every password and API key. Cleaning a live compromised site file by file rarely ends well — see our checklist for hardening WordPress after this incident.