Common WordPress Security Issues
By Stu 8 min read
Ask ten people what the biggest WordPress security issues are and you'll get twenty answers. Some of them are real. Some are folklore that has stuck around because it sounds plausible. Most of the compromised sites I've seen fall into a small handful of categories, and the categories are the same year after year.
This post is a ranked list of the security issues that actually cause problems on WordPress sites, from most common to least. Not the ones that make for a dramatic headline, the ones that reliably turn up in the logs of a site that just got hit.
1. Outdated plugins and themes
This one is not close. Outdated plugins are the single largest source of WordPress compromises, and it isn't a close race.
The pattern is always the same. A plugin has a vulnerability. A patch ships. The vulnerability gets published so other developers can learn from it. Automated scanners pick up the disclosure within hours and start probing every WordPress site on the internet for that plugin at that version. Any site that hasn't updated is now in the queue to be exploited.
The reason it keeps happening is not that people don't know updates matter. It's that WordPress sites accumulate plugins over years, and the site owner has usually stopped paying attention to half of them. A plugin installed to solve a one-off problem in 2021 is still active in 2026, still on version 1.4.2, and the author stopped maintaining it in 2022.
The fix is unglamorous. Keep everything updated. Uninstall anything you don't use. Review your plugin list at least once a quarter and prune it.
2. Weak, reused, or leaked admin passwords
The second largest category is credential compromise, and it hides in plain sight because a successful login looks exactly like the site owner logging in. Nothing on the server flags it. There is no attack to detect. Someone just knew the password.
Weak passwords are the obvious version. Reused passwords are the more common one. An administrator uses the same password on their WordPress site as they do on a forum that gets breached three years later. The leaked credentials end up in a wordlist that gets tried against every wp-login.php on the internet. Eventually it hits.
Two factor authentication makes this almost harmless. Even a leaked password on its own isn't enough to log in. A site with 2FA on every admin account has closed off the most common entry route to WordPress compromise, at a cost of about ten minutes of setup.
3. Weak or nonexistent login rate limiting
Related to the above, but a separate problem. wp-login.php will accept as many login attempts as you send it, from the same IP, all day long. Nothing in WordPress core stops you from trying a million passwords against an admin account.
That means brute force and credential stuffing attacks are trivially cheap. An attacker doesn't need to know your password. They can try every password on the leaked list, one after another, until something works.
The fix is any decent security plugin that limits failed logins per IP, or a server-level tool like Fail2Ban watching the access log. Either one turns a wide-open attack surface into a narrow one. The point isn't that a determined attacker can't work around rate limiting. It's that the automated bots doing 99% of these attacks won't.
4. Abandoned admin accounts
Every site has them. The developer who built the site three years ago. The freelance content editor who left in 2024. The agency that used to manage the site and still has an account "just in case". Every one of those accounts is a way in, and every one of them is being maintained (or not) by someone who no longer has any skin in the game.
If any of those old accounts has a weak password, uses 2FA on a phone the person no longer owns, or shares a password with an email account that later got breached, that's a compromise waiting to happen. And nobody notices because nobody is looking at the User list.
A quarterly review of who has admin access, and why, closes this off. If someone doesn't need access, remove them. It's fifteen seconds of work per account and it removes the account entirely from the attack surface.
5. Nulled or pirated plugins and themes
A specific case that's worth calling out on its own. Free versions of premium plugins and themes, distributed through unofficial sites, almost always ship with backdoors.
The economics make it inevitable. Someone has to fund the site handing out £200 worth of software for free, and that funding comes from selling access to the sites that install it. Every "nulled" plugin download is potentially a supply chain compromise with your site as the target.
The fix is: don't. If a plugin costs money, either pay for it or use a free alternative. There is no version of downloading a paid plugin from a third party that isn't taking a serious risk.
6. Misconfigured file permissions
Less common as a direct attack vector, more common as an accelerant. If file permissions are too loose, a small compromise becomes a big one. An attacker who finds a way to write one file can suddenly overwrite core files, drop backdoors in the theme, or modify wp-config.php.
The correct setup is directories at 755, files at 644, wp-config.php at 640 or tighter, and ownership separated so the web server user is not the file owner. On a well configured host, this is the default. On a lot of hosts, it isn't.
This one won't get you compromised on its own. It'll turn a minor problem into a full site rebuild.
7. XML-RPC left enabled
XML-RPC is a WordPress feature that lets external clients (Windows Live Writer, the WordPress mobile app, Jetpack) talk to your site. Almost nothing uses it any more, and yet on most WordPress sites it's still on, still accepting requests, still available for abuse.
The two things attackers actually do with XML-RPC are amplified brute force attacks (you can try hundreds of passwords in one request) and pingback DDoS reflection. Neither is exotic. Both show up constantly in server logs.
If you're not using Jetpack, the mobile app, or an external editor, disable XML-RPC. It's a single filter or a single nginx rule. Almost nothing legitimate needs it and its presence is a live attack surface.
8. No web application firewall
The plugins-and-passwords items above account for the majority of compromises, but a chunk of what's left is exploitation of unknown or zero-day vulnerabilities. Something in WordPress, a plugin, or a theme has a vulnerability that hasn't been publicly disclosed yet. The site owner can't patch what nobody knows about.
That's the case a WAF is for. A well configured WAF, either at the WordPress level (Wordfence) or the edge (Cloudflare), catches exploit patterns even before the specific vulnerability is known. It's not a substitute for keeping software updated. It's a second layer for the cases where updates aren't available yet.
Most sites don't run one. Most sites are fine most of the time. The ones that are fine are the ones that never had a zero-day pointed at them.
9. Backups you've never restored
Not an attack vector, but the reason a compromise becomes a total loss. Sites with backups that have never been tested regularly discover, at the worst possible moment, that the backups are incomplete, corrupted, or missing critical data.
Test your backup restore process once, on a staging environment, while nothing is on fire. That single test tells you more about your actual recovery posture than any amount of documentation.
10. Everything else combined
SQL injection through custom plugin code. Cross-site scripting in unmaintained themes. Session hijacking on sites without HTTPS. Weak database credentials. Publicly readable wp-config.php backup files (wp-config.php.bak, wp-config-old.php) left in the webroot. Debug logs left enabled with sensitive output. Directory listing left on. readme.html disclosing the WordPress version.
Any one of these can bring a site down. But collectively, they account for a small fraction of what I see in the wild. If you've closed off the top five items on this list, you've dealt with something like 80-90% of what actually gets WordPress sites hit.
What this list is really saying
The distribution of WordPress security issues is heavily skewed. A very small number of problems cause a very large share of compromises. If you had to pick three things to focus on, they'd be: keep plugins updated, use strong unique passwords with 2FA, and rate-limit login attempts. Those three alone close off the majority of realistic attacks.
Everything else on the list matters, but it matters less than most WordPress security articles imply. The exotic scenarios get more attention because they're more interesting to write about. The boring ones account for the actual incidents.
Working through them properly
Reading a list of security issues is easy. Working through each one on a live site, with the specific configuration and the reasoning behind each choice, is what actually changes the outcome.
The Protect My WP handbook walks through every item on this list, layer by layer, with the exact settings and why they matter. If this post left you unsure about any of the items above, that uncertainty is worth resolving before something forces the issue.
Get the book for £19.
Get the free WordPress Security Checklist
The security checks I'd run through on any WordPress site, delivered straight to your inbox.
Want to go deeper?
The first chapter of Protect My WP is free. Start with the foreword, then read Chapter 1 on hosting and server security. There is also a shorter guide that walks the same ground faster if you want the shape of the book first.