My WordPress site got hacked: what to do first

If your WordPress site has been hacked, take a full copy of the infected site first, then change every password and rotate the secret keys, then find out how the attacker got in before you clean anything. Cleaning without closing the entry point usually means being hacked again within days. The order matters more than any single tool.

This is the sequence I follow when a site lands on my desk in this state. It is a process, not a guarantee: a badly hidden infection can need more than a checklist.

What should I do in the first hour?

Do not start deleting files. Do these in order:

Ask your host whether they have clean, dated backups and whether they can see what changed. Hosts often have logs you do not.
Take a full backup of the infected site, files and database, and label it clearly. Sucuri’s cleanup guide starts the same way: download the site files and export the database before touching anything.
Put the site into maintenance mode or restrict access if it is serving spam, redirects or malware to visitors.

The infected copy is evidence. You may need it to work out how the attacker got in, and it protects you if a cleanup step breaks something.

How do I lock down access?

Assume every credential that touched the site is compromised. Change them from a device you trust:

WordPress admin and editor accounts
Hosting control panel, SFTP/FTP and SSH
The database password (then update wp-config.php to match)

A hosting provider’s compromise guide from Kualo makes the database point explicit: you must change the MySQL password to prevent the attacker reconnecting.

Then deal with the other ways back in:

Users. List every administrator and remove any you do not recognise. WordPress’s own developer blog shows wp user list --role=administrator for this, and notes that recently registered accounts you do not know are suspicious. The Sucuri mu-plugins case I link below included a hidden admin account.
Sessions and salts. Replacing the authentication keys and salts in wp-config.php invalidates existing login cookies, so a stolen session stops working. WP-CLI can do it with wp config shuffle-salts. Patchstack notes the side effect: all users are logged out.
Two-factor authentication on every admin account, once you are back in control.

How do I find out how they got in?

Work through the likely causes rather than assuming the first one:

A vulnerable plugin or theme. Patchstack’s numbers show where the flaws are, not how your site was entered, but they explain why I look here first. It counted 11,334 new WordPress vulnerabilities in 2025, with 91% in plugins, 9% in themes and 6 in core. It also reported that the weighted median time to first exploitation of heavily exploited vulnerabilities was about 5 hours, and that 46% of vulnerabilities had no developer fix at the time of public disclosure.
Stolen or weak credentials. Weak admin, FTP or hosting passwords, or a reused password from another breach.
Another site on the same account. Kualo’s guide warns that addon domains and other applications in the same hosting account may be compromised too.

To investigate, check your access logs for requests to unfamiliar PHP files and POST requests to plugin endpoints around the time files changed. The WordPress hardening handbook calls logs a key forensic resource because they can show IP addresses, timestamps and what the attacker did. Compare the first modified-file date to your plugin update history.

How do I clean the site properly?

Replacing files is better than editing them by hand, and updating through the admin dashboard alone is not enough on a hacked site (Kualo’s guide says this directly).

Core. Check your version in wp-includes/version.php, download the same release from wordpress.org and replace the core files. Sucuri warns not to overwrite wp-content or wp-config.php while doing this. WP-CLI can check the result: wp core verify-checksums compares your files with the official ones and flags files that should not exist.
Plugins and themes. Delete and reinstall them from clean sources. wp plugin verify-checksums --all checks plugins hosted on wordpress.org. Plugins from elsewhere cannot be verified this way, and the WordPress developer blog notes that is not proof of malicious code, since they may be premium or custom.
Look where malware hides.
- wp-content/uploads: PHP files there are a red flag. A find for *.php lists them. Sucuri’s mu-plugins case staged its payload in uploads as a hidden .sess-[hash].php file, so check hidden names too.
- wp-content/mu-plugins: must-use plugins load automatically and cannot be deactivated from the admin. Sucuri documented a loader named wp-index.php there, with a payload staged in uploads.
- wp-config.php: compare against the default sample file and remove anything you do not recognise.
Database. Look for injected spam links and suspicious PHP functions such as base64_decode, gzinflate and shell_exec, as in Sucuri’s seven-step guide.
Remove warnings. Request reviews from Google and other blocklists, and ask your host to lift any suspension.

Be aware that some malware fights back. Patchstack’s 2026 report, with Monarx data, describes memory-resident malware that rewrites cleaned files such as index.php and .htaccess the moment they are restored, and cloaking that shows clean pages to site owners and scanners while visitors get redirected. If files keep coming back, the infection is still running on the server, and that needs your host’s help, not another scan.

How do I harden the site afterwards?

Keep core, plugins and themes updated, and delete anything you do not use. WordPress’s hardening handbook notes older versions are not maintained with security updates.
Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. The handbook is honest that this will not stop an attacker uploading files, but it may stop some attacks.
Lock file permissions down. The handbook says only /wp-content/ should be writable by the web server, and only where needed, and suggests wp-config.php be 400 or 440.
Block PHP execution in uploads, one of the options in the Sucuri plugin.
Keep regular backups, including the database, and check they restore. The handbook recommends this too.
Watch for changes: logs, file integrity checks and alerts on new admin users.

When is it better to rebuild than clean?

If the site is small and content-driven, or you cannot trust any of the code, a rebuild on clean files with only the content moved across can be safer than hunting for backdoors. If the site has heavy custom code, no staging and no backups, cleaning gets expensive fast. This is a judgement call, and the cost of each route depends on the site.

FAQ

Should I restore a backup or clean the site?

Restoring is the fastest route if you have a backup you are sure predates the hack. Sucuri notes it can be impractical for sites that publish often, because you lose newer content. Whatever you restore, patch the entry point before it goes live again.

Will changing my admin password be enough?

No. Passwords for hosting, SFTP and the database matter as much, and the authentication salts need rotating to kill stolen sessions. Backdoor files and rogue admin users survive a password change.

How do I know the site is really clean?

You cannot be fully sure from one scan. Verify core and plugin files against official checksums, review admin users and the folders attackers favour, then watch logs and file changes for a couple of weeks.

Can a hack hurt my Google rankings?

Yes. Patchstack and Monarx describe cloaking malware that shows search engines keyword-stuffed spam, and Sucuri’s guide covers requesting reviews from blocklisting authorities such as Google once the site is clean.