How WordPress sites actually get hacked, and what stops each one
When we clean up a compromised site, it is almost never an exotic exploit. It is one of six things, in roughly this order.
1. An out-of-date plugin
By a wide margin the most common. A vulnerability is published, an automated scanner finds every site still running the old version within days, and yours is on the list because nobody logged in for four months.
The fix: turn on automatic updates for plugins and the core. If you are nervous about an update breaking something, that nervousness is really about not having a tested backup - fix that instead, then update automatically. And delete plugins you are not using: an inactive plugin's files are still on disk and still reachable.
2. A reused or guessable password
Credentials leak from unrelated services constantly, and attackers replay them against WordPress logins by the million. If the password on your admin account appears in any breach anywhere, it will be tried here.
The fix: unique passwords from a manager, and two-factor authentication on every administrator account. Also remove the accounts of people who have left, and demote the ones who do not need administrator - most contributors do not.
3. A nulled theme or plugin
A paid plugin offered free on a download site has been modified. That is the entire business model. The backdoor is usually in a file you would never open, and it often waits weeks before doing anything.
The fix: buy it or use a free alternative. If a nulled plugin is already installed, a clean reinstall is not enough - assume the whole site is compromised and restore from a backup taken before it went on.
4. File permissions and stray files
An uploads folder that will execute PHP turns a file upload form into a shell. An old info.php, a forgotten backup.zip in the web root, a .git directory left behind by a deploy - each one hands over something.
The fix: directories 755, files 644, no execution in uploads, and a look through the web root for anything that is not part of the site.
5. A neighbour on the same account
If you host five sites in one hosting account and one of them is a WordPress install nobody has touched since 2021, the other four are as exposed as that one. They share a filesystem.
The fix: separate accounts for sites you do not maintain together, and delete the ones that are no longer needed rather than leaving them parked.
6. A compromised computer, not a compromised site
Sometimes the credentials were never guessed. They were read out of an FTP client's saved-password file on an infected laptop.
The fix: SFTP rather than FTP, keys rather than passwords, and no saved credentials on a shared machine.
What to do if it has already happened
- Take the site offline or into maintenance mode. A hacked site actively harms visitors and your search ranking.
- Change every password - hosting, WordPress, database, FTP - from a clean machine.
- Restore from a backup taken before the compromise. Cleaning an infected install by hand almost always misses something.
- Update everything, then re-apply your content changes from after the backup date.
- Work out which of the six it was. Restoring without closing the route means being back here next month.
Daily backups are included on every plan we sell, which is what makes step 3 possible. If you are on a host where the most recent backup is one you took manually in February, that is the thing to fix before anything on this list.
