The five ways WordPress sites actually get compromised

People assume "WordPress got hacked" means a flaw in WordPress. It almost never does. WordPress core is mature and patched quickly; the holes are in everything bolted onto it and around it. After cleaning a lot of compromised sites, the entry vector is nearly always one of five things.

1. A vulnerable plugin or theme

This is the big one. A plugin gains an unauthenticated vulnerability — an authentication bypass, a SQL injection, an arbitrary file upload — long after the owner stopped thinking about it. Automated scanners find affected sites within hours of disclosure and exploit them at scale.

The fix: run fewer plugins, keep every one updated, and remove anything abandoned or deactivated-but-still-installed. A deactivated plugin with a vulnerable file is still reachable. If you build for clients, a plugin and theme audit on custom code catches the issues before they ship.

2. Weak or reused admin credentials

If an administrator's password is weak, reused, or already sitting in a breach corpus, no software vulnerability is needed — the attacker simply logs in. Credential-stuffing against wp-login.php and XML-RPC runs constantly.

The fix: enforce two-factor authentication on every admin account, use unique passwords, and rate-limit or restrict login. This closes a door that no amount of plugin patching will.

3. Outdated core (and PHP)

Less common than people think, but real — especially sites frozen on an old WordPress or PHP version because a theme or plugin "needs" it. Frozen software accumulates known, public vulnerabilities.

The fix: keep core on a supported branch and PHP on a supported version. If a theme constraint is keeping you back, the answer is to fix the theme, not to stay on the old version carefully.

4. A supply-chain backdoor

Sometimes the malicious code arrives pre-installed: a "free" version of a premium plugin from a sketchy site, a theme bundled with extras, or a legitimate plugin whose developer account or update channel was compromised and pushed a backdoored release. You installed it yourself, trusting the source.

The fix: install only from the official repository or the vendor directly. Never use nulled or "free premium" downloads — they are the single most reliable way to put a backdoor on your own site. Review what an update actually changed when you can.

5. A neighbour on shared hosting

On cheap shared hosting, many sites can sit under one account or with loose permissions between accounts. One compromised site can become a launch point for the others through writable directories or a shared user.

The fix: isolate sites (separate accounts/users), lock down file permissions, and pick a host that takes tenant isolation seriously. If one of several sites you manage keeps getting reinfected, the neighbour is a prime suspect.

The pattern underneath

Four of these five have nothing to do with WordPress itself and everything to do with what surrounds it — third-party code, credentials, and the hosting environment. That's also good news: each has a boring, durable fix, and most of them are on my hardening checklist. Closing them is cheaper than cleaning the aftermath.

If you've already been compromised, start with the first hour. If you want someone to find which of these five let them in — on WordPress or on a custom application — that's what penetration testing and WordPress incident response are for.