I’ve cleaned up more hacked WordPress sites than I can count on two hands — client emergencies, agency handoffs, my own early mistakes. Almost none of them were hacked because of some exotic zero-day. They were hacked because of five boring, entirely preventable habits. Here’s what actually lets attackers in, based on what I’ve seen in real incident cleanups, not theory.
1. Outdated plugins and themes (especially nulled ones)
This is the number one cause, full stop. Every hacked site I’ve touched had at least one plugin that hadn’t been updated in over a year. WordPress core gets patched fast; third-party plugins are where the real risk sits, because a lot of developers stop maintaining them and vulnerabilities go public on sites like WPScan’s database before a fix ever ships.
Nulled themes and plugins make this worse, not better. I’ve seen “premium” themes downloaded from sketchy sites that came pre-loaded with a base64-encoded backdoor in functions.php. The site owner thought they were saving $60. They ended up paying a cleanup fee that was ten times that, plus the SEO damage from being blacklisted by Google Safe Browsing for two weeks.
What actually works: run wp plugin list --update=available via WP-CLI weekly, or set up ManageWP/MainWP if you’re juggling more than three sites. Delete anything you’re not actively using — an inactive plugin is still a vulnerability if the files are sitting on the server.
2. Weak admin credentials and no login protection
Brute-force attacks against /wp-login.php and /wp-admin are constant — I’ve watched server logs show thousands of login attempts a day against sites nobody’s ever heard of, because bots don’t care about your traffic, they scan every WordPress install they can find. If your admin password is anything a dictionary attack could guess in a few hours, it’s a matter of when, not if.
The fix is not complicated: enforce strong passwords, install a login limiter (Limit Login Attempts Reloaded is free and does the job), and turn on two-factor authentication for every admin account. I also rename the default “admin” username on every site I set up — it’s a five-minute step that removes half the guessing game for attackers.
- Limit login attempts to 3-5 before a temporary lockout
- Require 2FA for all users with publish or admin capability
- Never reuse a password across client sites — use a password manager, not memory
3. Bad file permissions and exposed sensitive files
This one’s less talked about but shows up constantly in audits. wp-config.php should never be readable by the public — permissions of 644 on the file itself is common but I set mine to 440 where the hosting environment allows it. I’ve also found live backup files (backup.zip, database.sql) sitting in the public root because someone made a manual backup and forgot to delete it. That’s a full database dump, credentials and all, one Google dork away from being found.
Directory listing being enabled is another quiet killer — if someone can browse to /wp-content/uploads/ and see every file in a folder, they can map out your entire site structure before even trying to break in. Disable it in your .htaccess or Nginx config with Options -Indexes.
4. No firewall, no monitoring, no idea something’s wrong
Most of the compromised sites I’ve fixed had been hacked for weeks before anyone noticed — usually because Google flagged them for malware, or a client noticed weird redirects on mobile traffic only (a classic cloaking technique, where the malicious script only fires for search engine bots or mobile visitors so the site owner never sees it on desktop).
A web application firewall like Wordfence or Sucuri catches a large share of common attack patterns before they land, and just as importantly, it alerts you fast when a file changes unexpectedly. Pair that with file integrity monitoring so you know within hours, not months, when core files get modified. I set this up as a standard step on every site I launch now — it takes fifteen minutes and it’s saved multiple clients from a much bigger mess.
5. Cheap hosting with poor isolation and outdated PHP
Shared hosting is fine for a small blog, but a lot of budget hosts pack hundreds of sites onto one server without proper account isolation. If one neighboring site on that server gets compromised, a misconfigured server can let the infection spread sideways to every other account — I’ve seen this happen twice, where a client’s site got reinfected within a day of cleanup because the actual entry point was a different site on the same shared server, not theirs.
Running an outdated PHP version compounds the risk, since old versions stop receiving security patches. Check your PHP version in wp-admin under Tools > Site Health, and don’t let it sit two major versions behind — most managed WordPress hosts (Kinsta, WP Engine, even decent shared hosts like SiteGround) handle isolation and PHP updates properly, which is worth the extra few dollars a month.
The takeaway
None of these five causes require sophisticated attackers — they require sites that made it easy. Run through this as a checklist today: update everything, lock down logins with 2FA, check your file permissions and remove stray backups, install a firewall, and confirm you’re not on hosting that’s cutting corners. It’s an hour of work that prevents the multi-day nightmare of a full cleanup, blacklist removal, and rebuilding client trust.
