# Ninety minutes from patch to attack: the WordPress flaw that needed no password
*A vulnerability chain in WordPress core let anyone take over a stock installation with a single anonymous request — and the first exploitation attempts arrived before most administrators had read the advisory.*
WordPress shipped an emergency patch on Friday, July 17. Roughly 90 minutes later, attackers were already using the bug it fixed.
That window is the story. Not the flaw itself, remarkable as it is — the first critical unauthenticated remote code execution in WordPress core in nearly a decade — but the speed at which a patch became a weapon. Patchstack, which watched it happen across its sensor network, put it plainly: "Ninety minutes is fast, but it's not surprising anymore. It's what 'industrialized' exploitation looks like: someone reads the patch, someone else turns it into a scanner, and the scanner gets pointed at everything."
## What happened
The chain, nicknamed wp2shell, links two flaws in WordPress core itself — no plugin, no theme, no unusual configuration required.
The first, CVE-2026-63030, is a route confusion bug in the REST API batch endpoint, a default feature since WordPress 5.6. The endpoint validates sub-requests in one pass and executes them in another, tracking them in parallel arrays. Feed it a malformed path and the arrays fall out of step, so a sub-request runs under a different one's permission check — walking past the allow-list. Attackers steer that into the second flaw, CVE-2026-60137, a SQL injection in the `author__not_in` parameter.
Severity is contested: the WordPress CNA rates the route confusion 9.8 critical, CISA's own analysts rate it 7.5 and score the injection higher. Either way, CISA added both to the Known Exploited Vulnerabilities catalog on July 21 with a three-day federal deadline for the first. From there attackers either forged database rows that WordPress acts on to mint an administrator account, or wrote a PHP webshell straight to disk — Wiz found one disguised as a plugin named CMSmap, 150 KB with a GUI, file manager and privilege escalation modules.
The affected versions are narrow and worth getting right. Sites on 6.8.0 through 6.8.5 face the SQL injection only; the full code execution chain requires 6.9.0–6.9.4 or 7.0.0–7.0.1. Fixes landed in 6.8.6, 6.9.5 and 7.0.2, and WordPress forced updates through the auto-update system. Anything before 6.8 is unaffected.
## Why it matters for Texas institutions
Higher education runs on WordPress at a scale central IT rarely has mapped. Department sites, lab groups, conference microsites, faculty pages, centers and institutes — often stood up years ago by someone who has since graduated, frequently on a server nobody inventories.
Two things make this bug bite harder there. Exploitation required no credentials and no user interaction, so there was no phishing step to catch and no login to monitor. Mondoo's Patrick Munch described it as "no stolen password, no phished user, no vulnerable plug-in. Just one anonymous request to a stock install." And a clean run leaves little in access logs, because the decisive steps ride inside batch POST bodies.
The government angle is direct. MS-ISAC issued advisory 2026-070 rating the risk high for large and medium government entities, and said its own SOC observed automated scanning and exploitation against its state, local, tribal and territorial membership. No named .edu compromise has been published — but watchTowr counted more than 100 backdoor administrator accounts across its honeypot network.
## What your institution should do
**Patch, then assume nothing.** Confirm every instance is on 6.8.6, 6.9.5 or 7.0.2. Forced auto-updates helped, but a site compromised before July 17 stayed compromised. watchTowr's Jake Knott is blunt: "Defenders need to inspect their WordPress instances for new administrator accounts, malicious plug-ins, or other suspicious files, regardless of whether they've patched."
**Find the sites you forgot you had.** Scan your address space for WordPress rather than trusting an inventory. Searchlight maintains a checker at wp2shell.com; Eye Security published a free compromise-scanner plugin.
**Rotate credentials even on SQLi-only versions.** The injection alone reads `wp_users`, and early exploitation was observed exfiltrating password hashes.
**If your WAF rule only matches the URL, it is already bypassed.** Patchstack disclosed that nearly every rule published in the first hours was evadable, because WordPress reads `rest_route` from the POST body before the query string. Cover `/wp-json/batch/v1`, `?rest_route=/batch/v1`, and the POST-body form — and note that blocking the endpoint breaks the block editor.
**Hunt the host artifacts.** Administrator accounts you did not create, stray PHP under `wp-content/uploads` and especially `wp-content/mu-plugins`, webshells in `wp-content/cache/`, and HTTP 207 responses to batch endpoint requests — which Wiz calls a high-fidelity indicator of successful exploitation.
## RSOC is here to help
If you need help finding unmanaged WordPress across your address space or hunting these indicators, the Regional Security Operations Center can assist. RSOC provides attack surface discovery, vulnerability scanning, threat intelligence and incident response support to Texas higher education institutions and state agencies: [rsoc.utexas.edu](https://rsoc.utexas.edu).