Clean a Hacked WordPress Site Without Reinstalling Everything
A compromised WordPress site can almost always be cleaned without starting over. What makes the difference is doing it in the right order: people routinely remove the malware, miss the entry point, and get reinfected within days.
The short version
- Take a forensic copy before you change anything.
- Find the entry point before you clean, or you will do this twice.
- Rotate every credential, including database and hosting.
- Prove it is gone before you take the site out of maintenance.
Step 0: do not panic-delete
The compromised files are your evidence. Take a full copy — files and database — and store it off the server before you remove anything. If you delete first and the infection recurs, you have nothing to compare against.
Watch out
Do not restore an old backup as your first move. If the compromise predates the backup, you restore the backdoor along with the site, and you have now also lost the evidence.
Step 1: contain
- Put the site into maintenance mode or take it offline at the server level.
- Change the hosting account password and enable two-factor there.
- Rotate the database password and update wp-config.php.
- Regenerate the authentication salts to kill every active session.
- Note the exact time you did each of these.
Step 2: find the entry point
This is the step that gets skipped. Work through these in order:
| Source | What to look for |
|---|---|
| Access logs | POST requests to unusual paths, especially around the time the site changed behaviour. |
| File modification times | Core and plugin files modified at a time you did not deploy anything. |
| New files | Anything in wp-content/uploads with a .php extension. Uploads should never contain PHP. |
| User table | Administrator accounts you did not create, or accounts whose role changed. |
| Scheduled tasks | Unknown cron entries, often used to re-create removed files. |
| Plugin versions | Cross-reference installed versions against published vulnerabilities. |
Step 3: compare against clean copies
Download matching versions of WordPress core, your theme and every plugin from their official sources, then diff them against what is on the server. Anything that differs in core or in a plugin you have not modified is suspect.
# replace core wholesale, keeping wp-config.php and wp-content
wp core download --force
# reinstall every plugin at its current version
wp plugin install $(wp plugin list --field=name) --force
Core and plugin files can be replaced wholesale because they should be identical to the official release. Your theme and wp-content/uploads cannot, which is where the manual work is.
Step 4: clean what cannot be replaced
- Theme files. Read them. Look for obfuscated blocks, long base64 strings, and
evalon anything dynamic. Check the end of functions.php specifically, which is where injected code commonly sits. - Uploads. Delete every PHP file. There is no legitimate reason for one to exist there.
- mu-plugins. A frequently-missed directory. Anything here loads automatically and silently.
- Database. Check wp_options for injected scripts, and wp_posts for links added in bulk to old content.
Step 5: close the hole
Whatever you identified in step two, fix it. If the entry point was an outdated plugin, update or remove it. If it was a weak password, rotate everything and enable two-factor. If you could not identify it, assume credentials and rotate everything, including every user account.
Step 6: prove it is clean
- Scan with at least two independent tools. They catch different things.
- Fetch the site as Googlebot and confirm the response matches what a browser sees. Cloaked spam only appears to crawlers.
- Check Search Console for security notices and request a review if one is open.
- Monitor file integrity daily for two weeks. Reinfection usually surfaces within that window.
Step 7: harden, then reopen
Only now apply the hardening steps. Doing it earlier simply hardens a site that still contains an attacker.
Common questions
How long does this take?
Two to four hours for a straightforward case where the entry point is obvious. Considerably longer if logs have rotated away or the infection is old.
Should I just restore a backup?
Only if you know the backup predates the compromise, and you still have to close the entry point afterwards or it happens again.
Do I need to tell anyone?
If customer data could have been accessed, yes — and the obligations vary by jurisdiction. Take advice rather than guessing.
When should I hand this to a professional?
If payment data is involved, if the site is a revenue-critical business asset, or if you cannot find the entry point after a thorough search.
Sumit
Writes everything on TechMozz.