Multiple Websites Infected on Shared Hosting: Stop Reinfection

Map the real account boundaries

Two domains can appear unrelated to visitors while sharing a hosting login, operating-system user, deployment key or database password. Conversely, two customers on the same provider may be effectively separated by the host's account controls. Do not assume either that all shared hosting is unsafe or that a different folder creates meaningful isolation. Ask the provider to describe the boundaries relevant to your package.

Create an inventory that includes production sites, old campaign microsites, development copies, parked domains that execute code, and abandoned installations. For each, record its document root, software owner, database, update status and access methods. Include applications outside the main navigation. An unused test installation can still accept internet traffic and may have been forgotten during routine patching.

Use this map to decide the response scope. A single changed file across several roots may indicate shared access, but similarity alone does not identify the original vulnerability. Preserve logs and file samples before a mass restoration erases the sequence of events.

Contain affected services without losing the evidence

Protect visitors first when a site is serving harmful content. Work with the host to restrict affected applications while retaining administrative access for the response team. Keep a record of which domains were restricted, when, and by whom. Communicate a reliable contact route outside the affected account if its mail service may also be compromised.

1. Preserve a restricted incident copy and available access logs for every potentially connected installation. Label the copies by domain and capture time so findings do not become mixed together.
2. Establish trusted control of the hosting account and recovery email. Review additional accounts, keys, integration tokens and recent account changes, then revoke unexplained access after recording it.
3. Pause non-essential deployment and synchronisation jobs while their scripts and credentials are checked. A legitimate synchronisation process can also copy compromised material into a clean destination.
4. Agree with the host whether the problem appears limited to an account or requires investigation of server-level isolation. Avoid testing boundaries against other customers; that is the provider’s responsibility.

Choose recovery groups instead of restoring everything blindly

Group sites by the access and software they share. A maintained store with a verified code repository may be rebuilt differently from an obsolete campaign site whose business purpose has ended. Retire unnecessary applications rather than restoring vulnerable software just to reproduce the old account layout. Record the business owner's approval before removing a service permanently.

For each retained site, choose reviewed source code or a backup from before the earliest credible compromise. Reconcile recent business records separately. Do not copy an entire old account directory into a new account and assume that moving provider has made the files trustworthy. Migration changes the destination, not the provenance of the content.

Scheduled commands deserve their own review: cPanel documents cron as the mechanism for recurring account tasks. Identify each legitimate job's purpose, owner and required permissions. A clean website can be damaged again if a neglected job or deployment source continues to write unreviewed files into its document root.

Improve separation while recovery access is being rebuilt

Consider distinct hosting accounts or equivalent provider-supported isolation for applications with different owners or risk profiles. Use unique database users and credentials with only the permissions each application needs. A reseller package, virtual server or container is not automatically safer; the benefit depends on its actual configuration, maintenance and operator responsibilities.

• Remove unused transfer accounts and review which SSH or deployment keys remain authorised.
• Give each site an identifiable maintenance owner and patch schedule.
• Keep recovery copies inaccessible from public URLs and outside normal synchronisation paths.
• Separate backup administration from everyday website editing where the platform supports it.
• Document emergency access so future responders do not fall back on a shared password.

WordPress documents that must-use plugins load automatically in their designated location. Where WordPress is present, review these components explicitly rather than relying only on the normal plugin list. Check their expected source and business purpose in each installation; a legitimate hosting integration and an unexplained file require different handling.

Test each site and the connections between them

Imagine a hypothetical agency account with a company website, a shop and an old demonstration site. Cleaning the company website alone appears to work until a shared deployment key writes infected files back during the next scheduled release. The useful question is therefore not only whether each site is clean now, but which process or identity can change it next.

Verify the public behaviour of every retained domain: redirects, forms, uploads, privileged access and any integration that shares data with another site. Review changes after scheduled tasks have had an opportunity to run. A quiet interval chosen by the response team can provide useful observation, but no universal waiting period proves an account is safe.

• Record the evidence supporting each site’s recovery decision.
• Confirm the host has addressed any account isolation concern raised during investigation.
• Monitor unexpected cross-site file changes and renewed access from revoked identities.
• Escalate repeated infections or unexplained ownership changes to a responder who can assess the wider environment.

A multi-site recovery plan should finish with an ownership map, a maintenance plan and a clear list of remaining uncertainties. CyberXperts can help assess connected installations and prioritise their recovery without assuming that a single malware scan covers every domain.