What to do first when a WordPress site may be compromised: isolate, preserve, restore, rotate credentials

The moment you suspect a site has been tampered with is when it is easiest to act in a hurry. But the wrong order can erase the clues you need, or let the same visitor back in through the same door. This article lays out a first response for a suspected WordPress compromise in this order: isolate, preserve evidence, restore from a clean backup, rotate credentials. It does not cover attack techniques; it focuses on a calm way to proceed. The best steps depend on your environment, so please treat this as a starting point and involve your hosting provider or a specialist when unsure.

First, do not rush to delete

When you find a suspicious file, the urge is to delete it immediately. That is natural, but record what happened before you remove anything. Once files are gone, you may no longer be able to tell when or how someone got in, and the same gap may remain after recovery.

Also, finding and removing one item does not mean you are done. What you found may be only part of it. So think in this order: limit the damage, keep a record, return to a clean state, close the door again.

1. Isolate: stop the damage from spreading

The first goal is to keep the problem from reaching visitors or other sites.

• Take the site offline temporarily: show a maintenance page or restrict access, following your server panel or provider's guidance
• If other sites share the same server or account, check them too. A compromise on one can reach the others
• Contact your provider: on shared hosting, they can sometimes share what they can see, such as logs or blocking status

At this stage, do not delete or overwrite files yet.

2. Preserve evidence: keep it before you change it

To investigate and prevent a repeat, save the current state as it is.

• Copy the whole site: download files and the database before any changes and keep them elsewhere, separate from your recovery backups
• Collect access and error logs: logs are rotated away after a while, so fetch them early. See Reading access logs for how to read them
• Write down how you noticed: what you saw and when. Screenshots help

You can check things in a read-only way. For example, WP-CLI can compare WordPress core files against official checksums:

wp core verify-checksums
wp user list --role=administrator

These commands look at the state without changing it. The reasoning is covered in Three checks to confirm a site has not been compromised. Note that a clean result is not proof that nothing happened. Treat each finding as one clue.

3. Restore from a clean backup

In general, returning to a backup known to predate the problem tends to leave fewer things behind than removing suspicious files by hand. Points to keep in mind:

• Decide which backup generation is safe: if you do not know when it started, compare several. The newest backup may already contain the problem
• Consider restoring into a fresh environment: restoring to a new location and verifying before switching over also keeps the original as evidence
• Reinstall WordPress core, plugins and themes from official sources: update to current versions after restoring, and remove what you do not use
• A backup is only useful if it can be restored: how to take a restorable database backup is covered in mysqldump and consistent backups. Avoid trying a restore for the first time during an incident

If you have no backup, or none you can trust, prioritize talking to your provider or a specialist over going it alone.

4. Rotate credentials: close the door again

Even after a clean restore, stolen credentials let the same person back in. After restoring, rotate what may have been involved.

• WordPress administrator passwords: change them for every admin account. Investigate any admin account you do not recognize before deciding what to do
• Database password: update wp-config.php to match
• SSH keys, FTP/SFTP passwords, server panel password: renew anything that may have leaked, and disable old keys
• Salts (authentication secret keys): wp config shuffle-salts regenerates the salts in wp-config.php. This invalidates every existing login session, so everyone must sign in again. Do it knowing that
• API keys for external services stored on the site: reissue them at the provider

Rotate after returning to a clean environment. If you change them while the problem remains, the new credentials can be read as well.

5. Prevent a repeat, then decide when to reopen

After recovery, review what may have been the entry point: plugins that stopped receiving updates, forgotten admin accounts, unused plugins and themes, file permissions. The attack surface checklist can help.

Even after reopening, watch logs, admin accounts and file changes more closely than usual for a while. Base the timing on whether you have a lead on the cause and have closed the likely entry points.

Limits to be aware of

• Even if you follow the steps, the cause may remain unknown. In that case you close likely entry points broadly
• If the site handles personal data, you may need to notify affected parties or authorities depending on the situation. Talk to the person responsible in your organization or a specialist
• Tools alone cannot determine whether or how far a compromise went. Finding nothing is not a guarantee of safety

Summary

• Do not delete in a hurry. Go in order: isolate, preserve evidence, restore to a clean state, rotate credentials
• Recovery depends on a backup you can actually restore, so routine backup verification shapes the quality of the first response
• Rotate credentials after returning to a clean environment
• When unsure, ask your provider or a specialist

Steps decided in the middle of an incident tend to go wrong. Writing your own version down while things are calm will help when it matters.