1 · The WordPress database
Encoded script content in options records — especially autoloaded values — executes on normal requests and survives every file-level cleanup and theme reinstall.
Guide · Reinfection
If your WordPress site keeps getting hacked, the cleanup keeps missing something.
A site that is cleaned and reinfected — sometimes within days — is not unlucky. It means a persistence mechanism, an access path, or a neighboring compromise survived every cleanup so far. This guide covers the five places routine cleanups miss, and what breaks the cycle.
Published Last reviewed
- Symptom
- Malware returns after scans, restores, or professional cleanups
- Meaning
- Persistence or an access path survived the cleanup
- Usual misses
- Database, PHP config, hidden code, identities, shared hosting
- Fix
- Investigation and closure of the entry path, then retesting
The pattern
Reinfection is a diagnosis, not bad luck
Every reinfection follows the same logic: the visible symptom was removed, and something that can restore it was not. Attackers build for exactly this — the code you can see is designed to be found and deleted while a quieter mechanism waits to rebuild it after the scanner declares victory.
Why the infection appears to come back
-
01
A scan finds one bad file
The visible symptom is identified.
-
02
Only that file is deleted
The page may look normal for a while.
-
03
Another layer survives
The database, theme, .user.ini, or attacker access remains.
-
04
The infection returns
A later request, restart, cache refresh, or deployment loads it again.
The five places
Where surviving persistence actually hides
2 · PHP configuration
A .user.ini or php.ini auto_prepend_file directive loads a malicious file before WordPress starts. File scanners focused on WordPress rarely look here, and parent-directory settings can affect several sites at once.
3 · Places code is not expected
mu-plugins, drop-ins (object-cache.php, db.php), the uploads directory, and cache folders all execute or feed PHP but sit outside what most scans review carefully.
4 · Identities, not files
A rogue administrator, an application password, a session that survived the password change, an SSH or SFTP key, or a deployment token lets the attacker simply reinstall after each cleanup — no backdoor file needed.
5 · The neighboring site
On shared accounts without isolation, another site under the same user can reinfect a perfectly cleaned one. Cleaning one site in a compromised account is repainting one room of a flooded house.
Also worth ruling out
Sometimes the website is not the source at all
- A compromised administrator laptop or browser session that re-leaks credentials after every rotation.
- An infected backup or staging image that is restored — malware included — after each incident.
- A deployment pipeline or agency workflow that pushes an infected package to every release.
- A reused password appearing in credential dumps, giving the attacker fresh access without touching the site.
Breaking the cycle
What a cycle-ending cleanup does differently
- 01
Investigate before deleting
Timestamps, logs, and artifact structure identify what came first and what merely followed — evidence a delete-first cleanup destroys.
- 02
Enumerate every persistence layer
Files, database, theme, PHP configuration, scheduled tasks, and identities are each given an explicit trust decision, not just a scan pass.
- 03
Rebuild rather than patch
Core, plugins, and themes are replaced from trusted sources; legitimate customizations are reconciled separately instead of trusting edited files.
- 04
Close the entry path
The vulnerable component, exposed credential, or isolation gap that admitted the attacker is fixed — this step is the difference between cleanup and cycle.
- 05
Retest past the quiet period
Verification continues after caches expire, cron runs, and deployments execute — the exact moments earlier “clean” states collapsed.
How this played out on a real e-commerce site →The retest protocol used to prove a site stays clean →When the mechanism sits on the server, not in WordPress →Administer the server yourself? The WHM/cPanel response guide →Suspended by the host after a cleanup? Why, and how to be reinstated once →When every scanner reports clean and the flag stays up →
Common questions
Common questions about repeat infections
Should I just delete everything and rebuild the site?
A rebuild helps only if the entry path is closed and every credential is rotated first. Rebuilt sites are routinely reinfected through the same vulnerable plugin, stolen credential, or compromised hosting account that caught the original.
Does changing all my passwords stop it?
It is necessary but rarely sufficient. Sessions, application passwords, SSH keys, and deployment tokens can all outlive a password change — and none of it matters while a backdoor still executes on the server.
Is my hosting provider the problem?
Sometimes the account-isolation model contributes, especially when several sites share one user. But most reinfection cycles trace to surviving persistence or credentials, so blame the evidence, not the host, until the investigation says otherwise.
How many reinfections before I should get professional help?
One reinfection after a genuine cleanup is already the signal: something structural survived. Each further cycle adds spam indexing, warning risk, and evidence loss, so the second incident is the economical time to investigate properly.