WordPress released 7.0.3 on August 6, a security release the core team recommends installing immediately. Its headline entry is a pre-auth reflected cross-site scripting flaw on the login screen that can lead to PHP code execution, reported by the team at pwn.ai and tracked as CVE-2026-64638.

It is the second such release in three weeks, and the two numbers that bracket the first one matter more than either release. According to Patchstack, the critical chain fixed in 7.0.2 on July 17 was not found by a researcher reading the batch API line by line: Searchlight Cyber pointed an OpenAI model at WordPress core and had a working pre-auth SQL injection chained to remote code execution in ten hours, at a cost of about $25. After 7.0.2 shipped, the first exploitation attempts hit Patchstack’s sensors roughly 90 minutes later, three hours after the fix was committed to WordPress trunk. Both ends of the vulnerability lifecycle have compressed at once, and hosting companies occupy the space in between.

Key facts

  • Discovery: per Patchstack, a model produced the working chain in ten hours for roughly $25; WordPress.org credits Adam Kues at Assetnote and Searchlight Cyber for the report
  • Exploitation: the first attempts landed 90 minutes after 7.0.2 was released, which was three hours after the fix was committed to trunk; over the following days Patchstack blocked more than 65,000 attempts from over 1,500 addresses
  • Mitigation: Patchstack found that nearly every WAF rule published in the first hours was bypassable, including its own, because the rules matched on the request URL and WordPress accepts the same route from the POST body
  • Volume: WordPress security reports through HackerOne ran in the dozens per month for nine years and reached 450 in July, according to figures from core security lead John Blackbourn published by Patchstack

The July 17 timeline, measured from the moment the fix was committed to WordPress trunk, 1.5 hours before the release went out. Source: Patchstack telemetry.

Ten Hours and Twenty-Five Dollars

Patchstack names the model: OpenAI’s GPT-5.6 Sol Ultra, run against WordPress core by Searchlight Cyber. WordPress.org’s own release notes credit the resulting report to Adam Kues at Assetnote and Searchlight Cyber, which corroborates who found the flaw, though not the method or the price.

The August release points the same way. Two of its fixes are credited to companies built around AI: the login screen flaw to pwn.ai, which works on autonomous penetration testing, and an Author-level CSS injection to Anthropic. As Patchstack frames the shift, AI-assisted research used to mean a human researcher with a very fast assistant; now the model finds the flaw and carries it to exploitation, and the researcher’s job is to file the report.

The intake numbers show the volume that produces. Reports reaching WordPress through HackerOne, covering core, WordPress.org infrastructure and official plugins, ran at dozens per month for nine years, began climbing this spring and hit 450 in July, according to data from core security lead John Blackbourn published in Patchstack’s advisory.

None of that is bad news in itself, and Patchstack is careful to say so: more eyes on an open source codebase, moving faster, is a long-term gain. The consequence is about timing rather than merit. If a model can go from a standing start to working remote code execution in ten hours, the assumption that defenders have days between disclosure and exploitation no longer describes the world.

Ninety Minutes to a Live Campaign

The other end compressed too. The 7.0.2 problem was a two-part chain: a SQL injection in WP_Query reachable through the author_exclude parameter (CVE-2026-60137, affecting WordPress 6.8 through 7.0.1) plus a route and handler confusion in the REST API batch endpoint (CVE-2026-63030, affecting 6.9 through 7.0.1). Neither is a takeover alone. Chained, they let an unauthenticated request smuggle the injection past the schema that would normally sanitize it, and the published exploit walks from there to a new administrator and code execution. WordPress.org considered the severity high enough to enable forced updates through the auto-update system.

The two figures around that release describe the same moment from different starting points. The fix landed in WordPress trunk about 1.5 hours before 7.0.2 was tagged, and Patchstack treats that commit as the effective disclosure, because anyone watching core development can diff it and see exactly what changed. The first attempts arrived 90 minutes after the release, three hours after the commit.

