Last week was a long one. If you run a WordPress site and you felt a little jolt of panic when the security news started going around – yeah, you weren’t imagining it. A nasty core vulnerability got out, it got used fast, and a lot of small business sites got caught with their pants down.
We had two of our own maintenance sites get hit. Out of about 80. We’ll get to how that happened, because honestly it taught us something.
Here’s the whole story – what actually broke, why the “it auto-updates, I’m fine” thing didn’t save everyone, and what you should do so your site isn’t the next one getting cleaned up at 11pm.
What actually happened
Short version: a flaw in a recent WordPress core release let an attacker do things they had no business doing. Without logging in. That’s the part that makes these scary – no password needed, no admin account, nothing. The vulnerable code accepted input it should have rejected, and that gap was enough to let someone slip instructions through the front door.
In plain terms? An unauthenticated attacker could get a foothold. From there it’s the usual ugly playlist – injected spam, hidden redirects to sketchy pharma and casino pages, backdoor files tucked into your uploads folder so they can come back even after you think you’ve cleaned up.
The fix landed in the next patch release pretty quickly, to be fair. The WordPress security team moved fast. But “a patch exists” and “your site actually got the patch” are two very different things, and that gap is where most of the damage lived.
How fast it got used
Fast. Uncomfortably fast.
This is the bit people don’t get. When a core vulnerability goes public, the technical details get published so admins can understand and defend against it. Totally reasonable. Except the bad guys read the exact same writeups. And these days they don’t even do it by hand.
Automated scanners crawl the entire internet looking for sites running the vulnerable version. They fingerprint your WordPress install, check the version number, and if it matches – they try the exploit. No human involved. We saw probe attempts in server logs within hours of the details going public. Not days. Hours.
That’s the reality now. The window between “vulnerability announced” and “bots hammering your site” used to be a few days. Now it’s basically an afternoon.
But WordPress auto-updates. So why did anyone get hit?
Great question, and it’s the one that trips everybody up.
Yes, WordPress can auto-apply security patches. It’s a genuinely good feature. But it’s not the guarantee people think it is, and here’s why it quietly fails more often than you’d expect:
- It got switched off. A plugin, a host optimization, a developer who disabled it during a project three years ago and forgot. Auto-updates get turned off constantly and nobody notices – because when they’re off, nothing happens. That’s the whole problem. Silence looks fine right up until it isn’t.
- The update tried and failed. File permissions were wrong. Disk was full. A caching layer blocked the write. The update ran, choked halfway, and rolled back – and unless someone’s actually watching, you’d never know the site is still sitting on the vulnerable version.
- The site was too far behind. WordPress won’t leap you across several major versions automatically. Sites stuck on much older releases – we’re talking the 6.9.x line, some even back on 6.8.x – just don’t get these patches pushed to them. They’re outside the auto-update comfort zone entirely. (We’ve written before about what happens if you never update WordPress – short version, this exact scenario.)
So “it updates itself” is true, sort of, on a good day, if nothing’s broken. That’s a lot of ifs to bet your business on.
How we got hit (and yeah, we’re telling you)
Two sites. Out of roughly 80 on our maintenance plan. Both got compromised before the patch reached them.
What went wrong? On both of those sites the automatic update silently failed – a file permission issue on one, left over from a hosting migration that had happened months earlier, and a stubborn caching setup on the other that kept serving old files and blocked the update from completing. The update thought it was running. It wasn’t finishing. Classic.
Here’s the thing though – because these were maintenance sites, we were monitoring them. We caught both within the same window, cleaned them, patched them properly, and had them back up and running in a couple hours. Not days. Hours. The client on one of them didn’t even notice anything happened until we told them afterward.
That’s the difference monitoring makes. The vulnerability still got them – no system is perfect, and anyone who tells you their setup is 100% bulletproof is selling something. But getting hit and being back online before lunch is a completely different story than getting hit and finding out two weeks later when Google flags your site as dangerous.
And then the phone started ringing. We got seven more requests that week from businesses who weren’t on any maintenance plan. Some were running seriously old versions – a few on the 6.9.0-6.9.4 range, a couple even further back on 6.8.0-6.8.5. Those took longer. When a site’s been neglected, the cleanup isn’t just “remove the bad file” – it’s hunting down every backdoor, checking the database, resetting credentials, making sure nothing’s hiding to reinfect later. We got them all sorted within a few days, but it was a slog. Way more stress than it needed to be.
What actually protects you
Not vibes. Not hoping. Here’s the real list:
- Know your version – actually know it. Don’t assume auto-updates are on. Log in, check, or have someone check for you. “I think it updates itself” is not a security strategy.
- Real backups, stored somewhere else. A backup sitting on the same server that got hacked isn’t a backup, it’s a hostage. You want copies off-site, taken regularly, that you’ve actually tested restoring at least once.
- Someone watching. Monitoring is the whole game. The two sites we caught early? Caught because something was looking. The seven that came to us late? Nobody was.
- Patch fast, don’t wait. When a security release drops, the clock is already running. Same-day, not “I’ll get to it next month.”
- Don’t run ancient versions. If you’re several major versions behind, you’re not just missing features – you’re missing every security fix since then. That’s a stack of open doors.
Most of this isn’t hard. It’s just easy to ignore because nothing bad is happening… until it very suddenly is. That’s exactly the trap.
Is this going to keep happening?
Yes. Almost certainly. And probably more often.
Not because WordPress is bad – it runs a huge chunk of the web and the security team is genuinely good. It’s just that any software this widespread is a giant target. Find one flaw, and you’ve got millions of potential sites to try it on. The math is irresistible if you’re a criminal.
And AI is pouring gasoline on it. Attackers now use AI to read vulnerability disclosures, write working exploit code, and scan the whole internet faster than ever. The skill barrier that used to keep casual attackers out? Gone. Someone who couldn’t have pulled this off two years ago can now point a tool at the problem and let it work. That afternoon-long window between disclosure and attack is only getting shorter.
So no, this wasn’t a one-off. It’s the new normal. The question isn’t whether another one’s coming. It’s whether your site is being watched when it does.
So what should you actually do?
If you’ve got someone handling your site already – great, ask them straight up: are auto-updates confirmed working, and are we monitored? Make them show you, don’t just take “yep, all good.”
If nobody’s watching your site right now, that’s the gap. And it’s a gap that stays invisible right up until the day it costs you. Our website maintenance service exists for exactly this – we keep versions patched, run real off-site backups, and actually watch for trouble so a bad week like this one turns into a two-hour fix instead of a two-week nightmare.
And if you’re reading this because your site’s already acting weird – random redirects, Google warnings, stuff you didn’t put there – don’t wait and hope it clears up. It won’t. If you’re not sure what to look for, here’s how to spot the signs your WordPress site has been hacked. We do hacked site cleanup and recovery, and the sooner we look, the less there is to untangle.
Look, getting hacked isn’t always a sign you did something dumb. Sometimes the exploit just moves faster than the patch. But getting hacked and having nobody notice for two weeks? That part’s preventable. Every single time.