Short answer: malware returns when a cleanup removed the symptom but left either the persistence mechanism or the way in. It can also arrive again from a second infected site on the same hosting account.
The five usual survivors — and how to check each
- A backdoor elsewhere than the detected file. Run
grep -RIlE 'eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(|assert\s*\(|create_function\s*\(' wp-content/across the whole install, uploads included. - A valid credential still in the attacker’s hands. Rotate WordPress, database, SFTP and hosting passwords and invalidate sessions.
- A vulnerable component never updated. Compare installed versions against known vulnerabilities and update or replace.
- A cron task that rewrites files. Inspect
wp cron event listfor unfamiliar hooks. - Cross-contamination from another install in the account. Scan every site under the same hosting user.
Distinguish cache from real reinfection
A cached page can keep serving an old malicious response with no new infection. Before concluding it returned, record file hashes and modification times: new or freshly modified files mean genuine reinfection; identical files behind a stale cache mean a caching problem. Purge every cache layer and re-check.
What a complete cleanup includes
Comparison against clean core/plugin/theme sources, review of non-standard files in writable directories, a database audit (options, posts, users, cron), server-config review, credential rotation, and checks across neighbouring sites. The most useful question is not “is it clean?” but “what was the entry vector, what persistence was removed, and what will be monitored?”.
Monitor after the fact
Watch file integrity, user accounts and search results for at least a few weeks. Reinfection usually returns quietly, and the earlier it is caught the smaller the second cleanup.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Reinfection means either persistence survived, the entry route remains open, valid credentials are still exposed or a neighbouring site is reintroducing the payload.
Compare file hashes and modification times between clean state and recurrence.
Audit cron, mu-plugins, writable directories, users and database options for persistence.
Rotate WordPress, database, SFTP, hosting and API credentials and invalidate sessions.
Scan every site and scheduled job running under the same hosting account.
What must be verified
- File integrity remains stable after cache purges and cron cycles.
- No unknown users, tasks or writable PHP files reappear.
- The vulnerable component is patched, replaced or removed.
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.
How do I tell if the malware genuinely came back versus a cache just showing the old infected page?+
Compare file hashes and modification times against your cleanup record. New or freshly modified files mean real reinfection; identical, unchanged files behind a stale cache mean a caching problem, not a new attack. Purge every cache layer, including the CDN, before concluding anything.
Can malware come back even if my site itself was cleaned correctly?+
Yes, through cross-contamination from another infected site sharing the same hosting account. Scanning only the site that showed symptoms isn't enough if a sibling install on the same server is still compromised and reinfecting your files or database.
I already changed my WordPress password, why isn't that stopping the reinfection?+
A password rotation only helps if the WordPress login was the entry point. Attackers often keep access through the database credential, SFTP or hosting password, a still-vulnerable plugin, or a cron task that rewrites files on schedule. All of those need checking and rotating, not just the WordPress admin password.
What's the most reliable sign a cleanup was actually complete rather than just cosmetic?+
A complete cleanup can answer three specific questions: what was the entry vector, what persistence mechanism was removed, and what is now being monitored. If a cleanup only confirms the site 'looks clean' without answering those, treat it as unfinished.