WordPress Hacked? How to Clean Up and Recover Safely

You've noticed something's off - Chrome is showing a red warning, Google Search Console flagged "deceptive content," or a customer emailed asking why your site redirects to a pharmacy ad. Your WordPress site has been hacked. Before you panic and reach for the delete key, here's exactly how to confirm it, clean it up properly, and stop it from happening again.

The warning signs of a hacked WordPress site

Hacks rarely announce themselves with a ransom note. Most are quiet, because the attacker wants your site's traffic or server resources, not your attention. Watch for:

• Google Chrome or Search Console showing "This site may be hacked" or "Deceptive site ahead"
• Random redirects to spam, adult content, or fake pharmacy sites - often only on mobile, or only for visitors coming from Google search
• New admin users in Users that nobody on your team created
• Unfamiliar plugins or a wp-content/uploads folder full of .php files
• The server suddenly maxing out CPU or bandwidth for no obvious traffic reason
• Your host emails you about a spam-sending script or a suspended account
• Search results showing garbled Japanese/Russian keywords stuffed into your page titles

If you're seeing any of these, treat it as confirmed until proven otherwise. Waiting to be "sure" just gives the infection more time to spread and get re-indexed by Google.

Step 1: Contain it before you touch anything else

Do these three things immediately, in this order:

1. Change every password. WordPress admin, cPanel, FTP/SFTP, and the database user. Assume all of them are already known to the attacker.
2. Put the site in maintenance mode or restrict access via .htaccess if the malware is actively serving spam to visitors - you don't want Google re-crawling infected pages while you work.
3. Take a full backup right now, even though it's infected. In cPanel, go to Backup Wizard > Download a Full Website Backup. You need this as a fallback and as evidence of what was injected, before you start deleting things.

Step 2: Find what was actually changed

You can't clean what you can't find. The fastest way to spot injected files is to sort by modification date.

In cPanel's File Manager, there's no built-in "sort by date" view across the whole site, so use SSH or the Terminal app if your plan includes it:

find /home/username/public_html -type f -mtime -14 -name "*.php" -printf "%T@ %p\n" | sort -n

This lists every PHP file modified in the last 14 days, oldest first. On a site that hasn't been updated recently, a batch of files all touched on the same day - especially inside wp-content/uploads, which should never contain .php files at all - is your smoking gun.

If you have WP-CLI access, compare WordPress core files against the official checksums:

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

Anything flagged as modified in core files (not a normal update, a checksum mismatch) is either corruption or tampering.

Also grep for the classic injection patterns - obfuscated malware almost always uses one of these functions to hide itself:

grep -rl "eval(base64_decode" /home/username/public_html
grep -rl "gzinflate(base64_decode" /home/username/public_html
grep -rl "assert(\$_POST" /home/username/public_html

Step 3: Clean up - the safe order of operations

Step 4: Check the database, not just the files

Malware doesn't always live in files - it often sits in the database too, especially in wp_options and wp_posts. Open phpMyAdmin from cPanel and search across the database for:

• <script> tags inside post content that you didn't add
• Suspicious entries in wp_options with names like widget_texts, _transient_random-string, or anything containing base64-looking strings
• Extra rows in wp_users or wp_usermeta granting administrator capability to an account you don't recognize

If you're not confident reading raw SQL, a security plugin scan (Wordfence or Sucuri, free tiers are fine for this) will flag most database-level injections and let you review them before deleting.

Step 5: When cleanup is too messy, restore instead

If the infection is old, widespread, or you simply can't find every trace, don't keep chasing it file by file. Restore from a backup taken before the compromise - check cPanel's file modification dates from Step 2 to figure out roughly when it started, then go back further than that. A clean restore plus a hardened re-launch is faster and safer than an incomplete manual clean that gets reinfected in a week.

Step 6: After it's clean, rotate everything again

Once the site is confirmed clean:

• Regenerate your WordPress security keys and salts in wp-config.php (WordPress.org has a free secret-key generator) - this invalidates any stolen session cookies
• Change passwords a second time, now that you know the malware is gone and the new ones won't leak straight back to the attacker
• Revoke and reissue any API keys stored in plugins (payment gateways, SMTP services, backup tools)
• Remove any admin users you don't recognize - don't just demote them, delete them

Prevention: don't do this twice

Most reinfections happen because the entry point was never closed, not because the cleanup was incomplete. Update every plugin and theme immediately, remove anything you're not actively using, enable two-factor authentication for all admin accounts, and set a weekly backup schedule you can actually roll back to. If you skipped straight to this article without a hardening pass, that's the next thing to do.

Prevention checklist for next time

• Keep WordPress core, plugins, and themes on auto-update or check weekly
• Never install nulled/pirated premium plugins or themes
• Use unique, generated passwords and 2FA on every admin account
• Set file permissions to 644 for files and 755 for directories - never 777
• Keep off-site backups with at least 14 days of history so you always have a clean restore point
• Install a security plugin that scans on a schedule, not just on demand

A hack is stressful, but it's rarely fatal to your site if you work through it methodically: contain, identify, clean or restore, then rotate credentials. Do those four things in order and you'll be back online with a site that's actually more secure than it was before the attack.