Key figure: Reported cybercrime losses in the United States reached $16.6 billion in 2024, up 33% from 2023 (FBI IC3, 2024 Internet Crime Report).
Cybersecurity news keeps documenting WordPress backdoors that reinstall themselves after deletion. This page's 5-sign diagnostic finds every foothold, then gives the removal order that kills them all before any single one can regenerate.
Self-healing backdoors plant multiple persistence mechanisms — cron jobs, hidden admin users, mu-plugins, database triggers — so deleting one file just triggers reinstallation from another. Normal cleanup fails because it treats symptoms, not the web of persistence. This page's 5-sign diagnostic finds every foothold, then gives the removal order that kills them all before any single one can regenerate.
A self-healing backdoor is malware that reinstalls itself after deletion using redundant persistence mechanisms — scheduled tasks, rogue admin accounts, and hidden plugins that watch and restore each other.
You deleted the suspicious file. You changed the passwords. And then — it came back. That is not bad luck: it is the signature of a self-healing WordPress backdoor, a new strain that repairs itself every time you try to remove it. This free checklist helps you work out whether that is what is happening on your site, and shows the exact removal order that actually ends it. Nothing here attacks anything — it is a defensive self-audit you perform yourself in wp-admin and SFTP.
Because the file you deleted is the symptom, not the reinfection path. Self-healing malware persists through multiple footholds — rogue admin accounts in the database, wp-cron jobs that re-download the payload, and a mu-plugin that WordPress loads first. Until every foothold is removed in the right order (database first, then mu-plugins, then cron, users, and salts), one survivor rebuilds everything.
wp-content/mu-plugins/ — the one folder WordPress loads automatically, before everything else, with no activation step and nothing to toggle off in wp-admin.Per Wordfence research, reported by The Hacker News ThreatsDay bulletin, October 2026.
wp_options database table as transients, malicious files in the mu-plugins folder, and a restore routine injected into wp-config.php or object-cache.php that rewrites plugin files from the database on every page load — reinforced by hourly cron jobs. WPTips.Tick every statement that is true for your site. This runs entirely in your browser — nothing is uploaded, nothing is scanned remotely. Each sign is weighted by how strongly it points at a self-healing backdoor.
A self-healing backdoor is never one file. It is a set of footholds that rebuild each other: the mu-plugin, rogue database entries, scheduled tasks, and compromised accounts. Delete one and the others restore it. That is why you must work in an order where no surviving foothold can re-infect what you already cleaned:
wp-content/mu-plugins/ of anything you didn't place there yourself. Do the database first (step 2), or a surviving cron job re-drops the file.wp-config.php to invalidate every existing session and cookie — this locks out anyone still holding a stolen session.If your score was high — or files keep reappearing no matter what you delete — Ingenious AI's BreachHunter platform is built for exactly this: hunting persistent compromises, not just running a one-time scan.
Get early access to BreachHunter on WhatsApp →It is a WordPress backdoor that repairs itself after you try to remove it. Per Wordfence research reported by The Hacker News ThreatsDay bulletin in October 2026, this variant is delivered as a must-use plugin (mu-plugin) with self-healing mechanisms, so deleting the malicious file alone does not end the infection — it restores itself from the other footholds it created.
Yes. Community members on r/WordPress documented a self-healing attack that survived a full file-level cleanup and returned within 24 hours, because persistence lived in the database and in wp-config.php, not just on disk: base64 payloads in wp_options transients, malicious mu-plugins, and a restore routine that rewrites plugin files from the database on every page load. (Per WPTips, Oct 2026: https://wptips.com/guides/self-healing-wordpress-malware-survives-file-cleanup/)
Because you are removing the symptom, not the reinfection path. Self-healing backdoors persist through multiple footholds: rogue admin accounts in the database, scheduled tasks (wp-cron) that re-download the payload, and the mu-plugin itself, which WordPress loads before anything else. Until every foothold is removed in the right order, one survivor rebuilds the rest.
Connect over SFTP (or your host's file manager) and open wp-content/mu-plugins/. Any legitimate site rarely needs files there, so anything you did not put there yourself deserves suspicion. Compare the file dates against your last legitimate change, and if you are unsure what a file does, treat the whole site as compromised and follow the full removal order rather than deleting one file.
Take the site offline or into maintenance mode first, then work in this order: the database (rogue admin accounts and malicious cron entries live here), the mu-plugins folder, scheduled tasks, all user accounts and passwords, and finally rotate the security salts in wp-config.php. Then reinstall WordPress core and every theme and plugin from clean sources. Doing it in any other order lets a surviving foothold re-infect the parts you already cleaned.
One vendor, one security posture. Every platform below is in early access now — request access on WhatsApp and we'll onboard you before the Nov 1 full launch.