Most hacked sites get in through a small set of entry points: outdated software, weak or reused passwords, bad file permissions, nulled plugins, or an old install nobody's watching anymore. Most weren't even targeted specifically; they were scanned by bots looking for known vulnerabilities, and something on the site matched. The fix is the same in almost every case: find the door that was left open, close it, and clean up what got in.
If your site is showing a security warning right now, malware symptoms, or unexpected files, start with My site shows a security warning for the cleanup steps. This article is about the doors themselves, so the same thing doesn't happen again.
The usual entry points
Outdated software is the biggest one by far. WordPress core, plugins, themes, or any other CMS you run, every unpatched version is a published list of known exploits. Attackers don't need to find a new hole. They run automated scanners that check your version numbers against a database of disclosed vulnerabilities and walk straight in. Keeping everything updated, core, plugins, themes, isn't optional maintenance. It's the single highest-leverage thing you can do.
Weak or reused passwords are second. If your admin password showed up in a breach on some unrelated site, and you reused it here, that's a working login for anyone with the breach list. This applies to your WordPress admin, your FTP account, your email, and your portal account, not just one of them.
Bad file permissions let a compromised script write where it shouldn't. If a directory or file is set to be writable by more than it needs to be, a single vulnerable script can be used to drop a backdoor file anywhere else on the account. See Fixing a 500 Internal Server Error if you're chasing permission-related errors after a cleanup, since overly-tightened permissions during a fix can cause the same symptom from the other direction.
Nulled or pirated themes and plugins are a direct line in. "Free" premium plugins downloaded from somewhere other than the official source are a common way people install a backdoor themselves, deliberately packaged into the file by whoever cracked it.
Old, abandoned installs are an entry point people forget about. A WordPress install in a subfolder you stopped using two years ago is still live, still has a login page, and isn't getting updated. If you're not using it, remove it rather than leaving it as an unpatched target sitting on your account.
What actually closes the door
- Update everything, on a schedule. Core, plugins, themes. Don't let "I'll get to it" turn into months.
- Use unique, generated passwords for your portal account, cPanel, WordPress admin, FTP, and email. A password manager generates and stores a unique password for every one of these. Turn on two-factor authentication in the portal under Account → Security, since it stops a stolen password from being enough on its own.
- Only install plugins and themes from official sources: the WordPress.org directory, or a premium vendor you paid directly. Never a "nulled" copy.
- Remove what you don't use. Deactivated plugins, old themes, abandoned subfolder installs. Unused code is still exploitable code.
- Limit who has access. Every admin account, every FTP account, every team member with login access is another password that can leak. Remove access for anyone who doesn't need it anymore.
- Keep backups you've actually verified. Backups run nightly and stay encrypted at rest, but knowing you can restore, and roughly how far back, matters when you're deciding whether to clean in place or roll back.
Scanning already runs in the background
Every account on our servers runs through Imunify360 automatically. It scans for malware, blocks common attack patterns at the web application firewall level, and flags infected files without you having to install or configure anything. It's a safety net, not a substitute for the steps above. It catches what gets through; it doesn't stop the door from being left open in the first place.
After a cleanup, check for reinfection triggers
A site that gets reinfected right after cleanup almost always has one of two problems: the original vulnerability was never patched (so the same hole let the attacker back in), or a backdoor file was missed during cleanup and it's silently re-adding the malicious code. Update the software that was exploited first, then rescan; don't stop at deleting the obvious malicious files.
When to contact support
If you suspect your site is compromised and you're not confident doing the cleanup yourself, or a scan keeps finding new infected files after you've cleaned up, open a ticket from the portal. Support is real people, not a bot, and can help confirm whether an infection is fully cleared before you put the site back in front of visitors.