Several WordPress Sites Hacked on One Hosting Account? Plan Recovery Across Addon Domains

In this guide

When several separate WordPress websites are hacked on one hosting account, recovery needs an account-wide scope. Cleaning the main domain while leaving an abandoned staging copy, addon domain or shared access route untreated can leave a path back into the recovered site. First map the installations and their writable boundaries, then agree what will be cleaned, retired or moved.

This guide concerns independent WordPress installations sharing a hosting account. A WordPress Multisite network has a different architecture and needs the separate Multisite recovery plan. Neither situation proves that unrelated customers on the hosting server have been compromised.

Build an installation map before quoting “one cleanup”

Ask the account owner and host to list every domain, subdomain and document root. Compare the control-panel list with actual folders and databases; an old installation may remain after its domain was disconnected. Include development copies, temporary migration folders and applications that are not WordPress.

For each installation, record:

• Its public hostname, folder and database, plus whether it is still needed.
• The business owner and person authorized to approve changes.
• Known symptoms, first observation time and available logs.
• Shared system user, credentials, deployment access or backup destination.
• Its essential functions and latest business records that must survive recovery.

Keep this inventory private. It may contain internal paths and access information useful to an intruder. Record account identifiers and owners, but do not place passwords or secret keys in the worksheet.

Find the boundary that could connect the incidents

The WordPress hacked-site FAQ recommends involving the hosting provider because an incident may extend beyond the visible site. Ask the host which installations share an operating-system user and which files that user can write. Separate domain names do not by themselves establish filesystem isolation.

Use this decision checklist with the investigator:

1. One installation shows evidence, others are only nearby: preserve the distinction. Review the neighbours within the agreed account scope without declaring all of them infected.
2. Several sites have related unauthorized changes: compare timestamps, access paths and write permissions to identify a plausible shared route.
3. A recovered file changes again: preserve the new copy and corresponding logs. Investigate other writable applications, scheduled jobs and shared access before repeating the same cleanup.
4. Evidence reaches privileged server services: escalate to the host’s system administrator. Account-level cleanup is not a complete response to confirmed server compromise.

Do not infer the initial entry point solely from the oldest suspicious file timestamp. Imports, restores and deliberate timestamp changes can distort that evidence. A defensible incident record distinguishes confirmed findings from working hypotheses.

Contain the account while preserving useful evidence

The owner should identify which websites are commercially critical and authorize a coordinated maintenance window. Preserve suspicious files, database snapshots and available access logs securely before destructive cleanup. An incident snapshot is evidence, not a trusted restore point.

The host can advise on restricting the account’s public exposure, stopping malicious outbound activity and retaining logs. The developer should avoid running new scans or restoration jobs across several sites simultaneously without considering resource limits and evidence preservation. If the account has been suspended, use the hosting suspension recovery guide to coordinate the host’s reopening requirements.

Retire an abandoned application deliberately: preserve required records, remove its public routing and safely remove unnecessary executable files and access credentials. Merely renaming its folder is not a durable isolation control if the same account user can still execute or modify it.

Agree one recovery plan, with separate site checks

Write the cleanup scope in terms of installations and boundaries, not just domain count. It should cover trusted replacements for affected code, review of unauthorized database changes, user and integration access, scheduled tasks, and the suspected entry route. Mark exclusions explicitly so an old shop or staging folder does not quietly fall outside the work.

Credential recovery should include the hosting account and shared deployment routes as well as WordPress. Carry it out from trusted devices and coordinate rotation with dependent services. Do not publish replacement secrets to a server still under an intruder’s control. Use named access and appropriate permissions instead of restoring a universal shared login.

The WordPress hardening handbook provides the foundation for limiting access and containing damage. Ask the host whether separate accounts or stronger supported isolation would reduce the impact of a future compromise. Moving folders within the same writable account may not change the security boundary.

Accept each recovered website independently

Create a checklist for every active site: public pages, administration, forms, email delivery, search, scheduled work and checkout where applicable. Verify displayed contact and payment details against a trusted business record. Reconcile recent orders or enquiries before using an older database backup.

Run a controlled test of the functionality unique to each installation. A successful enquiry on the main domain does not validate a booking form on another site. Confirm that retired sites are no longer publicly executable and that staging does not send live customer notifications.

Then review for recurring file changes and unauthorized access across the account. The reinfection investigation guide is useful if symptoms return, but monitoring should follow a defined recovery scope rather than replace it.

FAQs

Does one hacked addon domain mean every site is infected?

No. It means the shared account deserves investigation. Actual exposure depends on permissions, access routes and evidence from each installation; record confirmed compromise separately from precautionary checks.

Can I move only the main website to new hosting?

You can prioritize it, but migrate reviewed data and trusted code. Also decide what happens to the remaining account and shared credentials so an untreated installation does not remain connected to the recovered business.

Is changing every WordPress password enough?

No. A shared hosting credential, writable backdoor or another application may remain. Access recovery must accompany investigation and cleanup across the agreed account boundary.

Prepared for website owners by Nithu / Suthakaran Nithursan. Dated advisory facts link to primary sources. Examples are illustrative and are not client results or guarantees.