Why WordPress Malware Keeps Coming Back After Cleanup

Cleaning the visible malware off a WordPress site is not the same as securing it. If the infection comes back days or weeks after a "cleanup," the malware was never the actual problem — the way the attacker got in was never closed.

The Symptom Everyone Recognizes

Someone cleans your site — a plugin, your host, a low-cost freelancer. For a few days it looks fine. Then the spam redirects come back, or Google flags you again, or a new admin account you didn't create shows up. This isn't bad luck. It's the predictable result of removing symptoms without finding the cause.

Why "Cleaned" Doesn't Mean "Secure"

A surface-level cleanup typically only does one thing: deletes the malware files a scanner can see. It usually misses:

• The original entry point — often a vulnerable plugin with a known, unpatched upload vulnerability, which the attacker can simply use again.
• Self-healing droppers — a small piece of injected code, often in a theme's functions.php, that silently re-creates the malicious plugin the moment it's deleted.
• Rogue administrator accounts — with randomized names, sitting quietly until they're needed again.
• Database-level persistence — logic planted directly in your database that survives a full file-system wipe entirely (more on this below).

A Real Example: 263 Sites, One Reinfection Vector

In a recent engagement, a real estate marketing agency's 263-site WordPress portfolio had already been through one round of cleanup with a previous provider. Sites kept throwing errors and reinfecting anyway. The actual cause: a vulnerable file-manager plugin with a known history of unauthenticated upload vulnerabilities, which the attacker was actively using to re-upload their payload every time it was removed. Until that specific plugin was identified and removed account-wide, no amount of file deletion would have held.

The Backdoor Category Most Scanners Miss Entirely

The same engagement turned up something more concerning: backdoors planted not in any file, but inside the MySQL database itself, as triggers that silently recreated administrator access. WordPress never uses database triggers on its own — so their presence is always a red flag — but it's a category of compromise that standard file-based malware scanners simply don't check for. We cover this in detail in our companion article on hidden WordPress backdoors →

How to Actually Break the Reinfection Cycle

1. Full database audit — check for hidden triggers, stored procedures, and scheduled events, not just infected files.
2. Identify the real entry point — not just what's currently on the site, but how the attacker got in and whether that vulnerability still exists.
3. Rotate every credential — WordPress admin, hosting panel, FTP/SFTP, database, and switch to key-based authentication where possible.
4. Harden after cleanup — close the specific vulnerability used, not just generic hardening advice.
5. Monitor for a real window — 30 days minimum, since some persistence mechanisms are dormant until triggered.

Frequently Asked Questions

If your site — or your agency's portfolio — has been cleaned before and keeps coming back, that's worth a proper investigation. Talk to our recovery team →