75 guides published Start a blog Fix my site How we test
SECURITY

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

  1. Put the site into maintenance mode or take it offline at the server level.
  2. Change the hosting account password and enable two-factor there.
  3. Rotate the database password and update wp-config.php.
  4. Regenerate the authentication salts to kill every active session.
  5. 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:

SourceWhat to look for
Access logsPOST requests to unusual paths, especially around the time the site changed behaviour.
File modification timesCore and plugin files modified at a time you did not deploy anything.
New filesAnything in wp-content/uploads with a .php extension. Uploads should never contain PHP.
User tableAdministrator accounts you did not create, or accounts whose role changed.
Scheduled tasksUnknown cron entries, often used to re-create removed files.
Plugin versionsCross-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 eval on 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

  1. Scan with at least two independent tools. They catch different things.
  2. Fetch the site as Googlebot and confirm the response matches what a browser sees. Cloaked spam only appears to crawlers.
  3. Check Search Console for security notices and request a review if one is open.
  4. 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.

S

Sumit

Writes everything on TechMozz.

More in Security