How WordPress Sites Actually Get Hacked (And Why It’s Rarely What You’d Expect)

Picture a hacker targeting your site. You probably imagine someone in a dark room, studying your business, probing your specific setup, looking for your particular weakness. The reality is considerably more mundane — and, in an odd way, more reassuring.

The overwhelming majority of WordPress compromises aren’t targeted at all. They’re automated. Bots scan thousands of sites simultaneously, looking for the same handful of known weaknesses. When they find one, they exploit it. Your site isn’t singled out; it just happened to have an unlocked door.

This post explains how those weaknesses are exploited: the real attack vectors, ranked by how commonly they actually occur. Understanding the mechanisms doesn’t require a technical background, and it makes the risk considerably less mysterious.

If you’re reading this because you think your site may already be compromised, start here instead: Has Your WordPress Site Been Hacked? Here’s How to Tell. This post is for understanding how it happens, not what to do when it has.

1. Outdated Plugins and Themes

This is, by some distance, the most common way WordPress sites get hacked. It has nothing to do with WordPress itself.

Here’s the mechanism: a vulnerability is discovered in a popular plugin. The plugin’s developer releases a patch. Security researchers publish details of the flaw (standard practice in the industry, since responsible disclosure pressures all affected sites to update quickly). Within hours, automated bots are scanning for sites still running the vulnerable version.

If your site hasn’t applied the update, it’s on the list.

The specific vulnerability varies. It might allow an attacker to upload files, inject malicious code into your database, or hijack admin sessions. The precise technical detail matters less than the pattern: the fix existed before the attack. The site simply hadn’t applied it.

This is why the narrative of “sophisticated hackers” doesn’t hold up for most small-business WordPress sites. The bot doesn’t care what your business does. It’s looking for version numbers. If yours matches a known-vulnerable release, that’s enough.

Themes carry the same risk, though less frequently. Premium themes updated infrequently, or abandoned free themes no longer receiving patches, are a quieter version of the same problem.

Related: What to Do When a WordPress Update Fails, because the fear of updates breaking things is often what keeps sites running outdated software.

2. Weak Passwords and Credential Attacks

The second most common entry point is also the least technical: someone gets hold of valid login credentials and walks in through the front door.

There are two main mechanisms here.

Brute-force attacks involve bots hammering /wp-login.php, WordPress’s default login URL, with thousands of username and password combinations per hour. Default WordPress installations don’t limit login attempts, so an unprotected site will simply sit there while a bot cycles through common passwords indefinitely. “admin” as a username makes this considerably easier.

Credential stuffing is subtler and increasingly common. Billions of email address and password combinations from previous data breaches are publicly available. If your WordPress admin account uses the same email and password combination you’ve used elsewhere, and that other service was ever breached, your credentials may already be on a list that bots are actively testing.

With admin access, the attacker has the run of the site.

3. Nulled and Abandoned Plugins and Themes

“Nulled” software is pirated premium plugins or themes: paid products redistributed for free on unofficial sites. They’re tempting when a plugin costs £60 and a nulled version is a free download away. The catch is that the licence-enforcement code has been stripped out and, in most cases, replaced with something else: a backdoor, a malware dropper, or a script that quietly phones home to an attacker’s server the moment it’s activated.

This isn’t a risk you can audit your way around. The malicious code is intentional and often obfuscated. You’ve installed the attack yourself.

Abandoned plugins are a separate but related problem. A plugin that was legitimate and well-maintained five years ago may now have no active developer, no security patches, and known unaddressed vulnerabilities. It still works, until it doesn’t. WordPress’s plugin repository flags plugins that haven’t been updated in over two years, but the flag is easy to miss, and plenty of abandoned plugins remain installed and active on sites that simply haven’t been reviewed recently.

4. Compromised Hosting and Shared-Server Contamination

Your site’s security is partly a function of where it lives. On cheap shared hosting, dozens or hundreds of sites run on the same server. If one of those sites is compromised, malicious code can propagate to neighbouring accounts on the same server. Those sites need not have any exploitable weakness of their own.

This is less common than vectors 1–3, and it’s one the site owner has no direct control over once it occurs. The hosting environment’s isolation between accounts, its server-level software maintenance, and its monitoring are all outside your hands.

Outdated server software compounds this: a host running old versions of PHP, MySQL, or the underlying OS may itself carry unpatched vulnerabilities that an attacker exploits at the infrastructure level rather than the site level.

5. Outdated PHP and WordPress Core

Worth including, but honest about where it sits in the frequency ranking. It sits lower than most security content implies.

WordPress core is one of the most scrutinised codebases in open-source software. Critical vulnerabilities are rare, patches arrive quickly, and auto-updates for minor releases are on by default in most installations. WordPress itself is genuinely not the usual problem.

PHP is a more meaningful concern, though the mechanism is indirect. Unsupported PHP versions (anything below 8.1 at the time of writing) no longer receive security patches. A vulnerability discovered in an end-of-life PHP version simply stays open. Sites running old PHP aren’t exploited through PHP itself very often, but the exposure exists and grows over time.

Keeping PHP and WordPress core current closes a real, if modest, attack surface. It’s also the lowest-effort maintenance task on this list.

6. Supply-Chain Compromises and Third-Party Scripts

The least common vector for small sites, and the one least within an owner’s control: a legitimate plugin, theme, or third-party service that itself gets compromised at source.

This has happened. Plugin developers’ accounts have been hijacked; a malicious update pushed through official channels; sites that had done everything right received malware via a trusted automatic update. Third-party scripts loaded from external CDNs carry a version of the same risk. If the script’s host is compromised, every site loading it is affected.

For most small WordPress sites, this is a background risk rather than a primary concern. Worth knowing about; it doesn’t warrant the same attention as vectors 1–3.

Why Almost All of This Is Preventable

Look at the list above and a pattern emerges. Outdated plugins: patchable. Weak credentials: fixable. Nulled software: entirely self-inflicted. Poor hosting: a choice. Outdated PHP: a configuration change.

Only the last vector involves an attacker doing something genuinely difficult, and it’s also the rarest. Everything else exploits neglect: known vulnerabilities left unpatched, default configurations left unchanged, convenience chosen over basic hygiene.

This matters because it shifts the frame from “hacking is something that happens to you” to “most of these gaps are ones you can close.” The sites that get compromised most often aren’t unlucky. They’re unattended.

That’s not a comfortable truth if your site has been running on autopilot. But it is a useful one — and it’s worth taking further than this post does. We’ve written a fuller, honest answer to the question this naturally raises: is WordPress actually secure as a platform, or is “unattended” doing all the work?

What to Do With This

If you’ve read this far, you now understand where the real risks are and roughly how common each one is. The next question is either “has any of this already happened to me” or “how do I make sure it doesn’t.”

For the first: Has Your WordPress Site Been Hacked? Here’s How to Tell walks through how to identify the signs of a compromise and what to do if you find them.

For the second: keeping plugins, themes, PHP, and core updated — ideally via a staging site so updates are tested before they go live — and using strong, unique credentials, closes the door on the vast majority of attacks described here. If you’d rather have that handled as a matter of routine rather than a recurring task on your list, our WordPress care plans cover ongoing monitoring and hardening as a matter of routine.

Either way, you’re now better placed to have a realistic conversation about what your site actually needs, which is usually less dramatic, and more straightforward, than most security content would have you believe.