This Time It Wasn't a Plugin

The advice has been the same for years. Keep your plugins few, keep them updated, stick to the ones with a real team behind them (The Seven Plugins You Need Before You've Even Started sets out the short list I would start from). It is good advice and I have given it plenty of times. None of it helped this time, because the hole was in WordPress itself.

What happened

Two flaws were chained together to give an attacker complete control of a site without ever logging in. CVE-2026-63030 was a confusion in how WordPress handles a feature that bundles several instructions into one request. That feature is part of WordPress itself, switched on by default, and it was the way in. CVE-2026-60137 was a SQL injection, meaning the site could be made to run database commands it was never meant to run. Chained, they let an attacker forge an administrator account and run code on the server.

Nothing to install, nothing misconfigured, nothing anyone did wrong.

The affected versions are the part worth reading twice, because it is not one clean answer. The full chain hit 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1, fixed in 6.9.5 and 7.0.2. The SQL injection on its own reaches further back, to 6.8.0 through 6.8.5, fixed in 6.8.6.

So if you are on the 6.8 line and took from the headlines that this did not apply to you, look again. Not the full takeover, but a flaw that needed patching all the same. Most of the coverage led with the version numbers for the chain, not the ones for the injection.

The part that should worry you is the timing

The flaws were disclosed on 17 July. Probing started that evening at 23:29 UTC, and the first attempts to use them followed thirteen minutes later. Webshells and rogue plugins, the things attackers leave behind so they can return, turned up within days.

Thirteen minutes. Not thirteen hours, not overnight. That is not a gap any human maintenance schedule fits inside.

It landed on nearly everyone at once, which is what a core flaw does. Everybody is running the same thing, so there is no version of this where it is somebody else's problem.

It was not new, it was newly public

There is a distinction the timeline hides, and it matters more than the thirteen minutes does. Three dates are involved, not one.

The hole existed from the moment 6.9.0 shipped. Every site on an affected version had been running it, unlocked, for as long as those versions had been out. It was found this July by a security researcher and made public the same month. Those two dates made the news. The first one never does.

Whether anybody else found it earlier and said nothing, no one can tell you.

So disclosure did not create the risk. It published the address. Which is why acting when you hear about something is not a plan, because it only covers the stretch after someone else spoke up.

Six in eleven thousand

This does not prove WordPress is a bad choice. Patchstack logged 11,334 WordPress vulnerabilities in 2025. Six were in core. Six. The rest were overwhelmingly in plugins and themes, which is exactly why the standard advice exists and why it is usually right.

WordPress also patched fast and forced the update out to affected sites, which is the correct response and not something every platform manages.

So the argument is not about competence. It is about surface area. Every piece of software you run is a thing that can be disclosed, and the more of them you run, the more often you are in somebody's blast radius. That is the argument underneath What “Platform Agnostic” Actually Means. Core flaws are rare and arrive everywhere at once. Plugin flaws are common and arrive in smaller doses. Neither is a reason to panic. Both are reasons to know what you are running.

The same goes for our own CMS. Fewer moving parts is a better bet, not an immunity. Anyone who tells you their platform could never have an equivalent flaw is selling something.

If you run WordPress, do this today

Check your version. Below 6.9.5, below 7.0.2 on the newer line, or below 6.8.6 on the older one, and you were exposed. Update today.

Then check whether anyone came through before you closed it, because updating does not tell you that. There is a separate piece on how to do that check, and it takes an afternoon.

The question underneath is simpler. If you cannot say, right now, what version your site is running and when it was last updated, that is the actual problem. The flaw just made it visible.

If you would rather someone else kept track of what your site is running and when it was last patched, that is a large part of what we do. Get in touch and we will take a look at where yours stands.