How WordPress Sites Actually Get Hacked (and How to Prevent It)

Part of my work is malware removal and security hardening, which means I regularly get called in after a site has been compromised. The interesting thing is how predictable these incidents are. It’s almost never a sophisticated attack. It’s the same handful of doors left open, over and over.

Here’s what actually happens – and what would have prevented it.

The real attack vectors

Outdated plugins with known vulnerabilities

This is the cause of the overwhelming majority of compromises I clean up. A vulnerability gets disclosed in a popular plugin, a patch is released, and within days automated bots are scanning the entire internet for sites that haven’t updated yet. They don’t target you – they target the version number.

Prevention: Enable auto-updates for plugins, or at minimum update within days of a release, not months. If a plugin has been abandoned by its author, replace it – no updates means no patches.

Weak or reused admin passwords

Credential-stuffing bots try username/password combinations leaked from other breaches. If your WordPress admin password is the same one you used on a forum in 2015, assume it’s already in a list somewhere.

Prevention: Unique, generated passwords and two-factor authentication on every administrator account. 2FA alone stops this entire attack class.

Nulled themes and plugins

“Free” copies of premium plugins downloaded from shady sites very often ship with a backdoor already inside. I’ve cleaned sites where the malware was installed by the owner themselves, bundled inside a pirated page builder.

Prevention: Only install from the official repository or directly from the developer. A $59 license is cheaper than a cleanup.

Compromised hosting neighbors

On poorly isolated shared hosting, one infected site can spread to every other site on the same account. If you host ten sites under one account and one gets hacked, expect ten cleanups.

Prevention: Proper isolation between sites – separate accounts, or better, a properly configured server where each site runs as its own user.

The hardening baseline I apply to every site

Beyond fixing the vectors above, this is my standard checklist:

1. Disable file editing in the dashboard. If an attacker gets an admin session, don’t hand them a code editor:

    define( 'DISALLOW_FILE_EDIT', true );

2. Limit login attempts and rename or protect wp-login.php from brute force at the server level.
3. Correct file permissions — directories 755, files 644, and wp-config.php locked down tighter.
4. Keep PHP current. Old PHP versions stop receiving security patches. Anything below PHP 8.1 in 2026 is a liability.
5. Off-site backups, tested. A backup stored on the same server as the site disappears with the site. And a backup you’ve never test-restored is a hope, not a backup.
6. Principle of least privilege. Content editors don’t need administrator accounts. Most sites I audit have 2–3 admins who only ever write posts.

What a security plugin can and can’t do

Security plugins are useful – malware scanning, login protection, and file integrity monitoring all have value. But a plugin running inside WordPress can’t fully protect WordPress. It runs at the same level as the thing it’s guarding.

Real defense is layered: server-level firewall rules, isolation, updates, strong authentication — with a security plugin as one layer among several, not the whole strategy.

If you’ve already been hacked

Quick triage order: take the site offline or behind maintenance mode, change every password (WordPress, hosting, database, FTP), restore from a clean backup if you have one, and if you don’t – get a professional cleanup. Simply deleting the visible malware almost never removes the backdoors that let the attacker back in a week later.