WordPress Site Hacked? A Full Recovery Playbook From Containment to Hardening

Signs That Confirm a Compromise

Not every hack announces itself with a defaced homepage.

Subtle indicators show up first – unexpected admin accounts in the Users table, Google Search Console warnings about injected spam, a sudden traffic spike from countries that have nothing to do with the target audience, or redirect chains that only trigger on mobile devices. The classic white screen of death can also signal file corruption caused by injected code. Browser-level malware warnings from Chrome or Firefox Safe Browsing are a clear confirmation. Check the .htaccess file for redirect rules that were never added manually, and look at header.php, footer.php, and functions.php for eval() calls or base64-encoded strings.

A quick remote check through Google’s Transparency Report or Sucuri SiteCheck reveals whether the domain has already been blacklisted.

Containment: Stop the Bleeding

Every minute a compromised site stays live increases the damage – visitors get infected, search engines flag more URLs, and the attacker’s foothold deepens. The first action is enabling maintenance mode to block public access. If dashboard access still works, a maintenance plugin handles this in seconds. If not, dropping a .maintenance file into the WordPress root directory achieves the same result without touching PHP.

<?php
$upgrading = time();

That single file tells WordPress to display a maintenance message to all visitors.

Contact the hosting provider immediately. Many managed hosts keep server-level snapshots for 7-30 days, and those snapshots might predate the infection. Requesting a restore point buys time. Change every credential associated with the site: WordPress admin password, database user password, FTP/SFTP credentials, hosting panel login, and any linked email accounts. Assume all of them are compromised.

Forensic Scanning Before Any Cleanup

Deleting suspicious files without understanding the scope of the infection leads to reinfection within days.

Start with a WP-CLI and SSH session and run a core checksum verification. This command compares every installed core file against the official WordPress checksums:

wp core verify-checksums

Any file that fails verification has been modified or does not belong in the installation. Flag those files but do not delete them yet – they are forensic evidence. Run a secondary scan for common malware signatures across the entire WordPress directory:

grep -r "eval(base64_decode" /path/to/wordpress --include="*.php"
grep -r "assert(" /path/to/wordpress --include="*.php"
grep -r "gzinflate" /path/to/wordpress --include="*.php"

These three patterns catch the majority of obfuscated backdoors. The SSH-based malware detection workflow covers more advanced grep patterns for edge cases like encoded iframes and rogue file inclusions.

Check the uploads directory for PHP files – they should never exist there:

find /path/to/wordpress/wp-content/uploads -name "*.php" -type f

List all files modified in the last 7 days to find the attacker’s trail:

find /path/to/wordpress -type f -mtime -7 -name "*.php"

Replacing Core Files and Plugins

Once scanning is complete, the safest approach is a full core replacement. Download a clean copy of the exact WordPress version running on the site and overwrite everything except wp-content and wp-config.php:

wp core download --version=6.7 --skip-content --force

Delete all plugins from the file system and reinstall them from the WordPress repository. Do not reactivate them yet. Themes follow the same pattern – delete, download fresh copies, reinstall. The wp-content/uploads directory stays untouched during this phase because post attachments live there, but any PHP file found inside uploads during the scanning phase must be removed.

Verify plugin integrity after reinstallation by running checksum comparisons:

wp plugin verify-checksums --all

Plugins not available in the official repository cannot be verified this way and need manual code review.

Database Decontamination

File-level cleanup misses injections buried in the wp_posts, wp_options, and wp_usermeta tables.

Search the database for script tags, iframes, and suspicious URLs. Using WP-CLI for bulk database operations simplifies this process. Run a search through post content for common injection patterns:

wp db search "<script" --all-tables
wp db search "eval(" --all-tables
wp db search "base64_decode" --all-tables

Look at the wp_options table for entries you did not create – attackers frequently store command-and-control URLs in option rows with innocuous-sounding names. Check wp_users for accounts that should not exist, especially any with administrator privileges. Remove rogue users and revoke all application passwords:

wp user list --role=administrator

Compare the output against the known list of legitimate admins. Any unknown account is a backdoor that needs immediate deletion.

Pharma hacks and Japanese SEO spam inject thousands of fake posts into the database. These are SQL injection artifacts that need surgical removal through direct SQL queries rather than the WordPress admin interface. Export the database before running any DELETE statements.

Hardening After Cleanup

The vulnerability that allowed the breach still exists unless explicitly patched.

Update WordPress core, every plugin, and every theme to the latest version. Remove plugins and themes that are no longer maintained or that have known unpatched vulnerabilities. Disable XML-RPC if the site does not use it for remote publishing – it remains one of the most exploited entry points for brute-force attacks. Disable the file editor in wp-config.php to prevent code changes through the dashboard:

define('DISALLOW_FILE_EDIT', true);

Set strict file permissions: 644 for files, 755 for directories, and 600 for wp-config.php. Implementing two-factor authentication on admin accounts blocks credential-based attacks even if passwords leak again. Restrict wp-admin access by IP through .htaccess or server-level firewall rules when the admin team works from fixed locations.

Rotate all WordPress salts and authentication keys. WP-CLI handles this in one command:

wp config shuffle-salts

This invalidates every active session, forcing all users – including any attacker with a stolen cookie – to re-authenticate.

Reputation Recovery and Monitoring

Google and browser vendors maintain separate blacklists, and removal from each follows its own process.

Submit a review request through Google Search Console after confirming the site passes a clean scan. Google typically processes these requests within 72 hours, but sites flagged as repeat offenders face a 30-day lockout before a new review is accepted. Run the site through Sucuri SiteCheck, VirusTotal, and Norton Safe Web to confirm clean status across multiple databases. Bing Webmaster Tools has its own malware review process that runs independently from Google’s.

SEO damage from a hack includes deindexed pages, injected spam URLs still cached in search results, and a potential manual penalty. Submitting an updated sitemap through Search Console accelerates reindexing of legitimate content. If the hack created thousands of spam pages, those URLs return 404 or 410 status codes after cleanup – submitting a removal request for the spam URL patterns speeds up cache clearing.

Install a monitoring solution that checks file integrity, login attempts, and outbound connections on a scheduled basis. Security plugins like Wordfence or Sucuri run automated scans, but server-level monitoring through tools like OSSEC or Maldet catches threats that plugin-based scanners miss. Hosting on an environment with proper security configuration reduces the attack surface before any plugin is even installed.

Backup Strategy That Actually Works

A hacked site without backups turns a 4-hour recovery into a multi-day rebuild.

Automated daily backups stored off-site – not on the same server as the WordPress installation – are the minimum. Use a plugin like UpdraftPlus or a host-level solution that keeps at least 30 days of snapshots. Store copies in two separate locations: a cloud bucket (S3, Google Cloud Storage) and a local drive. Test restores quarterly. A backup that fails to restore is not a backup. Verify that both the database export and the file archive produce a working site when deployed to a staging environment. The cPanel hosting environment offers built-in backup tools, but relying solely on host-managed backups adds a single point of failure.

Separate the backup credentials from the WordPress admin credentials so that a compromised site cannot also compromise the backup chain.

Често задавани въпроси