On July 17, WordPress pushed out an emergency patch. Not because a feature broke, but because someone could walk into a huge number of WordPress sites with no username, no password, and no warning, and take the whole thing over.
If you run a WordPress site, or you’re responsible for one on a client’s behalf, July 2026 is worth twenty minutes of your attention. Here’s what actually happened, what it looks like when it goes wrong, and exactly what to do about it before you close this tab.
The bug that started it
WordPress 7.0.2 fixed two flaws that, on their own, aren’t the end of the world. Chained together, they are. One was a logic flaw in how the REST API handles batch requests (CVE-2026-63030), which let a request pretend to be something it wasn’t. The other was a SQL injection sitting quietly in core (CVE-2026-60137). Neither needed a username or password to trigger. Put them together and an attacker with no account on your site at all could get their own code running on your server, with the same access as an administrator.
Researchers nicknamed the chain “wp2shell,” which tells you exactly how it ends if you’re not patched: someone gets a shell on your server, meaning they can run commands on it directly, the same as if they were sitting at the keyboard.
The affected range was wide: any site on WordPress 6.8 through 7.0.1. Fixes shipped in 6.8.6, 6.9.5, and 7.0.2, depending on which branch a site was on.
This wasn’t a theoretical risk
Four days after the patch went out, the US Cybersecurity and Infrastructure Security Agency added it to their Known Exploited Vulnerabilities list. That list is reserved for bugs being used in real attacks, not hypothetical ones. WordPress.org went as far as force-pushing the fix through auto-update, because waiting for site owners to click “update” themselves wasn’t going to be fast enough.
So if a site you’re responsible for was sitting on an affected version through mid-July, that’s not a maintenance backlog you can get to next month. That’s a door that was left open while people were actively trying the handle.
And it wasn’t just core
Core got the headline, but the week of July 17 to 24 alone saw 93 separate vulnerabilities disclosed across WordPress core, plugins, and themes, including issues in Yoast SEO and BuddyPress. Neither of those is some obscure plugin nobody’s heard of, and that’s the actual point: even well-maintained, popular plugins ship bugs. If a site runs a dozen plugins, which most do, the odds that at least one of them shipped a patch that’s still sitting there uninstalled aren’t small.
The one that worries us more
Here’s the part that should bother you more than the headline bug. Researchers also flagged a backdoor campaign this month hiding inside the /wp-content/mu-plugins/ folder. Must-use plugins load automatically in the background and don’t show up in your normal Plugins screen in the dashboard, which makes that folder a genuinely good place to hide something. A site could be compromised right now, patched and looking perfectly fine on the surface, and the owner would never see it, because there’s never been a reason to go looking in that particular folder.
What this actually looks like when it goes wrong
“Security vulnerability” sounds abstract until it’s your site. Here’s what it turns into in practice.
An online store running an older install gets in through exactly this kind of chained bug. The attacker doesn’t deface the homepage, they’re rarely that obvious. They quietly add a script to the checkout page that copies card details before they’re encrypted. Nobody notices until customers start disputing charges weeks later, and by then the store’s already lost the trust of everyone who shopped in that window.
For a service business, the damage shows up differently but costs just as much. A hidden backdoor lets someone use your server to send spam email at scale, thousands of messages a day, all leaving from your domain. Your own business emails, the invoices and proposals you’re sending to prospects, start landing in spam because your domain’s reputation has quietly tanked. You won’t get an alert for this. You’ll notice when a client mentions, for the second time, that your email never arrived.
And for almost anyone running a site, there’s Google. A compromised site is often used to inject spam links or silent redirects to malware. Google usually finds it before you do, and your site gets hit with a red warning screen in search results and in Chrome. Clearing that flag once you’ve cleaned the malware is the easy part. Getting back the search ranking you lost while the flag was up takes months, not days.
What to actually do about it
If you manage your own WordPress site, here’s the real list, not just “keep it updated”:
- Log into wp-admin and confirm your WordPress version is 6.8.6, 6.9.5, 7.0.2, or newer. If it isn’t, update core first, before touching anything else.
- Update every plugin and theme showing a pending update, not just the ones whose names you recognise.
- Open
/wp-content/mu-plugins/through FTP or your hosting file manager and look at what’s actually sitting in there. If you don’t remember installing something, that’s worth investigating before you assume it’s fine. - Check Users > All Users for any account you don’t recognise, especially ones added in the last few weeks.
- If you have any reason to think the site was already compromised, a plugin update alone won’t fix it. You need a malware scan, and if it comes back dirty, a restore from a clean backup taken before the infection, not just a cleanup on top of it.
- Force a password reset for every admin account, and while you’re in there, rotate the secret keys and salts in
wp-config.php.
Each of those takes a few minutes on its own. Doing all of them, correctly, every time a patch ships, month after month, on top of actually running your business, is the part that’s genuinely hard to keep up with.
Why this is really a maintenance problem
A bug like wp2shell has a window: the days between when it’s disclosed and when every affected site has actually patched. Attackers move fast in that window precisely because they know most site owners don’t. That’s the whole game.
A maintenance plan exists to close that window. Patches get applied within days, sometimes hours, instead of whenever you next happen to think about it. Someone is actually looking at file changes and the admin user list on a schedule, so a backdoor sitting in the mu-plugins folder gets caught in week one, not month three. And when something does go wrong, a clean, tested backup means the fix is a restore, not a scramble.
That’s what our WordPress maintenance plans do: patching, monitoring, and backups you can actually restore from, so the twenty-minute job doesn’t get skipped for six months and turn into a very different kind of week.
A patched site costs you twenty minutes. An unpatched one can cost you the conversation where you explain to a customer why their data ended up somewhere it shouldn’t have.
