WordPress 7.0.2 fixes a critical RCE: check your site today

WordPress pushed an out-of-band security release on July 17, 2026, and the severity is the kind that ends weekends. WordPress 7.0.2 patches two flaws, one of them critical: a REST API batch-route confusion bug that chains SQL injection into remote code execution. If your business runs on WordPress — and for small businesses, it usually does — this is the rare case where the project turned on forced updates for you. That doesn't mean you're patched. It means you should go check.

What actually happened

Per the official WordPress 7.0.2 release post, two vulnerabilities were fixed:

• CVE-2026-63030 (critical) — REST API batch-route confusion plus SQL injection, leading to remote code execution. Reported by Adam Kues at Assetnote/Searchlight Cyber.
• CVE-2026-60137 (high) — a SQL injection issue, reported by TF1T, dtro, and haongo.

Backports shipped the same day: 6.9.5, 6.8.6, and 7.1 beta2. WordPress 6.8 and later are affected — 6.9 and 7.0 catch both bugs, 6.8 catches only the SQL injection. Anything older than 6.8 is untouched by these two.

The detail worth pausing on: the WordPress team enabled forced updates through the auto-update system for sites on affected versions. They don't do that casually. Help Net Security notes an interim mitigation for anyone who can't update immediately — block anonymous access to the batch API endpoint. We haven't seen confirmed reports of exploitation in the wild yet, but a critical RCE in the world's most-deployed CMS has a short quiet period.

Why it matters for your business

"Forced auto-update" sounds like the problem solved itself. It frequently doesn't. Auto-updates fail on the exact sites most likely to be running unpatched: installs with DISALLOW_FILE_MODS set, sites deployed from git or a container image where the filesystem is read-only, managed hosts that gate core updates behind their own release train, and anything where a previous update broke a plugin and somebody quietly disabled the mechanism. The sites that need the patch most are disproportionately the ones the patch can't reach.

So verify instead of assuming. Log into wp-admin and confirm the version string reads 7.0.2, 6.9.5, or 6.8.6. If you deploy WordPress as an artifact, bump the version in your build and ship it. If a managed host owns your core updates, ask them today for their timeline in writing — "we handle updates" is not a patch status.

The broader lesson is the same one that keeps showing up: the CMS running your storefront or lead-gen site is infrastructure, not decoration. It needs a version you can state from memory, an update path you've actually tested, and a name attached to who checks.

Sources: WordPress.org — WordPress 7.0.2 Release, Help Net Security — Two new high severity WordPress vulnerabilities.