What to do when your WordPress site is hacked

When your WordPress site is hacked, work in this order. Write down what you see, keep a copy of the site as it is now, then change every password and log everyone out. Next, remove the hack, either by restoring a clean backup from before it started or by replacing WordPress, your plugins and your theme with fresh copies. Check for admin users you did not create, update everything, and only then ask Google to remove any warning. Changing passwords before you find the way in is not enough, and cleaning without changing passwords lets the attacker log back in.

This guide goes through each step on ordinary cPanel hosting, with the checks WordPress.org itself recommends and one we ran on a test install.

How do you know your WordPress site has been hacked?

WordPress.org’s own “my site was hacked” FAQ lists the signs that clearly point to a hack:

• Google, Bing or another search engine has blacklisted the site.
• Your host has disabled the site.
• The site has been flagged for distributing malware, or visitors say their antivirus warns them about it.
• Someone tells you your site is being used to attack other sites.
• You notice things you did not authorise, such as new users.
• You can see the hack when you open the site in a browser.

Two symptoms fit this list well. The first is a redirect, where visitors land on a spam or scam site instead of yours. Google notes that hackers may hide such content from site owners, so you can see nothing wrong on your own computer while visitors are sent elsewhere. The second is a new administrator account you never created. Both mean someone can change files or settings on your site, so treat them as a hack, not a glitch.

What should you do first?

Write down what you see

The FAQ calls this the first step. Note what made you think the site is hacked, when you noticed it, and what changed recently, such as a new plugin, a theme change or a plugin update. This becomes your incident report. If you hire someone to clean the site, give it to them first.

Tell your host

On shared hosting, a hack can affect more than your own site. The FAQ suggests checking with your host in case it is already taking steps or needs to. The FAQ also warns that a site abused to send spam can get the server’s IP address flagged by email blacklists, and that address is often the one your email goes out from. If your shop’s order emails stop arriving after a hack, our guide to WooCommerce order emails that do not arrive explains how to check your mail records.

Keep a copy of the hacked site

Before you clean anything, take a full copy of the files and the database as they are now. The FAQ recommends this snapshot even though it is infected. If the cleanup goes wrong, you still have the site’s content, and the copy can help show how the attacker got in. In cPanel, File Manager can compress your site folder for download, and phpMyAdmin can export the database. Store the copy on your own computer, away from the site.

Which passwords do you change, and in what order?

The FAQ says to change every access point, which it lists as FTP or SFTP, the WordPress admin, cPanel or any other control panel, and the database, for every user who has access, not just you. Start from the account that controls everything else:

1. Your hosting account and cPanel. Whoever has cPanel can change every file and every other password.
2. FTP and SFTP accounts. Delete any you do not recognise.
3. The database user. Set a new password in cPanel’s database section, then put the same password in wp-config.php, or the site cannot connect.
4. Every WordPress administrator, then every other user who can publish.
5. Email accounts on the domain, especially the one WordPress sends password reset links to.

Our help guide on resetting a password shows where each of these lives in cPanel and WordPress.

How do you log out everyone who is logged in?

A new password does not end a session an attacker already has. To end every session at once, replace the security keys in wp-config.php. WordPress’s wp-config documentation says that changing these keys invalidates all existing cookies, so every user has to log in again.

WordPress.org runs a key generator. We opened it and it returned eight lines, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY, plus the four matching SALT lines. Replace the same eight lines in your wp-config.php with a fresh set. The page shows new random values every time you load it, so never reuse a set you have pasted anywhere else.

Change the passwords again once the site is clean. The FAQ says this too. If the attacker still had a way in while you worked, the first new passwords may already be known.

Should you restore a backup or clean the site by hand?

If you have a backup from before the hack, restoring it is usually the fastest way back. WordPress’s hardening guide explains why regular snapshots matter here. A site can be compromised days before anyone notices, and only a backup from before that date is clean.

Three things decide whether a restore is enough:

• Pick a date before the first sign. Use your notes from the first step. If you do not know when it started, go back further than you think, and accept losing recent posts or orders. Copy any orders placed since then out of the hacked copy first.
• A restore brings back the hole. The plugin or password the attacker used comes back with the old files and database. Update everything and change the passwords right after the restore, before you reopen the site.
• Restore files and database together. A WordPress site is both. Restoring only the files leaves any change the attacker made in the database, such as a new admin user or injected script in a post.

On cPanel hosting, your host may keep daily backups for a set number of days. Ask which dates exist before you choose. If none is old enough, clean the site as below.

How do you find and remove what the hacker changed?

Check WordPress’s own files against WordPress.org

WordPress.org publishes a checksum for every file in every release, a short fingerprint that changes if even one character of the file changes. WP-CLI’s core verify-checksums command downloads that list for your version and compares every core file on your site against it.

