Cross-Site Contamination on Shared Hosting

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

You cleaned the site thoroughly. Files replaced, database swept, passwords changed, everything verified. Four days later it is infected again, with no sign of a new break-in. If you host more than one site under the same account, the answer is probably sitting in a folder beside it — an old site you forgot about, still infected, still able to write into its neighbours.

How sites reach each other

On typical shared hosting, every site under one account runs as the same system user. That user needs read and write access to all of those sites' files in order for any of them to work. There is usually no wall between them at the filesystem level, because from the server's point of view they are all just directories belonging to the same person.

So malicious code executing in one site has the same file access as code in any other. A backdoor in an abandoned test install can write to your live site's theme, drop files in its uploads folder, and modify its .htaccess, without needing any vulnerability in the live site at all. Your careful cleanup is undone by a neighbour you were not thinking about.

Recognizing the pattern

The signature is reinfection without a plausible entry point. You patched everything, rotated credentials, and found no new suspicious requests in the access logs for the cleaned site — and yet the malicious files reappeared. When the way in does not show up in the logs of the site that got infected, it is worth asking whether it came in through a different door entirely.

Another tell is identical payloads across several sites. If two or three of your sites carry the same injected script or the same backdoor filename, they are not three independent compromises. One of them was first, and the rest are downstream. My guide on reinfection loops covers the other explanations worth ruling out.

Taking a full inventory

This is the step that actually solves the problem, and it is the one people skip. List every directory in your hosting account and account for every single site, including the ones you forgot: the staging copy from a redesign three years ago, the subdomain built for a campaign that ended, the client site you handed over but never deleted, the backup folder containing a full copy of an old install.

Old installs are the usual culprit precisely because nobody maintains them. An abandoned WordPress from four versions ago, never updated, is trivially exploitable and completely invisible in day-to-day work. It has no traffic, so nothing draws attention to it, and it sits there as a permanent foothold.

Cleaning all of them at once

The critical rule is simultaneity. Cleaning one site at a time, in sequence, does not work when the sites can write to each other — the ones you cleaned first get reinfected by the ones you have not reached yet, and you can spend a whole day going in circles.

So: take everything offline or into maintenance mode first, then clean every site in the account before bringing any of them back. Delete the installs you do not need rather than cleaning them, which is both faster and permanently removes the risk. Then rotate credentials across the whole account — database passwords for each site, hosting and FTP passwords, and WordPress salts everywhere.

Preventing it structurally

The cleanest long-term answer is separation: put important sites on their own hosting accounts so a compromise cannot cross over. That costs more than stacking everything under one plan, and for a site that matters to your business it is money well spent.

Short of that, reduce the surface. Delete every install you do not actively need — that one decision removes most of the risk for most people. Keep what remains genuinely updated, including the sites nobody visits, because an unmaintained site is not a dormant risk, it is an open one. My guide on hardening covers the practical details, and if you have several infected sites in one account and want them all cleared properly in one pass, that is exactly what my malware removal service does.

Related reading: ASP.NET and IIS hosting. See also every platform I clean.

Common questions

Can malware really spread between my sites?

On standard shared hosting, yes, easily. All the sites under one account typically run as the same system user with read and write access to each other's files. Malicious code in one site can write directly into another without needing to exploit anything in the second site at all.

Why does my site keep getting reinfected with no new break-in?

Because there was no new break-in. If the access logs for the reinfected site show nothing unusual, the code likely came from another site in the same account. Look at every other install under that account, especially old or forgotten ones, before assuming you missed something in the site you cleaned.

Do I need to clean all my sites at the same time?

Yes, and this is the detail that makes or breaks the job. Cleaning them one at a time lets the ones still infected reinfect the ones you have finished. Take everything offline, clean or delete every site in the account, and only then bring things back up.

Would separate hosting accounts have prevented this?

It would have contained it. Separate accounts mean separate system users and no shared filesystem access, so a compromise of one site cannot reach the others. For a site your business depends on, that isolation is usually worth the extra hosting cost.

What about the old test site I never use?

That is very often the source. An unmaintained install running an old WordPress version with old plugins is easy to compromise and attracts no attention because nobody visits it. If you do not need it, delete it — that is faster than cleaning it and it removes the risk permanently.