Security Digest · Jul 17, 2026 · Vulnerability · Web framework

WordPress 7.0.2: REST Batch + SQL Injection Chain to RCE

Two WordPress core bugs chain into unauthenticated RCE on 6.9 and 7.0. Fixed in 7.0.2, 6.9.5 and 6.8.6, with forced auto-updates. Exploited (CISA KEV).

Our verdict

Act now

Core WordPress 6.9 and 7.0 sites were exposed to unauthenticated remote code execution that is now exploited; most sites got a forced update, so your job is to confirm every one actually did.

Who must act: Anyone running WordPress 6.9.x before 6.9.5 or 7.0.x before 7.0.2 (RCE chain), or 6.8.x before 6.8.6 (SQL injection), especially with auto-updates disabled or blocked.

Who can relax: Sites already on 7.0.2, 6.9.5, 6.8.6 or later (including 7.1), and WordPress versions before 6.8, which WordPress says are not affected.

Affected
WordPress 7.0.0-7.0.1 (both CVEs)
WordPress 6.9.0-6.9.4 (both CVEs)
WordPress 6.8.0-6.8.5 (CVE-2026-60137 only)
WordPress 7.1 beta1
Fixed in
WordPress 7.0.2
WordPress 6.9.5
WordPress 6.8.6
WordPress 7.1 beta2
CVSS
9.8 (v3.1, CNA)
EPSS
10.6% (percentile 96)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
Critical

What to do

  1. Check every site's core version (wp core version) and confirm it is 7.0.2, 6.9.5, 6.8.6 or later.
  2. Update any site that missed the forced update: wp core update --minor, or Dashboard > Updates.
  3. Find out why auto-updates did not apply (AUTOMATIC_UPDATER_DISABLED, WP_AUTO_UPDATE_CORE=false, read-only filesystems, version-pinned images) and fix it.
  4. Rebuild container images that pin a vulnerable WordPress version instead of restarting old containers.
  5. Treat any site that ran a vulnerable 6.9 or 7.0 release after July 17 as possibly compromised and review it.

How to check if you are affected or compromised

  • Run wp core version and wp core verify-checksums on every install to confirm the version and spot modified core files.
  • Review web logs for unusual POSTs to /wp-json/batch/v1 (or ?rest_route=/batch/v1) around and after July 17.
  • List admin accounts (wp user list --role=administrator) and look for unfamiliar ones or recent creation dates.
  • Look for new or modified PHP files in wp-content/uploads, plugins and mu-plugins, and for unexpected processes run by the PHP user.

What happened#

On July 17, 2026, WordPress released 7.0.2, fixing "one critical and one high severity security issue". Because of the severity, WordPress.org enabled forced updates through the auto-update system for sites on affected versions. There are two bugs, and they work as a chain:

  • CVE-2026-60137 (GHSA-fpp7-x2x2-2mjf): WP_Query does not properly sanitize its author__not_in parameter. On its own this is a "facilitated" SQL injection, exploitable when a plugin or theme passes untrusted input to that parameter. It was reported by TF1T, dtro and haongo. CVSS 3.1: 5.9.
  • CVE-2026-63030 (GHSA-ff9f-jf42-662q): a REST API batch-endpoint route confusion. Combined with the SQL injection, it leads to remote code execution on WordPress 6.9 and later. It was reported by Adam Kues at Assetnote / Searchlight Cyber. CVSS 3.1: 9.8 (network, low complexity, no privileges, no user interaction).

CISA added both CVEs to the KEV catalog on July 21, 2026. The KEV entry says the chain lets "an unauthenticated attacker" gain RCE "on default WordPress installations". Federal agencies had to fix CVE-2026-63030 by July 24 and CVE-2026-60137 by August 4.

Who is affected#

According to the vendor and the CVE records (NVD CVE-2026-63030, NVD CVE-2026-60137):

  • 7.0.0-7.0.1 and 6.9.0-6.9.4: both bugs, which means unauthenticated RCE. Fixed in 7.0.2 and 6.9.5.
  • 6.8.0-6.8.5: only the SQL injection, which needs a plugin or theme to pass untrusted input. Fixed in 6.8.6.
  • 7.1 beta1: both bugs. Fixed in 7.1 beta2.
  • Before 6.8: not affected.

Do you really need to act?#

For most sites the hard part already happened automatically. Forced background updates moved affected installs to the fixed release. The risk now sits with sites where that update did not land:

  • Auto-updates disabled with AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE, or managed by a deployment pipeline that overwrites core.
  • Read-only or immutable filesystems, and container images that pin wordpress:6.9/7.0 tags built before the fix.
  • Forgotten staging, marketing and microsites.

CISA classifies the chain as actively exploited and automatable. Neither WordPress nor the KEV entry discloses details about attacks, as of October 21, 2026. Any 6.9 or 7.0 site that stayed unpatched after mid-July should be treated as possibly compromised, not just out of date.

What to do now#

  1. Inventory and check: wp core version on each install, or wp site list plus a loop for multisite networks.
  2. Update anything behind: wp core update --minor (7.0.x to 7.0.2, 6.9.x to 6.9.5, 6.8.x to 6.8.6), or move to the current release.
  3. Fix the reason auto-update did not run, so the next forced security update gets through.
  4. Rebuild images from a refreshed wordpress base and redeploy them. Restarting an old container does not patch it.
  5. If you develop plugins or themes, make sure nothing passes request data unsanitized into WP_Query arguments such as author__not_in. Cast IDs with array_map('intval', ...).

How to tell if you were hit#

No official indicators of compromise have been published. Look for the usual signs of an RCE on a WordPress host. wp core verify-checksums flags modified core files. wp user list --role=administrator shows admins you did not create. New PHP files in wp-content/uploads, mu-plugins or plugin folders, and unexpected outbound connections or child processes from the PHP-FPM or web server user, are strong signals. Because the chain goes through the REST batch endpoint, review access logs for unusual POSTs to /wp-json/batch/v1 or ?rest_route=/batch/v1 from the period when you were on a vulnerable release. If you find anything, rebuild the site, then rotate the database password, the salts in wp-config.php and admin passwords.

Timeline#

  • — WordPress 7.0.2, 6.9.5, 6.8.6 and 7.1 beta2 are released with forced auto-updates. Both GHSAs and CVEs are published.
  • — CISA adds CVE-2026-63030 and CVE-2026-60137 to KEV.
  • — Federal due date for CVE-2026-63030 (August 4 for CVE-2026-60137).

Vulnerability records

  • CVE-2026-63030 · KEV 2026-07-21 · WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the author__not_in…
  • CVE-2026-60137 · KEV 2026-07-21 · WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. WordPress.org — WordPress 7.0.2 Security Release wordpress.org
  2. WordPress / GitHub — GHSA-ff9f-jf42-662q: REST API batch-route confusion and SQL injection leading to RCE github.com
  3. WordPress / GitHub — GHSA-fpp7-x2x2-2mjf: Facilitated SQL injection in WP_Query author__not_in github.com
  4. NVD — CVE-2026-63030 nvd.nist.gov
  5. NVD — CVE-2026-60137 nvd.nist.gov
  6. CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-63030 cisa.gov
  7. CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-60137 cisa.gov