WordPress Security Vulnerabilities Fixed in Version 7.0.2

If your WordPress site is running version 6.8 or 6.9, two formally tracked security vulnerabilities were sitting in your codebase until 17 July 2026. One of them could give an attacker the ability to run arbitrary code on your server. The other creates a path to direct database access through SQL injection. Both carry assigned CVE numbers, CVE-2026-60137 and CVE-2026-63030, which means they are logged, documented, and visible to anyone scanning for unpatched sites.

The WordPress.org security release published on 17 July 2026 addresses both vulnerabilities in version 7.0.2. For sites still running 6.9, the fix was backported to version 6.9.5. For sites on 6.8, the first vulnerability was backported to version 6.8.6. Sites running versions prior to 6.8 are not affected by either issue.

That version boundary matters. If you are unsure which version your site is running, that uncertainty is itself a risk.

Forced Auto-Updates Signal How Serious This Was

The WordPress.org team took a step they reserve for genuinely serious situations: they enabled forced updates through the auto-update system. Under normal circumstances, auto-updates for major releases are optional. Site owners and developers choose whether to enable them, and forced updates bypass that choice entirely, pushing the patch to affected sites automatically.

The decision to force this update tells you something about how the team assessed the risk. A site left on an older version without anyone actively watching it would receive the patch without any human intervention, which is a reasonable safety net, but not a substitute for knowing what is happening on your site.

Here is the practical problem: forced auto-updates work when the update mechanism itself is functioning. Sites that have been neglected, sites where plugins or server configurations have broken the update process, and sites where someone disabled auto-updates without putting a manual process in place may not have received the fix at all. If a WordPress site has not been actively managed for months, there is a real chance updates are not landing and no one would notice if they stopped.

The Business Consequence of a Compromised Site

Recovery costs tell the clearest story here. Forensic investigation, clean-up, and any required customer notification can run well beyond what routine maintenance would have cost across an entire year, and that is before accounting for the reputational damage. Customer data exposed through a database breach carries regulatory weight. Search engines detect and flag compromised sites, which can remove you from search results at precisely the point when potential customers are looking for you.

Once a CVE is published, the clock starts. The vulnerability is public, automated scanning tools probe for unpatched sites continuously, and they do not distinguish between a large business and a small one. Delaying security updates simply gives attackers more time to find you before you find the patch. The question is whether your site was updated before it was scanned.

The businesses most exposed after this release are those where no one is paying attention. A site that has been left to run without active oversight is exactly the kind of site these vulnerabilities are designed to reach, and the recovery costs make the original patch look trivial by comparison.

Here is what I recommend you do now, in order:

1. Log in to your WordPress dashboard and check the current version. It should read 7.0.2, 6.9.5, or 6.8.6 depending on the branch you are running. If it reads anything lower than those numbers, your site has not received the patch.
2. If auto-updates are enabled and the patch has been applied, confirm the update log shows the correct date. A forced update that ran successfully will appear in your site health information.
3. If you cannot confirm the version or the update log, treat the site as unpatched until someone with direct access verifies it.
4. Assign accountability. Someone needs to be responsible for checking that future security releases are applied. That person needs access, a process, and a reason to check regularly.

The version 6.8.6 documentation confirms the release date and scope for sites on the 6.8 branch. If your site is on that branch, the fix covers only the first of the two vulnerabilities, which is worth knowing before you consider the job done.

One angle that often gets missed: forced auto-updates can occasionally create compatibility problems. A plugin or theme that has not been tested against the latest WordPress version may behave unexpectedly after an automatic patch. If your site updated automatically and something is now broken, the update is still the right outcome. The breakage is a separate, manageable problem. A broken site that is secure is a better position than a functioning site with a known remote code execution vulnerability in it.

The release of WordPress 7.0.2 is evidence that the WordPress security process works. Vulnerabilities are found, assessed, patched, and pushed. The organisations that benefit from that process are the ones keeping their sites current and maintaining someone accountable for the result, while those running on autopilot face the real possibility that a forced update never landed and no one is checking either way.

---

If you are not certain your site received the 7.0.2 patch, or if you have no clear process for monitoring future security releases, I can audit your site’s update status and put a monitoring arrangement in place. Given that CVE-2026-60137 and CVE-2026-63030 are now publicly documented and actively scanned for, an unpatched site is an open target today. Contact The WordPress Guy to arrange an update audit.