If your host gives you SSH or a terminal with WP-CLI, run wp core verify-checksums from your site’s folder. We tried it on a throwaway test install of the current WordPress. On the clean install, it reported that WordPress verifies against the checksums. Then we added one line to wp-includes/functions.php and put a new file in wp-includes. The WordPress.org FAQ notes that hacks often add new files, so we tested both cases. The command named both files, with “File doesn’t verify against checksum” for the edited one and “File should not exist” for the new one, and it ended with an error.

It also flagged one extra file that our test setup had placed in the site’s main folder. Extra files are not always malware, so read each warning before you delete anything.

If you have no command line, do what the FAQ suggests. Download the same WordPress version you run from WordPress.org, then upload fresh wp-admin and wp-includes folders over SFTP, replacing the old folders completely. Do not use the reinstall button in the dashboard for this. The FAQ explains that installers only overwrite existing files, while hacks often add new ones.

Check plugins and themes

For plugins from the WordPress.org directory, WP-CLI’s plugin verify-checksums command does the same check against WordPress.org’s copy. Paid plugins and themes have no checksums there, so delete them and download fresh copies from the seller.

On the same test install, we changed one line in WooCommerce’s main file and added a new file to its includes folder. The plugin check listed both, as “Checksum does not match” and “File was added”.

Delete any plugin or theme you do not use. The hardening guide says to remove unused plugins, and a deleted plugin cannot be exploited. Delete anything you do not remember installing.

Check the files hackers change most

The FAQ names .htaccess as one of the files most often changed, whatever the type of infection. It can sit in your site’s main folder and in other folders too. It also names index.php, and your theme’s header.php, footer.php and functions.php, because a change in any of them affects every page.

For a redirect hack, look for these:

• Rewrite or redirect lines in any .htaccess file that send visitors to a domain you do not know.
• Script tags pointing to unknown domains in your theme files, in widgets and in the content of posts and pages.
• The WordPress Address and Site Address under Settings, General. Both should show your own domain.
• PHP files inside wp-content/uploads. That folder holds your media. A PHP file there deserves a close look.

How do you find admin users the hacker added?

Open Users in the dashboard and filter by Administrator. Delete any account you do not recognise, and when WordPress asks, give its content to your own account. Then check the other roles, because an attacker may also create an Editor.

If the attacker locked you out, the FAQ suggests using phpMyAdmin from your hosting panel. It lets you open the wp_users table, change your own account’s email to one you control, and then use “Lost your password” on the login screen.

How do you stop it from happening again?

Most of this comes from WordPress.org’s hardening guide:

• Update WordPress, plugins and themes. The guide says older versions are not maintained with security updates, and once a fix is released, the details of the flaw are almost certainly public.
• Install plugins and themes only from trusted sources, which the guide defines as the WordPress.org directory or well-known companies.
• Turn off the file editor. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. The guide says the dashboard’s theme and plugin editor is often the first tool an attacker uses after logging in.
• Use long, unique passwords and two-step login for every administrator.
• Use SFTP, not plain FTP, so your password is never sent unencrypted.
• Scan your own computer. Both WordPress.org guides warn that malware on your own computer can steal your logins, and no server setting helps against that.
• Keep backups you can restore, with copies away from the server.

A server-side malware scanner helps you find a hack sooner. Our WordPress hosting plans include Imunify360 malware scanning for this reason. A scanner does not fix the out-of-date plugin that let the attacker in, so the updates above still matter most.

How do you remove a Google warning after a hack?

If Google flagged your site, open the Security Issues report in Google Search Console. It lists what Google found, with example pages. Fix every issue on every page, then select Request Review in the report and describe what you fixed. Google says a security review can take from a few days to a few weeks. Request the review only once the site is clean.

Frequently asked questions

Will changing my WordPress password remove the hack?

No. A hack usually leaves files, users or database entries behind that work without your password. Change passwords, replace the security keys, and then find and remove what the attacker changed.

Can I reinstall WordPress from the dashboard to clean it?

Not on its own. WordPress.org’s FAQ says the dashboard installer only overwrites existing files, and hacks often add new ones. Replace the wp-admin and wp-includes folders completely with the same version from WordPress.org.

How do I log out everyone, including the hacker?

Replace the eight security keys in wp-config.php with a fresh set from WordPress.org’s key generator. That invalidates every login cookie, so everyone has to log in again.

Will restoring a backup fix my hacked site?

Only if the backup is from before the hack began, and only if you restore both the files and the database. Update everything and change all passwords straight after, because the restore brings back the weakness the attacker used.

How long does Google take to remove the hacked site warning?

Google says a security review takes from a few days to a few weeks. Request it from the Security Issues report in Search Console once every issue is fixed.