Shared Hosting Cross-Site Infection: Why Hacks Spread

You clean your main business site after a hack. Every file checked, every password changed, the plugin that let them in updated. Two weeks later the same spam pages are back. When you finally look at the rest of the hosting account, you find your old blog, a test copy of the site from a redesign, and a half-finished shop your nephew started, all on the same plan, all quietly infected.

This is one of the most common reasons a cleanup does not hold. When several websites share one hosting account, an attacker who gets into one of them can usually reach all the others. This post explains why, how to check for it, and how to clean a crowded account so it stays clean.

Why sites in one account can infect each other

Most shared hosting plans let you run more than one website. In cPanel these are often called addon domains; in Plesk, extra domains or sites within one subscription. Each site has its own folder, its own domain name and often its own database. It feels like separate houses.

Underneath, though, they are usually rooms in the same house. All the files in the account belong to the same system user, and the web server runs PHP as that user. When a malicious script runs inside one site, it runs with the same permissions as every other file in the account. It can list the other folders, read their configuration files and write new files into them. No break-in is needed, because as far as the server is concerned, there is no wall between them.

So an attacker who gets in through an old plugin on your forgotten blog does not stop at the blog. Many infection scripts are written to walk through every folder they can reach and plant copies of themselves along the way.

Cross-account and cross-site are different problems

It is worth separating two situations that both get called “the hack spread on shared hosting”.

Within one account: your own sites, under your own login, infecting each other. This is normal behaviour for most shared plans, and it is the main subject here.

Between accounts: a stranger’s site on the same physical server infecting yours. A well-run host separates customer accounts so this cannot happen, and many use isolation tools to make sure of it. If it does happen, it points to a problem on the host’s side, which we discuss in our post on whether your host is responsible for a hacked site.

Owners often assume the second when it is really the first. Before blaming a neighbour on the server, check every site you have in your own account.

The sites people forget they have

The infection usually starts in the site nobody looks after. Over the years, accounts collect leftovers. Look for these:

• Old staging or test copies. A folder called /dev/, /new/, /staging/ or /test/ holding a full WordPress install that was used once during a redesign and never deleted. Our guide to WordPress staging sites explains how to run one properly, which includes removing it afterwards.
• The previous version of the site. Sometimes moved to /old/ or /backup/ “just in case”, with the plugins frozen at whatever version they were on that day.
• Abandoned side projects. A blog, a landing page for an event years ago, a second brand that never launched.
• Extra copies inside the main site. A full site archive unzipped into a subfolder of the live site, or a migration plugin’s leftover export.
• Sites a developer set up for you. If someone else built your sites, they may have added things you never knew about. Taking stock of exactly this is part of taking over a website from another developer.

Each of these is a full, working website with its own login page, its own plugins and its own vulnerabilities. None of them get updated, because nobody remembers they are there.

How to check a hosting account for spread

Start from the hosting control panel rather than from WordPress, because WordPress only shows you one site at a time.

1. List every domain and subdomain in the account. Compare it with the sites you think you have. Note any you do not recognise.
2. Open the file manager at the top level of the account and look at every folder, not only the ones linked to a domain. A WordPress install can sit in a folder with no domain pointing at it and still be reachable through your main domain’s address.
3. Look for WordPress installs everywhere. Any folder containing wp-config.php and a wp-content folder is a WordPress site. Count them.
4. Sort files by modification date in each install and look for clusters of recently changed files, especially PHP files in places that rarely change.
5. Check the databases list. More databases than sites can mean forgotten installs, or installs that were deleted but left their data behind.
6. Look at the top-level .htaccess and any index files outside the site folders. Some infections write to the account’s root so they affect every site beneath it.

If your host runs a malware scanner, ask for a scan of the whole account and the full list of flagged paths. That list often makes the spread obvious at a glance, because the same file names turn up in several sites.

Why cleaning one site at a time fails

Suppose you have four sites in the account and you clean the important one on Monday. The other three are still infected. On Tuesday, one of their scripts runs, finds your clean site, and writes the backdoor back into it. By the end of the week you are where you started, and it looks as though the cleanup was useless.

The fix is to treat the account, not the site, as the thing being cleaned. In practice that means:

• Take a full backup of the whole account first. Every site, every database. It preserves evidence and protects you from a mistake.
• Decide what to keep. Sites nobody needs should be deleted, files and databases both, rather than cleaned. That is the fastest and most reliable cleanup there is.
• Take the remaining infected sites offline together, or restrict access to them, so nothing reinfects anything while the work is under way.
• Clean all of them in the same session, and only bring them back once each one is checked.
• Change every password and every set of WordPress security keys across all the sites, plus the hosting panel, FTP accounts and database users.

If the same infection keeps returning even after that, the problem is usually a backdoor that was missed, or a cron job set at the account level that downloads the malware again. Our page on fixing a site that keeps getting reinfected explains what we look for in that situation.

Shared credentials make spread easier

Files are not the only route between sites. If every site in the account uses the same database user, any one compromised site can read the others’ databases. If every WordPress install has the same admin username and password, a stolen login on one is a stolen login on all of them. One FTP account with access to the whole tree means one leaked password exposes every site.

When you rebuild, give each site its own database user with access only to its own database, its own admin accounts and its own passwords. It takes a little longer to set up and it limits how far a future breach can reach.

Separating your sites after the cleanup

Once the account is clean, think about whether the sites should share it at all.

• Keep the important sites apart. A shop or the main business site is worth its own hosting account, so a problem on a hobby blog cannot touch it.
• Check whether your plan offers separate users. Some control panels let you run each domain under its own system user, which gives you real separation inside one plan. Plesk subscriptions, for example, each have their own system user. Ask your host what is possible on your plan.
• Delete instead of archiving. If you want to keep an old site for reference, download a copy to your own computer and remove it from the server.
• Keep a written list of every site in the account, who is responsible for it and how it gets updated. Anything not on the list should not be on the server.

When your host suspends the whole account

Hosts usually suspend at the account level, not the site level. So when one site sends spam or hosts something harmful, every site in the account can go offline together, including the ones that were never infected. That can be the first sign many owners get that their sites are connected at all. If you are in that position now, our page on dealing with a hosting suspension for malware explains how to work with the host to get the account back.

A crowded account with several infected sites is more work than a single hacked site, but it is the same job done carefully across everything at once. If you would like help with it, the hacked website repair page explains how we work. Message us on WhatsApp, start with the word HACKED, and list the domains in the account; we will tell you what we find before suggesting what to clean, keep or remove.

Next in this series: Restoring a Backup After a Hack: When It Is Enough