The Plugin You Forgot About Is the One That Gets You
Nobody hacked the site. A tool that was supposed to help it was quietly corrupting the database — and the only reason anyone caught it was a review that was already on the calendar.
A site I look after started getting slow. Not dramatically slow. Pages took an extra beat, the admin dashboard hesitated before loading. The kind of slow you notice on a Tuesday and shrug at.
It turned out to be a database optimization plugin. A well-known one. Installed years earlier for a perfectly good reason, still active, still running its scheduled cleanup jobs — and getting them wrong. It had been mangling table operations for weeks.
No alert fired. The host didn’t flag it. The security scanner didn’t care, because nothing about it was malicious. A trusted tool was simply failing, quietly, in the dark, doing damage that would have been a genuine emergency in another month.
I found it because I run a plugin review on a schedule, and that quarter’s review happened to land at the right moment. That’s not skill. That’s process. And process is the part almost nobody has.
Most WordPress disasters aren’t attacks. They’re neglect that finally came due.
The numbers are uglier than most people realize
Patchstack’s 2026 report counted 11,334 newly disclosed vulnerabilities across the WordPress ecosystem in 2025 — a 42 percent jump over the previous year. Ninety-one percent of them were in plugins, not in WordPress itself. Core had a handful, all low risk.
Two other figures matter more than the headline number. Roughly 46 percent of those vulnerabilities had no patch available on the day they were made public, which means the responsible move — update immediately — didn’t exist as an option. And about half of the high-impact ones get exploited within 24 hours of disclosure.
WordPress core is solid. It has been for years. The risk lives in the twenty-odd plugins bolted onto it, and in the fact that most site owners couldn’t tell you what half of them do.
“But I have auto-updates turned on”
Good. Genuinely. That covers maybe half the problem, which is more than most sites have going for them. But auto-updates only work on plugins that are actively maintained and that actually ship a fix. They do nothing for the four situations that cause the most damage:
- The abandoned plugin. Last updated in 2023, developer moved on, still sitting there active on your site. No update is coming, so auto-update has nothing to do.
- The pulled plugin. Removed from the WordPress.org repository over an unpatched issue. Your site keeps running it and never says a word.
- The plugin that isn’t broken, exactly. It’s working as designed and the design is wrong for your setup. That’s the database story above. No CVE, no alert, real damage.
- The one you installed for one job in 2022. The job ended. The plugin didn’t.
The quarterly review, in about forty minutes
This is the whole thing. It isn’t clever and it doesn’t require tooling you don’t have. It requires that it actually happens, four times a year, whether or not anything looks wrong.
- Write down every plugin. A spreadsheet is fine. Name, version, what it does, who asked for it. If you can’t answer the last two, that’s your finding right there.
- Check the pulse on each one. Open its WordPress.org page. Look at “last updated” and the support forum. Anything untouched in twelve months goes on the watch list. Anything with a dead 404 for a plugin page goes straight on the kill list — that plugin has been pulled.
- Ask what breaks if it’s gone. Not “what does it do” — what actually breaks. Half the time the honest answer is nothing, and you’ve just found free security.
- Look for overlap. Two caching plugins, two SEO plugins, three form plugins from three different eras of the site. Overlap is normal on any site older than a few years, and it’s usually where the conflicts hide.
- Test the kill list on staging first. Always. Deactivate the candidates on a copy, click through the site like a visitor, check the forms, check checkout if you have one.
- Then delete — don’t just deactivate. Deactivating leaves the code sitting on your server. It stops running in the normal flow, but the files are still there, still reachable, still yours to maintain. Delete means gone.
Three things you can do this week
Open Plugins → Installed Plugins and count them. If you’re north of twenty-five, you have an inventory problem before you have a security problem, and the two are the same problem eventually.
Click “View details” on five you don’t recognize. You’ll find at least one that hasn’t been touched in years. That’s your starting point.
Then put the review on the calendar. Four recurring appointments, one per quarter, forty-five minutes each. That’s three hours a year standing between your site and the bad Tuesday.
This is the kind of thing we handle on the sites we maintain — a scheduled review, a staging environment to test against, and someone whose job it is to notice when a trusted tool starts misbehaving. Most sites don’t have that, and most of the time it doesn’t matter. Until the Tuesday it does.
“The fastest security fix in WordPress isn’t a plugin. It’s the delete button.”
Coastal Digital runs quarterly plugin reviews, staging tests, and ongoing maintenance for small businesses and nonprofits in Hampton Roads and beyond. If nobody currently owns this on your site, that’s worth a conversation.
