When Your Whole Hosting Account Is Compromised

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

There is a meaningful difference between someone exploiting a plugin on one of your sites and someone holding the keys to your hosting account. The first is a site cleanup. The second means every site, every database, every email address and every credential under that account has to be treated as theirs until you prove otherwise, and cleaning one site accomplishes almost nothing.

How to tell which one you have

The strongest signal is scope. If several unrelated sites in the account are infected at once, particularly ones running different software or different plugin sets, a single site vulnerability does not explain it. Neither does a site being reinfected when its own access logs show no new suspicious requests.

Other signs point the same way: FTP accounts you did not create, control panel logins from unfamiliar locations in the access history, email accounts or forwarders you did not set up, cron jobs at the account level that are not yours, DNS records changed in the panel, or your own control panel password no longer working. Any one of those moves this from a site problem to an account problem.

How accounts get taken over

Most often by credentials rather than by exploitation. A password reused from another service that was breached elsewhere, a password stolen by malware on the computer you administer the site from, or one captured through a phishing page imitating your host's login. My guide on infostealer malware on your own machine covers the second, which is far more common than people expect.

The other route is escalation: a site-level compromise that reaches credentials stored on the server — database passwords in wp-config.php, FTP or SMTP credentials in plugin settings — and uses them to widen access. That is why a web shell on one site should never be treated as an isolated finding.

Taking control back

The order matters here. Change your hosting control panel password first, from a device you have reason to trust — not from the machine you suspect might be the source. Then enable two-factor authentication on the account if your host offers it, which stops a stolen password being enough on its own.

Then work through every access path the account provides: delete FTP and SFTP accounts you do not recognize and change the passwords on the ones you keep, check SSH keys and remove any you did not add, review email accounts and forwarding rules, and check account-level cron jobs. Each of those is an independent way back in, and changing only the panel password leaves the rest wide open.

Then clean every site

All of them, at the same time. Sites in a shared account can write to each other, so cleaning them sequentially lets the ones you have not reached reinfect the ones you have finished — my guide on cross-site contamination covers why that goes in circles.

Take everything offline, then clean or delete each site. Delete the ones you do not need rather than cleaning them; an abandoned install is a permanent liability and removing it is faster than securing it. Rotate every database password, replace WordPress salts everywhere, and reset all site user passwords.

Working with your host

Tell them, early. A good host can show you control panel access logs you cannot see yourself, tell you whether the compromise looks server-side, and in some cases confirm from their own monitoring when unauthorized access began. That information is genuinely hard to get any other way.

If the account was suspended, my guide on hosting suspensions covers what hosts need in order to restore it. And be direct with them about what you have found — a specific account of the problem gets substantially better help than a general report that something seems wrong.

Afterwards

Assume everything in that account was readable while the attacker had access, including database contents and anything in email. That determines whether you have a data incident to handle, which my guide on breach notification obligations covers.

Then make the recurrence harder: unique passwords stored in a password manager, two-factor authentication everywhere it is offered, no more shared logins, and separate hosting accounts for sites that matter so a future compromise cannot spread. If you are dealing with several infected sites and are not certain the account is genuinely back under your control, that is precisely what my malware removal service is for.

Common questions

How do I know if it is the account rather than just one site?

Scope is the giveaway. Several unrelated sites infected at once, reinfection with no suspicious requests in that site's own logs, or artefacts at the account level — unfamiliar FTP users, unexpected email forwarders, control panel logins from strange locations, cron jobs you did not create. Any of those points past a single site.

What do I change first?

The hosting control panel password, from a device you trust rather than the one you suspect. Then enable two-factor authentication if available. Then work through FTP and SSH accounts, email accounts and forwarders, and account-level cron jobs — each is a separate route back in that a panel password change does not close.

Do I really need to clean every site in the account?

Yes, and simultaneously. Sites under one account can usually write to each other's files, so cleaning them one at a time means the infected ones re-infect the finished ones. Take everything offline, clean or delete all of it, then bring things back.

Should I tell my hosting provider?

Yes, promptly. They can see control panel access logs you cannot, they can tell you whether the problem extends beyond your account, and they are the ones who will restore service if the account gets suspended. A specific, factual report gets far better assistance than a vague one.

Could this have come from my own computer?

It is one of the most common routes. Information-stealing malware on a machine you administer the site from harvests saved passwords and session cookies, including hosting logins. If you cannot find a server-side entry point, scanning your own devices is the logical next step.