Fix a Hacked WordPress Site Step-by-Step Guide cloudywp
Luke Anderson WordPress

How to Fix a Hacked WordPress Site, Step by Step

To fix a hacked WordPress site, keep a copy of the infected files as evidence, take the site offline, restore from a backup made before the infection, then change every password and key and check that core files, plugins, users and scheduled tasks are clean. Finish by asking Google to re-review the site if it was flagged. The order matters: cleaning files before changing passwords is the most common reason a site is hacked again within days.

This guide is the order we work through on a cleanup. If you are not sure the site is hacked at all, start with the warning signs that point to a compromise and come back here once you are confident.

Step 1: Take a copy, then take the site offline

Before you change anything, download the current files and a database export. Do not plan to restore this copy. It is evidence: it shows what was injected and often how the attacker got in, and a developer will want it if the cleanup needs a second look.

Then stop visitors from hitting the infected site. Most hosts let you password-protect the site folder or switch on a maintenance page from the control panel. If the site takes payments or logins, do this first, before copying anything.

Step 2: Find out how far it goes

If you have SSH access (many Australian hosts offer it on business plans), WP-CLI gives you quick, reliable checks. Run these from the site root.

Compare core and plugin files with the originals

wp core verify-checksums
wp plugin verify-checksums --all

Both commands compare your files against the official copies from WordPress.org and list anything that has been changed or added. Two limits: premium plugins and themes bought elsewhere are not covered, and the commands tell you a file is different, not that it is malicious. Treat every line of output as something to look at.

Look for administrator accounts you do not recognise

wp user list --role=administrator

Delete any account you did not create. If you are unsure about one, note its details before deleting it so you can ask your developer or host.

Look for PHP files where none belong

The uploads folder should hold images and documents, not code. This lists PHP files there that changed in the last two weeks:

find wp-content/uploads -name "*.php" -mtime -14

Widen the number if you think the infection is older. Also look in wp-content/mu-plugins. Must-use plugins load automatically and do not appear in the normal Plugins screen’s active list, which makes them a favourite hiding place.

Check scheduled tasks and settings

wp cron event list

Look for tasks with random names or ones that call code you do not recognise. Reinfection often comes from a scheduled task that quietly rewrites a backdoor after you delete it. Also check wp-config.php and .htaccess for lines you did not add, especially redirects to unfamiliar domains, and check Settings, General to confirm the site address has not been changed.

A search for common obfuscation can also help, though it will not catch everything:

grep -rl "base64_decode" wp-content --include=*.php

Plenty of legitimate plugins use base64_decode, so this gives you a list to inspect, not a list to delete.

If you do not have SSH, a scanner such as Wordfence or Sucuri SiteCheck can list suspicious files and flag blacklisting. SiteCheck is an outside scanner that reads your public pages. It cannot see backdoors that do not show on the front end, so a clean result is not proof the site is clean.

Step 3: Restore from a backup dated before the infection

Last night’s backup is not automatically safe. If the site was compromised two weeks ago, a backup from last night contains the malware. Work out when the first sign appeared (the date of a suspicious file, a new admin account, or a login you do not recognise in your host’s logs) and restore a backup from before that date.

If no clean backup exists, reinstall instead of restoring. Replace WordPress core and your plugins with fresh copies, keeping your content and settings:

wp core download --force --skip-content
wp plugin install plugin-slug --force

Repeat the plugin command for each plugin from WordPress.org. For premium plugins, download a new copy from the vendor. Delete any plugin or theme you no longer use, because abandoned code is a common way in. Your database holds your posts and settings, so inspect it for injected content (spam links in posts, unknown entries in the options table) before you trust it.

Step 4: Change every key and password

Do this after the restore, not before, or you will be locking the door while the attacker is still inside.

  1. Replace the security keys and salts in wp-config.php. With WP-CLI: wp config shuffle-salts. This logs everyone out, including the attacker’s stolen sessions.
  2. Change the database password in your hosting control panel, then update DB_PASSWORD in wp-config.php to match.
  3. Change your hosting account, SFTP and SSH passwords.
  4. Reset the password of every WordPress user, starting with administrators and editors.
  5. Remove any SFTP or SSH accounts and API keys you did not create.

Use a password manager so each one is long and unique. If you reuse a password from another site, assume it is already known.

Step 5: Close the way back in

A cleaned site that still has the original hole will be hacked again. Work out how they got in. The usual causes are an outdated or abandoned plugin, a nulled (pirated) theme or plugin, a weak or reused password, or a compromised account on the same shared hosting server.

  • Update WordPress core, every plugin and every theme.
  • Switch on two-factor authentication for all administrators.
  • Stop the dashboard editing code by adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php.
  • Check file permissions with your host. Folders are normally 755 and files 644.
  • Make sure automatic backups run and are stored away from the web server.

If you cannot find the entry point, assume the cause is still there. That is the point to bring in someone who does this every week: have a developer clean it and close the way back in. Our hacked site cleanup starts from $299.

Step 6: Deal with Google and the search results

Hacked sites often get flagged. In Google Search Console, open Security issues and Manual actions and read what is listed. Search Google for site:yourdomain.com.au and look for pages you did not create, such as pharmacy, casino or foreign language listings. Remove those pages and make sure they return a 404 or 410.

When the site is clean, use the review request on the Security issues or Manual actions page and describe what you found and what you fixed. Reviews take time, so do not resubmit repeatedly. If the site shows a browser warning, the same Search Console report is where you request the review.

Step 7: Report it and check your obligations

In Australia you can report a cyber incident to the government through ReportCyber. It helps if the attack involved fraud or stolen money.

If customer personal information may have been accessed, such as names, addresses, logins or order details, the Notifiable Data Breaches scheme may apply to your business. The OAIC explains who is covered and what to do in its notifiable data breaches guidance. If you think it might apply, get advice early rather than after the cleanup.

Frequently asked questions

Can I fix a hacked WordPress site myself?

Often yes, if it is a small brochure site, you have a clean backup, and you are comfortable with SFTP or WP-CLI. Stop and get help if the site takes payments, holds customer data, keeps getting reinfected within days, or you cannot work out how the attacker got in.

Should I restore from a backup or clean the files by hand?

Restore from a backup made before the infection when you have one. Hand cleaning risks missing a backdoor. If there is no clean backup, reinstall core and plugins from fresh copies and inspect the uploads folder and database by hand.

Why does my site keep getting hacked again?

Almost always because a backdoor, a rogue admin account or a scheduled task survived the cleanup, or because the original hole (usually an outdated plugin or a stolen password) was never closed.

Do I need to tell my customers?

It depends on what data was exposed and your business. The Notifiable Data Breaches scheme may apply if personal information was accessed and serious harm is likely. Check the OAIC guidance or ask a privacy adviser.

Discussion

Be the first to comment

Leave a comment

Get in touch