A critical WordPress flaw. What it means for your site

On 17 July 2026 the WordPress team shipped version 7.0.2. It is an emergency release: it patches two security flaws, one of them rated critical. Given the severity, the update was pushed automatically to sites that have background updates switched on.

The detail that matters most here: both flaws sit in the WordPress core itself. Not in a theme, not in a plugin. A clean installation with no additional plugins at all was exactly as vulnerable as a site running forty of them.

What was actually patched

CVE-2026-63030, critical. A REST API bug: batch-route confusion combined with SQL injection. It allows arbitrary code to be run on the server hosting the site, with no login and no permissions of any kind. Reported by Adam Kues of Assetnote, part of Searchlight Cyber.

CVE-2026-60137, high. SQL injection, meaning access to the contents of the site's database. Also without logging in. Reported jointly by TF1T, dtro and haongo.

That "without logging in" is why the first one is rated critical. You do not need to be a signed-in editor, you do not need a stolen password, and nobody has to click anything. The site simply has to be publicly reachable.

Does it affect your site

It comes down to the version number. The fixed releases are:

• 7.0.2 – the current release, contains both fixes
• 6.9.5 – both fixes, backported to the older branch
• 6.8.6 – the CVE-2026-60137 fix only, as the critical flaw did not affect that branch
• 7.1 beta2 – both fixes

Versions older than 6.8 are not vulnerable to either flaw. If your site runs on the 6.8, 6.9 or 7.0 branch and its number is lower than the ones above, it needs updating.

You can check the version after signing in to the WordPress admin, under Dashboard → Updates. If you do not have access, ask whoever looks after your site. It is a one-message question.

What to do now

1. Update WordPress to 7.0.2, or to 6.9.5 or 6.8.6 if you are deliberately staying on an older branch.
2. Take a backup before you change anything, and confirm it actually restores. A backup nobody has ever restored is still just a file.
3. Make sure automatic background updates are enabled. With this flaw, that was the one thing that quietly did the work for thousands of people.
4. If the site sat unpatched for several days, review the list of accounts with administrator rights and any files that appeared on the server in that window. If anything looks off, bring in someone who does this for a living.

Why this comes back every few months

WordPress runs a very large share of the web, which is precisely what makes it worth attacking. That is not a criticism of the people building it. The flaws were found, reported responsibly and patched within days, and the fix went out automatically. This is what the process is supposed to look like.

The real point is different. A WordPress site is a running application: a database, an admin panel, code executed on every visit, exposed publicly around the clock. It has to be maintained, even if you have not changed a word on it in two years.

How we do it

The sites we build do not run on WordPress. We pull the content in when the site is built and write it out as finished HTML files, so a visitor's request does not trigger database queries. The content editor itself is a hosted service, maintained and patched by its provider, rather than an application sitting on our server that we have to update ourselves.

That does not make such sites unbreakable. Nothing is, and nobody honest will promise otherwise. It only means there are fewer moving parts to look after, and that an emergency core update mid-week is not something you have to remember.

If you have a WordPress site and you are not sure who updates it, this is a good moment to find out. Whether or not we are the ones helping with it.

Sources: the WordPress 7.0.2 release announcement on wordpress.org and a write-up of the vulnerability on sekurak.pl.