WordPress core itself has a strong security track record — the WordPress security team is fast, and core updates for anything serious tend to ship quickly. Almost every WordPress compromise we get called in to clean up traces back somewhere else entirely: a plugin, a theme, or an update that was never applied. Here’s where the real risk actually sits.
The Plugin Ecosystem Is the Real Attack Surface
WordPress’s biggest strength — an enormous plugin ecosystem covering almost any feature you could want — is also its biggest security liability. Every plugin is code written and maintained by a different team, at a different standard, on a different update schedule. A well-maintained site with fifteen active plugins has fifteen separate pieces of software that each need watching, not one.
The practical risk isn’t usually a zero-day in a major plugin — it’s an abandoned or infrequently updated plugin sitting quietly on a live site, doing its job right up until a known vulnerability in it becomes public.
Core Updates Are the Easy Part
WordPress can auto-update itself for minor releases, and that’s generally safe to leave switched on. Major core updates and, more importantly, plugin and theme updates are where things go wrong — not because the update itself is insecure, but because of the opposite problem: updates get delayed because nobody wants to risk breaking something that’s currently working.
That hesitation is understandable and also exactly how sites end up running months-old, publicly known vulnerable versions of something. An update you’re afraid to apply is a security decision, whether or not it feels like one.
wp-admin Is a Target Whether or Not You Think of It That Way
/wp-login.php gets hit by automated brute-force attempts constantly, on every WordPress site on the internet, regardless of size or profile. Weak or reused admin passwords, no rate limiting, and no two-factor authentication turn a background noise problem into an actual breach. This is one of the cheapest risks to close off and one of the most commonly left open.
What Actually Prevents This, in Practice
- Test before you deploy. A staging environment that mirrors production means a plugin or core update can be checked before it reaches the live site — which removes the main reason updates get delayed in the first place.
- Back up before every update, not just on a schedule. If something does break, the fix is a five-minute rollback instead of an emergency.
- Prune what you don’t use. A deactivated-but-still-installed plugin can still be a vulnerable target. If it’s not doing anything, remove it.
- Treat wp-admin like the login page it is. Strong, unique credentials and two-factor authentication close off the most common and least sophisticated attack vector.
- Have someone actually watching, not just installed software hoping to catch it. Automated scanning helps, but knowing when to apply an update — and having tested it first — is what keeps a site both current and stable.
Why This Is a Hosting Conversation as Much as a WordPress One
This is exactly why our managed WordPress hosting plans exist as more than server space — updates, patching and monitoring happen as standard, with a staging step in the process rather than updates going straight to a live site untested. If you’re managing this yourself and it’s starting to feel like a part-time job, that’s a reasonable sign it’s time to hand it off. Get in touch if you’d rather this wasn’t something you had to think about.