A backup can look clean because the visible redirect or spam had not started yet. It may still contain a dormant backdoor, vulnerable plugin, stolen administrator account or scheduled task. The attacker can also remain outside the backup through hosting access, DNS or a neighbouring site.
Do not repeat the same restore without preserving the reinfection timeline.
Establish what “clean” meant
Record the backup creation date, source, files/database included and how it was previously tested. A scanner result or normal homepage view is not enough.
Check whether the backup includes:
- complete document root and hidden files;
- database and user records;
- must-use plugins;
- uploads and unknown PHP;
- cron or hosting configuration;
- sibling sites under the account.
Preserve the restored infected state before another overwrite.
Build a precise restore timeline
Note when restoration completed, when DNS/cache changed and when the first malicious symptom appeared. Record plugin updates, logins, cron runs and public requests in between.
If malware appears immediately, it may already exist in files/database or cache. If it appears after a scheduled interval, inspect cron and external access. If it returns after the first visitor request, a loader may activate on demand.
Use one timezone across evidence while keeping original timestamps.
Scan the backup offline
Restore to an isolated environment without public network access. Compare WordPress core and vendor packages, review custom code, search database injections and inspect scheduled events.
Do not open suspicious pages through a normal browser or allow the restored copy to send email, webhooks or scheduled requests.
Hash unexpected files and preserve them in quarantine. Treat the backup as untrusted evidence, not a deployable release.
Patch before public restoration
Update or replace vulnerable core, plugins and themes from verified sources in the isolated copy. Remove unsupported components and review custom upload/authentication code.
Clean hidden users, application passwords, malicious options, cron and database scripts. Rotate WordPress salts and affected credentials in a planned order.
Do not expose the restored site while it still runs the old vulnerable version, even for a short “test.”
Verify the backup’s own provenance
Confirm which system created the archive and whether it ran inside the compromised WordPress process. A backup plugin can package malicious files faithfully, and an attacker with panel access may replace an archive or alter its retention.
Compare archive hashes with provider-side records where available. Inspect whether the backup destination, encryption keys and restore account were exposed. If trust is uncertain, rebuild from verified application packages and migrate only reviewed content rather than treating the archive as an image of a trustworthy server.
Review persistence outside the backup
Inspect hosting-panel users/sessions, SFTP/FTP accounts, deployment keys, server cron, email accounts, DNS and CDN rules. Check every installation sharing the same account.
A clean WordPress archive cannot revoke a stolen cPanel session or remove a backdoor in an old staging directory.
Coordinate credential rotation with administrator devices and automation so clean secrets are not immediately stolen again.
Handle cache and multiple origins
An infected CDN response can remain after a clean restore, while a load-balanced site may restore only one node. Compare origin and public responses through authorised methods.
Purge relevant cache objects after the clean origin is verified. Confirm code and configuration match on every web node.
Do not interpret one intermittent clean response as proof.
Verify beyond the previous recurrence time
Repeat the original device/referrer/path trigger and monitor file/database changes. Run normal cron and allowed administrative workflows.
Observe longer than the interval between restore and reinfection. Check users, scheduled tasks, outbound requests and provider alerts.
When to request reinfection cleanup
Request help when several restores fail or the source backup cannot be trusted. Send the restoration timeline, public symptoms and backup date—not the archive or credentials.
A reliable recovery cleans the backup before deployment, closes external access and proves the original recurrence route no longer works.