WordPress 7.0.2 Patches Critical Security Flaws

This is not a routine maintenance drop. WordPress 7.0.2 exists to close two server-side security holes, one of which can lead to remote code execution, and the project has taken the unusual step of pushing the update to affected sites automatically rather than waiting for administrators to click through. If you run or manage a WordPress site, the practical takeaway is simple: confirm that every install you are responsible for is on a patched version today.

Coming just over a week after the 7.0.1 maintenance release, 7.0.2 is a reminder that security releases arrive on their own schedule and rarely at a convenient time. The good news is that the fix is narrow, the update path is well understood, and for most sites the work is verification rather than intervention.

How it works

The release addresses two separate vulnerabilities. The first is a facilitated SQL injection issue, where crafted input can reach the database layer in a way that lets an attacker read or alter data they should not be able to touch. The second, and more serious, is a REST API batch-route confusion combined with SQL injection that can be chained into remote code execution, meaning an attacker could run their own code on the underlying server rather than simply querying the database.

The REST API is the interface WordPress exposes for structured requests, used by the block editor, headless front ends, mobile apps, and countless plugins. Batch routes let a single request bundle several operations together. The vulnerability stems from confusion in how those batched routes were resolved, which opened a path to the injection. Because the REST API is enabled by default and reachable without a logged-in session on many endpoints, issues in this layer carry a wide blast radius.

Both fixes have been backported to the older branches that share the affected code. WordPress 6.9 was vulnerable to both issues and is corrected in 6.9.5. WordPress 6.8 was vulnerable to the first issue only and is corrected in 6.8.6. The 7.1 beta, still in testing, was affected by both and is corrected in 7.1 beta2. Anything earlier than 6.8 is not affected. The two issues are tracked publicly as CVE-2026-60137 and CVE-2026-63030, with matching GitHub Security Advisory identifiers.

Given the severity, the WordPress.org team enabled forced updates through the automatic background update system. Sites that support background updates will move to the patched version without any action from the administrator, which is how the project contains a widely exploitable flaw across millions of installs quickly.

What it looks like in practice

For a single well-maintained site on managed hosting, the most likely outcome is that nothing appears to happen. The background updater applies 7.0.2 quietly, and the first time an owner notices is when the dashboard footer reads 7.0.2 or the update history logs the release. That is the system working as designed.

The sites that need attention are the ones that sit outside that happy path. An install where automatic updates were disabled to prevent a fragile plugin from breaking will not receive the fix on its own. A site parked on an older branch, say a 6.8 install that was never moved forward, needs to be on 6.8.6. A staging or development copy that mirrors production but is excluded from the update routine can quietly remain vulnerable while the live site is patched, which matters if that copy is publicly reachable.

For anyone managing a portfolio of WordPress sites, this release is a prompt to run a version audit across the whole estate rather than trusting that automation caught everything. The gap between assuming every site updated and confirming it is exactly where an exploitable install hides.

What this means for UK site owners and agencies

A remote code execution vulnerability in WordPress core is close to a worst case for a site owner, because it can hand an attacker control of the server rather than just the content. Compromised WordPress sites are routinely used to serve malware, inject spam links, harvest customer data, or pivot into other systems on shared hosting. For a UK business, the fallout can include a Google Safe Browsing warning on the domain, a manual action in Search Console, loss of customer trust, and in cases involving personal data, obligations under UK GDPR.

The immediate action is verification. Confirm that every WordPress property you own or manage is on 7.0.2, or on 6.9.5 or 6.8.6 if it is held on an older branch for a specific reason. If a site is still on a vulnerable version because automatic updates were switched off, update it now and then work out how to keep it current safely, rather than leaving updates disabled indefinitely.

This is also a reminder that a WordPress site is only as secure as its maintenance routine. A well-built and actively maintained site applies security releases within hours and recovers cleanly if something does go wrong, which is a core part of how we approach web design and build for the businesses we work with. Security incidents also carry an SEO cost when a hacked site loses rankings or picks up a manual penalty, so keeping core patched is as much a visibility decision as a technical one.

Practical considerations

Do not disable automatic background updates as a general policy. Turning them off is the single most common reason a site misses a critical fix like this one. If a specific plugin or theme conflict forces you to hold updates, treat that as a fault to resolve, not a permanent setting, and monitor the affected site manually until it is fixed. Guidance on configuring background updates safely is documented in the official WordPress documentation.

After the update lands, confirm the version rather than assuming. Check the dashboard footer or the Updates screen, and for larger estates verify in bulk through your host or management tool. If a site was already compromised before the patch, updating core closes the hole but does not remove any malware or backdoors an attacker may have already placed, so a site that showed signs of compromise should be scanned and cleaned, not just updated.

FAQ