Clean up and recover WordPress after an intrusion

Finding everything an attacker added or changed is difficult. Replacing the core reduces the risk, but it does not guarantee a complete clean-up: you also need to review wp-content, wp-config.php, users, scheduled tasks and the database.

1. Preserve evidence and create a current backup

Put the website into maintenance mode and avoid new writes. Before cleaning, keep a complete copy of the compromised state, including files, database and logs, in isolated storage. Calculate and keep its checksums; this copy is for investigation and must not be restored as if it were clean.

Also create a current recovery point and check that it can be restored to a temporary location. Note down the versions of WordPress, plugins and themes, as well as users and scheduled tasks.

2. Compare before replacing

From the exact WordPress root, run:

wp core version
wp core verify-checksums --include-root

Review each difference. --include-root may flag legitimate custom files in the root; do not delete them without identifying them. Inspect and keep wp-config.php, .htaccess, search engine verification files and any of your own files separately. Review the whole of wp-content, including plugins, themes, uploads, mu-plugins and caches.

3. Replace the core in a recoverable way

Download the same clean version you identified from WordPress.org and verify its source. Instead of deleting, keep wp-admin and wp-includes in a dated quarantine outside all public directories and with no possibility of web execution. Put the clean copies in place and replace only the core files confirmed by checksum. Renaming them inside the website does not isolate them.

Do not replace wp-content or wp-config.php, or automatically treat them as safe: they contain customisations and may also contain the attack's persistence. Reinstall plugins and themes from official sources or known copies, and review custom files before recovering them.

Run again:

wp core verify-checksums --include-root

Check the front end, wp-admin, PHP logs, admin users, cron tasks, active options and database content before reopening.

4. Revoke access

Change the WordPress admin passwords, regenerate the salts to close their sessions, and revoke exposed keys or tokens. Always rotate the database password used by WordPress and update wp-config.php, because an intrusion with file read access may have exposed it. Also rotate cPanel, SFTP/SSH and email when they are involved in the way in, have been reused or the attacker may have been able to read them. Update the core, plugins and themes to supported versions and fix the way in before taking the site out of maintenance.

Rollback

If the replacement breaks the website, keep access closed, return the directories from quarantine and restore the database or files from the verified recovery point. Do not republish the compromised state: rolling back lets you continue the recovery in a closed environment while you prepare a new, controlled clean-up.

Limits of checksums and WP-CLI

A core comparison does not review the whole database, nor does it guarantee that plugins, themes or non-core files are safe. Check the exact version and language to interpret legitimate differences. Also keep hidden files, mu-plugins and settings that may load code before the application.

Avoid running commands that load the compromised installation until you are working in a contained environment. Do not assume that skipping normal plugins prevents any persistence from loading. Note down each replacement and keep a copy of the evidence outside the public site.

If you would rather we did it

If your WordPress is with another provider, when you order any plan we bring it over and apply this procedure free of charge before publishing it here. See what it includes in hacked website rescue.