A malware suspension changes the recovery order. The hosting provider has already contained part of the risk, so preserve its report and build a clean recovery path before asking for the account to be reopened.
Collect the provider’s evidence and scope
Save the flagged paths, scan time, reason for suspension and any affected domains. Determine whether the provider found one malicious file, a broader account compromise or outbound abuse.
Preserve a recoverable copy before cleanup
- Take an offline or isolated copy of files and database if the provider allows it.
- Keep the original malicious samples outside executable web paths.
- Record WordPress, PHP and plugin/theme versions.
- List other sites sharing the same account or credentials.
Build the clean baseline away from public traffic
Reinstall trusted core and components, classify custom code, remove confirmed persistence and compare unexpected changes with the integrity-alert triage process. For WordPress core specifically, use trusted checksum comparison.
Close the entry point before reactivation
- Patch or replace the vulnerable component.
- Rotate hosting, WordPress, SFTP, database and relevant API credentials.
- Remove unknown admins and invalidate sessions.
- Verify permissions and writable directories.
Meet the provider’s re-scan requirements explicitly
Do not assume a visually clean homepage is enough. The hosting scan must no longer find the flagged artefacts, and the account must stop any abusive outbound behaviour that triggered suspension.
Do not restore a full backup blindly
If the backup already contains the compromise, restoring it simply resets the incident to an earlier timestamp.
Return-to-service checks
Reopen only when the provider accepts the clean state, privileged access is rotated, integrity remains stable and normal traffic does not recreate the files or behaviour that caused suspension.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Restoring one website from an old backup can overwrite useful logs or reintroduce the vulnerable component. Coordinate evidence, clean source and account-wide scope.
- 1
Request the provider’s exact detection reason, sample paths and timestamps.
- 2
Obtain a full file/database backup and relevant access/mail logs before deletion.
- 3
Inventory every site, subdomain, cron job and user under the hosting account.
- 4
Identify whether the suspension also blocks database, SFTP or outbound mail.
What must be verified
- The provider confirms the account is clean and reactivated.
- All hosted sites pass integrity and user/cron review.
- No malware, spam or resource-abuse signal returns.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I restore the site from an old backup right after suspension to get back online quickly?+
Not immediately. Restoring from an old backup can overwrite logs needed to identify the entry point or reintroduce the same vulnerable component that caused the suspension in the first place, so evidence should be preserved before any restore happens.
Is it enough to clean just the one site the host flagged as malicious?+
No. The provider's sample paths and timestamps are a starting point, not a complete inventory, and other sites, subdomains, cron jobs, or users under the same hosting account can also be compromised or spreading the infection.
How soon should reactivation be requested after cleaning the flagged files?+
Only after confirming no unexplained files, users, or vulnerable packages remain anywhere on the account. Requesting reactivation while any of those are still present risks a second suspension arriving quickly, which also reduces the provider's trust for future incidents.
Does a hosting suspension always mean malicious files were found, rather than something like sending too much spam?+
No. Hosts can suspend an account for several distinct reasons, including malicious files, abuse traffic like spam or attack requests, or resource abuse, and the exact detection reason should be requested from the provider rather than assumed.