WordPress hacked? A step-by-step recovery checklist

First: is it really a hack?

“Hacked” covers a lot of ground, and a broken plugin update can look alarming too. WordPress.org’s own guidance starts with indicators of compromise: things that only happen when someone else is in control. If you see any of these, assume a compromise until you’ve proved otherwise.

Redirects

Visitors (often only from Google or on mobile) land on spam, scam or adult sites

Spam pages

site:yourdomain.com shows pharma, casino or foreign-language pages you never wrote

Unknown admins

Users › All Users lists administrators nobody on your team created

Host action

Your host suspended the site or reports malware, spam or abuse

Google warning

“This site may be hacked” in search results, or a red browser warning

Antivirus alerts

Readers say their antivirus blocks your site

The recovery checklist

Work top to bottom. The order matters: cleaning before you close the entry point is the most common reason sites get reinfected within days. Your ticks are saved in this browser, so you can come back mid-task.

1. Contain and preserve

The instinct is to start deleting suspicious files. Resist it for ten minutes. First, stop the damage: block public traffic at the CDN or server (a password prompt in the web server config, or your host’s “disable site” switch). A maintenance-mode plugin isn’t enough, because it runs inside the very software that’s compromised.

Then take a full copy of the hacked state: files, a database export and the web server and PHP logs. You’ll need it to find the entry point, and it’s a fallback if the cleanup breaks something.

# Files, including dotfiles like .htaccess$ tar -czf ~/incident-$(date +%F)-files.tgz -C /var/www yoursite# Database (WP-CLI)$ wp db export ~/incident-$(date +%F)-db.sql# Logs — paths vary by host$ cp /var/log/nginx/access.log* /var/log/php*-fpm.log* ~/ 2>/dev/null

2. Find the way in

Most WordPress compromises come through one of three doors. Check all three, because closing the wrong one leaves the real one open.

• The server’s software. Unpatched PHP is the obvious one this month: PHP2Shell could give an attacker code execution before WordPress even loads. Confirm your version with our PHP version guide, and ask your host if you’re unsure.
• A vulnerable plugin or theme. Look at what was installed or updated around the time things went wrong, and at abandoned plugins that haven’t had an update in years. Public vulnerability databases list known issues per plugin.
• Stolen credentials. Reused passwords, a leaked hosting login, or malware on the computer of someone who logs in. Your login history (if you have one) and your host’s access logs show unexpected logins.

The access log is the best witness. Find the first suspicious file’s modification time, then look at requests just before it. POST requests to odd URLs, uploads to pages that never take uploads, and requests to files in wp-content/uploads ending in .php are all telling.

# PHP files where only media should be$ find wp-content/uploads -type f -name '*.php'# Everything changed in the last 14 days (newest first)$ find . -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort -r | head -50# Common obfuscation patterns (expect some false positives)$ grep -rlE 'eval\(base64_decode|gzinflate\(base64|str_rot13\(' --include='*.php' .

3. Restore or rebuild

Which route you take depends on one question.

# Which files differ from the official release? --include-root also flags unknown files in the root$ wp core verify-checksums --include-root# Same for plugins from WordPress.org (premium plugins can't be checked this way)$ wp plugin verify-checksums --all# Reinstall core files for your current version, keeping wp-content$ wp core download --force --skip-content --version=$(wp core version)# Reinstall every WordPress.org plugin at its current version$ wp plugin install $(wp plugin list --field=name) --force# Look for scripts injected into posts$ wp db search '<script' --all-tables --stats# Check the site URLs haven't been changed$ wp option get siteurl && wp option get home

4. Rotate every secret

Assume anything stored on, or typed into, the site was seen. Some attacks (PHP2Shell among them) can also leak server memory, which can include passwords and keys that were never written to a file.

1. 1

   Step 1: Remove unknown users and application passwords

   Users › All Users for accounts, and each admin’s profile for Application Passwords. Reassign their content to a real user.
2. 2

   Step 2: Reset every user’s password

   At minimum every administrator and editor. Turn on two-factor login for admins while you’re there.
3. 3

   Step 3: Replace the salts in wp-config.php

   Generate new ones at WordPress.org’s secret key service and paste them over the old AUTH_KEY…NONCE_SALT lines. Everyone, including the attacker, is logged out. Or run wp config shuffle-salts.
4. 4

   Step 4: Change the database password

   In your hosting panel, then update DB_PASSWORD in wp-config.php to match.
5. 5

   Step 5: Change hosting, SFTP and SSH logins

   And remove any SSH keys you don’t recognise from ~/.ssh/authorized_keys.
6. 6

   Step 6: Rotate API keys

   SMTP, payment gateways, analytics, CDN and backup storage. Revoke the old keys rather than just adding new ones.

5. Get back into Google

If Google flagged the site, open Search Console › Security & Manual Actions › Security issues. Google’s guidance is to fix every listed issue across the whole site (the sample URLs may not be complete), then select Request Review and explain what happened, what you fixed and the result. Reviews take from a few days to several weeks, and you’ll get email updates. Don’t resubmit while one is pending.

Spam pages the attacker created should return 404 or 410 once removed. If you used a redirection tool, make sure none of the attacker’s redirects survived in it.

When to hire a professional

Doing it yourself is realistic for a small site with a clean backup. Get help when:

• The site handles payments, member accounts or personal data — you may have legal notification duties, and you need to know what was accessed, not just make the symptoms go away.
• You’ve cleaned it once and it came back.
• You can’t find the entry point, or you don’t have server access to look.
• Several sites on the same account are affected.

Ask any cleanup service how they identify the entry point, whether they keep the forensic copy, and what they guarantee if the infection returns.

Make it not happen again

Once you’re clean, run through the interactive WordPress security checklist: patched PHP, two-factor login, fewer plugins, off-site backups and someone watching the logs cover most of the risk.

It’s also worth asking how much software your site really needs to run. A typical WordPress site depends on the PHP runtime, a MySQL server and a dozen plugins, each with its own update schedule. Presscomet keeps the same wp-admin and URLs but has no PHP runtime and no PHP plugins, so PHP-runtime and PHP-plugin vulnerabilities don’t apply. It still needs its own updates, strong logins and backups, so nobody should call it unhackable. Read the trade-offs in Can you run WordPress without PHP? or on our WordPress security page.