WordPress 7.0.2 Closes a Critical Pre-Auth RCE Chain as a Public Exploit Surfaces

The WordPress core team shipped version 7.0.2 on July 17, 2026, closing a two-bug chain that let an attacker read from the database of almost any self-hosted WordPress site without logging in first. Because of the severity, WordPress.org enabled forced automatic updates for every site running an affected version, pushing the fix out without waiting for site owners to click update.

The release fixes two separate flaws that only become dangerous when combined. WordPress.org’s official advisory tracks them as CVE-2026-60137 (GHSA-fpp7-x2x2-2mjf) and CVE-2026-63030 (GHSA-ff9f-jf42-662q). The advisory credits three researchers working as a team, TF1T, dtro, and haongo, with reporting the SQL injection half, and Adam Kues of Assetnote / Searchlight Cyber with reporting the REST API bug that makes it reachable without authentication.

How the two bugs chain together

The first bug, CVE-2026-60137, sits in WP_Query, the function that builds database queries for post listings. According to a technical breakdown from Patchstack, the author__not_in query variable was only sanitized into a list of integers when it arrived as a PHP array. If it arrived as a plain string instead, that sanitization step was skipped entirely, and the raw value was concatenated straight into the SQL WHERE clause. Under normal REST API processing, the matching author_exclude parameter is always validated as an array before it reaches that code, so this bug was not directly reachable on its own.

The second bug, CVE-2026-63030, is what makes it reachable. WordPress’s REST API batch endpoint lets a client bundle several sub-requests into one call, and the handler that processes them, WP_REST_Server::server_batch_request_v1(), keeps two internal arrays that are supposed to stay in sync: one holding every sub-request, and one holding only the sub-requests that resolved to a valid handler. Patchstack found that a deliberately malformed first sub-request, one with an unparseable path, gets recorded in the first array but is never added to the second, throwing off the index the batch handler later uses to match each request back to its permission checks and handler. Nesting the trick a second time shifts a request far enough that it gets validated against one endpoint’s rules but executed against a different endpoint entirely, letting the unsanitized author_exclude string reach WP_Query through an unauthenticated GET request. The result is blind, pre-authentication SQL injection.

Who is affected and how to update

WordPress.org’s advisory lays out which branches need which release. Version 6.8 is exposed only to the SQL injection half of the chain and is fixed in 6.8.6. The 6.9 line, and the 7.0 line through 7.0.1, are exposed to both bugs and are fixed in 6.9.5 and 7.0.2 respectively. Versions of WordPress before 6.8 are not affected. The in-development 7.1 beta was also affected and has a fix in beta2.

Because of the forced-update rollout, most sites with automatic background updates enabled should already be running a patched version. Site owners who manage updates manually should check the Updates screen in their WordPress Dashboard or download 7.0.2 directly from WordPress.org, and hosts or agencies managing several installs should confirm the forced update actually applied rather than assume it reached every site. For sites that cannot patch immediately, a write-up from Daily CyberSecurity suggests blocking /wp-json/batch/v1 and the rest_route=/batch/v1 parameter at the firewall, or requiring authentication on the batch endpoint, as temporary stopgaps rather than a substitute for updating.

Exploitation status is still developing

Patchstack said it pushed virtual-patching rules for both bugs immediately after disclosure and had already logged exploitation attempts against the flaw in its own traffic. Separately, Daily CyberSecurity reported that a security researcher has published working proof-of-concept code confirming the SQL injection, capable of extracting data from an affected database, including admin password hashes, though no confirmed successful site compromise has been publicly reported yet. That report also flags an important limit: turning the SQL injection into full remote code execution still requires cracking a recovered password hash offline and using it to log in and upload a malicious plugin, a step no public disclosure has walked through yet. That leaves the injection itself dangerous on its own, since it can expose site data and credentials well before anyone completes the jump to full code execution.

Cloudflare said it deployed two Web Application Firewall rules that automatically shield customers running affected WordPress versions, while still recommending that every site update to a patched release rather than rely on the WAF as a permanent fix. Searchlight Cyber, whose researcher found the critical half of the chain, estimates that more than 500 million sites run WordPress, and this bug needs no login and no vulnerable plugin: a stock installation with an unpatched core is enough to be exposed. With a public proof-of-concept now available for part of the chain, sites that have not yet confirmed they are running 6.8.6, 6.9.5, or 7.0.2 should treat this as an update to apply today, not sometime this week.