Patchstack watched the aftermath from inside its customers’ sites, and what it saw looked less like one operator than a land rush: more than 65,000 blocked attempts from over 1,500 unique addresses, mostly from VPS and cloud ranges, with the busiest single network accounting for only 6.45 percent of the volume. Some 97 percent targeted the REST batch endpoint, and around three quarters carried an injection attempt in the author_exclude parameter.

Most of that was scanning. In Patchstack’s account, a small cluster of requests from just three addresses carried the complete chain and went straight for administrator creation, while a ready-made exploit tool circulated publicly under the name wp2shell. One caveat travels with all of these numbers: they count blocked attempts on sites that were running vulnerable versions, not completed compromises.

A Model Found the Artifactory Zero-Day; Only Self-Hosted Users Had to Patch

The WAF Rules Hosts Deployed in July Had a Common Blind Spot

The finding with the longest shelf life is not about the exploit at all. It is about the mitigation.

Nearly every WAF rule published in the hours after the July disclosure looked for batch/v1 in the request URL, because that is how every public proof of concept reached the endpoint. Patchstack found that WordPress registers rest_route as a public query variable and reads those variables from the POST body before it reads them from the query string. Send a plain POST to the site root with the route and the payload in the body, and WordPress routes the request to the batch endpoint while the URL still looks like an ordinary request to the homepage. A rule that inspects only the URL waves it through.

Because the gap was industry-wide rather than specific to one product, Patchstack handled it as a coordinated disclosure, notifying the affected vendors and the WordPress security team, which passed it on to major hosts and DNS-level WAF providers before publication. Patchstack states plainly that its own first rules had the same gap, and reports seeing attempts using the body-based form in the wild from July 21. For anyone maintaining their own rules, that is the actionable part: match the route wherever WordPress will accept it, not only where the proof of concept happened to put it.

What Is Actually in the August Release

The new release deserves proportion rather than panic. The login screen flaw is reachable without authentication, which is what makes it sound like the July chain, but a reflected XSS fires only in the browser of whoever clicks the crafted link. As Patchstack puts it, that makes it a targeted send rather than a drive-by, and if the person clicking is not an administrator the payload achieves nothing useful. If an administrator does click it, the path to code execution is real.

Two other entries deserve a hosting company’s attention more than the headline. There is a privilege escalation on multisite networks with user registration enabled, which lets a user create a new site, reported by Aikido Security. And there is a server-side request forgery in URL validation that allows requests to link-local ranges, the address space where cloud instance metadata services live. On shared or cloud-hosted fleets, that second one is a platform problem as much as an application problem. Patchstack counts 12 fixes in the release in total. Backports are still rolling out to older branches, currently as far back as 4.7, and WordPress 7.1 RC2 already contains the applicable fixes.

What This Changes for Hosting Companies

  1. Reading the release notes is no longer a defense. When the interval between a public commit and live payloads is three hours, any process that depends on a human noticing an announcement has already lost. The only mechanisms that operate on that timescale are automatic updates and pre-deployed virtual patches, and hosts control both.
  2. WordPress.org will push core updates itself when severity demands it. It did exactly that with 7.0.2, using the auto-update system rather than waiting for site owners. Hosts that suppress or delay core auto-updates for stability reasons now carry a larger risk than they did a year ago, and should be able to say out loud which of their plans update automatically.
  3. Rule quality is worth auditing, not assuming. The July bypass affected rules across the industry. A host buying virtual patching should be asking vendors how a rule is anchored, on the URL or on the behavior, and how quickly a rule was revised once the bypass surfaced.
  4. Maintenance windows are the wrong unit of time. If discovery costs ten hours and $25, and weaponization takes ninety minutes, the gap between a monthly patch cycle and the threat it is meant to answer is now measured in orders of magnitude.

Two core releases in three weeks may turn out to be a coincidence of scheduling. The economics behind them will not.