WordPress Hacked: The Step-by-Step Recovery Protocol

Find Your Situation: What Are You Seeing Right Now?

Different hack types require different starting points. The redirect hack that sends visitors to a casino site is a different infection pattern from the pharma hack that injects fake pages into Google. Starting with the right section saves hours. Use the table below to identify what you are dealing with and jump to the correct step.

Section 1: Immediate Triage — Do These Four Things Before Anything Else

The temptation after discovering a hack is to start deleting files. Resist it. Rushed file deletion removes your forensic evidence, can break the site completely, and often misses the actual malware while deleting legitimate files. The four steps below take under 15 minutes and set up everything that makes the actual cleanup faster and more complete.

// Temporary maintenance mode — remove after recovery is complete
function whr_maintenance_mode() {
    if ( ! current_user_can( 'edit_themes' ) || ! is_user_logged_in() ) {
        wp_die(
            'Site temporarily unavailable. Back soon.',
            'Maintenance',
            array( 'response' => 503 )
        );
    }
}
add_action( 'get_header', 'whr_maintenance_mode' );

Section 2: The Recovery Protocol — Six Steps in Sequence

The recovery protocol below is sequential. Skipping steps or doing them out of order is how re-infections happen: a backdoor left in step 3 survives the database clean in step 4 and restores the malware within hours. Complete each step fully before moving to the next.

Step 1: Run a Malware Scan

The first scan is reconnaissance. Before you delete anything, you need a complete picture of what is infected. A scan that shows 3 files infected is not the same situation as a scan that shows 47 files infected across multiple plugins and your theme directory. The scope changes the recovery approach.

After the scan runs, look specifically for these four categories in the results:

• Modified core WordPress files in /wp-admin/ or /wp-includes/ — any file there that differs from the clean WordPress release is compromised
• PHP files in /wp-content/uploads/ — no legitimate PHP belongs in the uploads directory. Every match here is a backdoor or webshell.
• Obfuscated code — looks like eval(base64_decode('...')) or $_GET[chr(99)](${'_POST'[1]}) — these are backdoors hiding their function
• Unknown admin user accounts — the scan may flag these or you will find them in step 2

Step 2: Remove Unknown Admin Users

Attackers who gain database access create admin accounts as persistent backdoors. They are invisible to site visitors but give the attacker re-entry even after all infected files are cleaned. This step must happen before file cleaning because an attacker with a working admin account can re-upload malware after you clean it.

1. WordPress Admin then Users then All Users
2. Filter by Role: Administrator
3. Review every account. Any admin you did not create: hover, click Delete
4. Check registration email addresses — attacker accounts typically use random Gmail, Proton, or temp-mail addresses
5. Check Settings then General then Membership — if "Anyone can register" is enabled and you did not intentionally enable it, turn it off

If admin access is unavailable (locked out), remove attacker accounts directly via phpMyAdmin:

-- List all admin accounts with registration date (newest first):
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

-- If you see an account you did not create, note its ID and delete:
DELETE FROM wp_users WHERE ID = [attacker_user_id];
DELETE FROM wp_usermeta WHERE user_id = [attacker_user_id];

Step 3: Clean or Restore Core WordPress Files

Core file modification is how most redirect hacks persist: the attacker edits a file in /wp-admin/ or /wp-includes/ to execute their payload every time WordPress loads. The scan results tell you which files were changed. This step replaces them with verified clean versions.

After restoring core files, scan for backdoors in your theme and plugin files. These survive a core reinstall because they are in /wp-content/, which core reinstall does not touch:

# Search for the most common backdoor signatures:
grep -r "eval(base64_decode" /path/to/wordpress/wp-content/
grep -r "system(" /path/to/wordpress/wp-content/
grep -r "passthru(" /path/to/wordpress/wp-content/
grep -r "shell_exec" /path/to/wordpress/wp-content/
grep -r "assert(" /path/to/wordpress/wp-content/

# Find PHP files modified in the last 7 days (suspicious recent changes):
find /path/to/wordpress/wp-content/ -name "*.php" \
  -newer /path/to/wordpress/wp-config.php \
  -not -path "*/cache/*" \
  | sort -k6 -r | head -30

# Each match needs manual review.
# Legitimate plugins rarely use eval(base64_decode) or passthru.
# The ones that do will have it documented in their source.

Step 4: Clean the Database

File cleaning without database cleaning is incomplete recovery. The Sucuri 2024 Website Threat Report found that over 40% of WordPress infections include a database component — most commonly injected siteurl values that redirect visitors, spam links injected into post content, and malicious JavaScript stored in wp_options. A cleaned set of files with a dirty database means the site still redirects visitors and still serves spam links.

Start with the four most critical database checks. Run these in phpMyAdmin under your database's SQL tab:

-- 1. Verify the site URL has not been hijacked:
SELECT option_name, option_value 
FROM wp_options 
WHERE option_name IN ('siteurl', 'home', 'admin_email', 'blogdescription');
-- Expected: siteurl and home both point to your real domain.
-- If either points elsewhere: that is your redirect hack. Update them:
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';

-- 2. Check for injected code hiding in wp_options:
SELECT option_name, LEFT(option_value, 300) 
FROM wp_options 
WHERE option_value LIKE '%base64_decode%' 
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%<script%'
   OR option_value LIKE '%document.write%';
-- Any row returned here contains injected malware. Delete the row if the
-- option_name is not a known WordPress or plugin option.

-- 3. Check post content for spam link injection:
SELECT ID, post_title, post_status, LEFT(post_content, 200)
FROM wp_posts 
WHERE post_content LIKE '%<a href%'
  AND (post_content LIKE '%casino%' 
    OR post_content LIKE '%viagra%' 
    OR post_content LIKE '%pharmacy%'
    OR post_content LIKE '%payday loan%')
  AND post_status = 'publish';
-- Any result here is SEO spam injection into your posts.

-- 4. Find injected script tags in published content:
SELECT ID, post_title 
FROM wp_posts 
WHERE post_content LIKE '%<script%'
  AND post_status = 'publish';

For spam links injected across many posts — which is common in SEO spam hacks — Better Search Replace handles bulk removal without SQL knowledge. Install it from the WordPress plugin directory, run a dry-run search for the attacker's domain, verify the count of occurrences, then run the actual replace with an empty string. The dry-run mode shows you exactly how many rows are affected before any changes are made.

Step 5: Clean the /uploads/ Directory

The /uploads/ directory is the most common location for webshells and PHP backdoors after a file upload vulnerability is exploited. No legitimate PHP file belongs in /uploads/. Every PHP file found there is malicious — no exceptions, no investigation needed before deletion.

# List all PHP files in uploads — review before deleting:
find /path/to/wordpress/wp-content/uploads/ -name "*.php" -type f

# Common webshell names to look for specifically:
find /path/to/wordpress/wp-content/uploads/ \
  -name "*.php" -o -name "c99*" -o -name "r57*" \
  -o -name "shell*" -o -name "wso*" | head -20

# Once confirmed: delete all PHP files in uploads:
find /path/to/wordpress/wp-content/uploads/ -name "*.php" -type f -delete

# Confirm deletion worked:
find /path/to/wordpress/wp-content/uploads/ -name "*.php" -type f
# Expected output: nothing. Zero files returned.

After removing PHP files from uploads, create a permanent block that prevents any PHP file in uploads from executing even if an attacker uploads one again. This is the hardening step that closes the upload directory attack vector permanently. Create this file:

# Block PHP execution in uploads directory.
# Any PHP file uploaded here will not execute.
<Files *.php>
    deny from all
</Files>

Step 6: Update Everything — Then Delete What You Are Not Using

After cleaning, every component in your installation needs to be at its latest version. The vulnerability that allowed the original compromise is almost certainly a known issue with a patch available. Installing the update closes the specific door the attacker used.

1. WordPress core — Dashboard then Updates. Confirm you are on the latest release.
2. All plugins — Dashboard then Updates then select all then Update Plugins. Check each plugin's changelog for recent security fix mentions — that is where your vulnerability likely was.
3. All themes — Dashboard then Updates then Themes. Include inactive themes.
4. Delete inactive plugins — deactivated plugins are still readable by PHP and still exploitable. If you are not using it, delete it. Appearance then Themes: delete every theme except your active one and one backup theme.
5. Remove nulled/pirated plugins or themes — if any component came from outside the official plugin directory or the developer's own site, delete it now. Nulled plugins ship with pre-installed malware in approximately 80% of cases examined by Sucuri researchers.

Section 3: If Your Hosting Account Was Suspended for Malware

Hosting suspension for malware is common, it is fixable, and most hosts unsuspend within 1 to 24 hours of confirmed removal. The workflow below applies to the three most common hosting types: shared cPanel hosts, managed WordPress hosts, and cloud platforms like Cloudways. The key rule: fix the issue before contacting support. Hosts run an automated rescan before unsuspending — if a single infected file remains, the account stays suspended and the support ticket resets to the back of the queue.

How to Access Your Files When the Site Is Suspended

Shared and cPanel hosting: cPanel itself stays accessible even when your website is suspended. Log into cPanel directly — typically yourdomain.com/cpanel or via the URL in your original welcome email. File Manager shows all your WordPress files and lets you edit, delete, and upload. The suspension blocks web visitors; it does not block your own cPanel access.

Cloudways: SSH and SFTP remain accessible during suspension. Your application's SSH credentials are in Cloudways Dashboard then Applications then Access Details. Connect via SFTP client (FileZilla, Cyberduck) and navigate to the public_html directory. Cloudways support also responds to security-related tickets faster than average because managed hosting security support is part of their offering.

ScalaHosting managed VPS: SPanel remains accessible during WordPress-level issues. SSH access stays functional. Their support team actively assists with malware removal as part of their managed service — open a security ticket with "malware cleanup request" and you will get a response within the support SLA. This is one of the concrete differences between managed and unmanaged hosting when security incidents happen. The managed versus unmanaged VPS guide covers the full breakdown of what managed hosting includes in these scenarios.

What to Say to Your Host When Requesting Unsuspension

Specificity matters. A vague "I think I fixed it" delays the response. A specific ticket that names the files removed gets a faster review. This template works:

Section 4: If Google Blacklisted Your Site

A Google blacklist means Chrome shows "This site may harm your computer" or "Deceptive site ahead" before visitors reach your pages. Organic traffic collapses immediately because the warning stops roughly 95% of clicks. The warning does not self-resolve after you clean the malware — you must manually request a review. The review takes 24 to 72 hours. During that window, the warning stays visible.

The Exact Sequence to Remove Google's Blacklist Warning

1. Complete Sections 2 and 3 first. Do not request a review before the malware is gone. If Google rescans and finds anything remaining, the review fails and the window resets. You want to submit one clean review request, not multiple failed ones — repeated failed reviews signal a persistent problem and can extend the review timeline significantly.
2. Open Google Search Console. If your site is not verified, add it now via DNS TXT record (fastest verification method — under 10 minutes via your DNS manager or Cloudflare dashboard).
3. Navigate to Security and Manual Actions then Security Issues. Google's flagged URLs and descriptions are here. Read them carefully — they show which specific pages were flagged and what Google detected. This is your checklist for confirming the issue is fully resolved.
4. Verify every flagged URL is clean. Visit each URL Google listed. Check the page source for any injected scripts. Run Sucuri SiteCheck on your domain for external confirmation.
5. Click "Request a Review." Write a specific description: "I identified and removed [describe what you found — redirect hack / injected spam links / etc.]. Specific actions: [list your cleanup steps]. All infected files deleted, database cleaned, all passwords rotated, all components updated."
6. Wait for the review. Google sends an email when the review is complete. Do not resubmit while a review is pending — it resets the queue position.

Why Is Other Blacklists After Google Clears

Google's safe browsing verdict carries significant weight with other security vendors. McAfee SiteAdvisor, Norton Safe Web, ESET, and Yandex Safe Browsing all reference Google's feed as one input. Most auto-remove a site from their blacklists within 24 to 48 hours after Google's review completes. You do not need to manually submit removal requests to most of them.

Sucuri Blacklist Checker (sitecheck.sucuri.net) shows your site's status across multiple vendors simultaneously. Run it after Google confirms your review is approved. If any secondary vendor still shows a warning after 72 hours, visit that vendor's specific removal portal. Norton Safe Web, McAfee SiteAdvisor, and Yandex each have a URL submission form for dispute requests.

Section 5: Harden Against Re-infection — Do All of These Before Going Back Online

Most WordPress sites that get re-hacked within 30 days of recovery were cleaned but not hardened. Cleaning removes the current infection. Hardening closes the structural vulnerabilities that made infection possible. The average re-infection window on a cleaned-but-not-hardened site is under 72 hours. The steps below take under 2 hours total and need to happen before you take the site out of maintenance mode.

5a. Rotate WordPress Secret Keys in wp-config.php

WordPress secret keys are used to encrypt session cookies. If an attacker's existing session cookie was created before you rotated these keys, that session remains valid after every other cleanup step. Rotating the keys invalidates all existing sessions simultaneously — including every active session the attacker holds.

/* Step 1: Visit this URL to generate fresh keys:
   https://api.wordpress.org/secret-key/1.1/salt/
   
   It generates output like this (yours will be different):
*/
define('AUTH_KEY',         'x0I1 ~:t5#Tr^GfH=fFiZy-q%0+Y;|4v)n8%}FWB@1xo');
define('SECURE_AUTH_KEY',  'x9pX7$w%RiBV+GsT!^5m&L|y6Qz2uH_F9');
define('LOGGED_IN_KEY',    'Q7-8|5.Ft>3$cBnRpJ{&hK...etc');
define('NONCE_KEY',        '...generate new values for all eight...');
define('AUTH_SALT',        '...');
define('SECURE_AUTH_SALT', '...');
define('LOGGED_IN_SALT',   '...');
define('NONCE_SALT',       '...');

/* Step 2: In wp-config.php, find the existing KEYS AND SALTS section
   and replace ALL eight lines with the freshly generated output.
   
   Edit wp-config.php via:
   - cPanel File Manager (right-click the file then Edit)
   - SFTP client
   - SSH: nano /path/to/wordpress/wp-config.php
*/

5b. Lock Down wp-config.php File Permissions

wp-config.php contains your database credentials, secret keys, and table prefix. It should never be world-readable. The correct permission is 400 (owner read-only) or 440 (owner and group read-only). Most WordPress installations ship with 644 or 640 — readable by any process on the server.

# Set wp-config.php to owner read-only (most restrictive):
chmod 400 /path/to/wordpress/wp-config.php

# Verify the change:
ls -la /path/to/wordpress/wp-config.php
# Expected output: -r-------- 1 username username ... wp-config.php

# If 400 breaks your site (some server configs require write access):
chmod 440 /path/to/wordpress/wp-config.php

5c. Enable Two-Factor Authentication on Every Admin Account

2FA is the single configuration change with the highest impact on preventing re-infection via credential attacks. An attacker who recovered your old password through a session, a keylogger, or a breach database cannot log in without the second factor. Two-factor authentication makes credential stuffing, brute force, and leaked password attacks irrelevant simultaneously.

Install WP 2FA (free, 100,000+ active installations, maintained by Melapress). Configure: Enforce 2FA for all Administrator roles. Set a 3-day grace period so existing admins can set up their TOTP before being locked out. Use TOTP (Google Authenticator, Authy, or any TOTP app) rather than email-based codes — TOTP works without email delivery and cannot be intercepted via a compromised email account.

5d. Install a Security Plugin with an Active Firewall

A security plugin sits between incoming requests and WordPress and blocks attack patterns before they execute. WordFence and MalCare are the two credible options. Both run an application-layer firewall that blocks brute force, SQLi attempts, and known exploit patterns. Do not install both — they intercept the same request pipeline and running both simultaneously does not improve detection coverage while adding real server overhead.

WordFence Free — Web Application Firewall with 30-day delayed rule updates, malware scanner, login protection, and 2FA via WordFence Login Security. Correct choice for sites that are now clean and need prevention going forward. Install, run the initial scan, accept the firewall optimization prompt (moves WordFence to load before WordPress, increasing blocking effectiveness).

WordFence Premium ($119/year) — Real-time firewall signatures. When a new WordPress plugin vulnerability is disclosed and attackers start scanning for it within hours of the CVE announcement, Premium gets the blocking rule immediately. The free tier gets it 30 days later. For any site processing e-commerce or storing personal data, real-time rules are worth the cost. One blocked attack typically covers the annual subscription.

MalCare ($99/year) — Better detection for obfuscated and encoded malware. If you experienced an infection that a basic scanner missed, MalCare's cloud-based analysis is worth running as the ongoing monitoring tool. Their login protection and firewall cover the same ground as WordFence's application layer.

5e. Enable Cloudflare — the Network Layer That Stops Attacks Before They Reach WordPress

A plugin-level firewall runs after the request arrives at your server. Cloudflare runs at the DNS layer — it intercepts requests before they reach your server at all. Volumetric DDoS, known malicious IP ranges, and bot traffic are absorbed at Cloudflare's edge network, which has over 300 Tbps of capacity. Your server never processes the attack traffic.

Cloudflare free tier: add your domain, point your nameservers to Cloudflare's nameservers, enable Always Use HTTPS, enable Bot Fight Mode. This alone blocks the majority of automated attack traffic with zero ongoing cost. Configure a rate limiting rule on /wp-login.php: 5 requests per 10 minutes per IP, block for 1 hour. This single rule stops brute force at the network edge without loading WordPress at all.

Cloudflare Pro at $20/month adds the OWASP Core Rule Set — a curated set of firewall rules targeting SQLi, XSS, and protocol-level attack patterns. For any site generating revenue, Pro is the correct configuration after a compromise. The WAF blocks attack patterns that would otherwise reach WordFence, reducing server load in addition to improving security coverage. The CDN guide covers the full Cloudflare setup sequence for WordPress including cache configuration, performance settings, and firewall rule priority.

5f. Additional Hardening Items That Take Under 10 Minutes Each

Section 6: The Monitoring Stack — Set These Up Once and Let Them Watch

The monitoring tools below alert you within minutes of the conditions that indicate a new attack or re-infection. Set them up in a single session after the recovery is complete. Combined, they cost nothing beyond about 45 minutes of setup and cover the detection gap that allowed the original hack to run undetected. A site without monitoring relies on a visitor email to detect its next compromise. That is a detection window measured in days to weeks.

The Backup Strategy That Makes Disaster Recovery Actually Work

Monitoring detects problems. Backups determine whether a future compromise costs you 2 hours or costs you everything. Three properties make a backup strategy real rather than theoretical:

Off-site storage. A backup stored on the same server as your WordPress installation gets encrypted or deleted in a ransomware attack. Google Drive, Dropbox, and Amazon S3 are all valid off-site targets. UpdraftPlus (free) supports all three. Configure it to send backups to Google Drive — it is free for up to 15 GB and takes under 5 minutes to authorize.

30 days of retention minimum. Some infections run silently for weeks before becoming visible. If you discover a compromise today that started 3 weeks ago, you need a backup from 4 weeks ago to have a clean restore point. A 7-day retention window is not sufficient for this scenario. UpdraftPlus free tier supports custom retention counts — set it to 30 daily backups.

Tested restores. An untested backup is a hypothetical backup. Every 90 days, download one of your backups and restore it to a staging environment. The WordPress multisite or a free Cloudways trial server work for this. If the restore fails, you find out now rather than during the emergency when it matters. This is the check that most WordPress site owners never run — and it is the most important one.

UpdraftPlus configuration for the setup described above: install the free plugin, Settings then UpdraftPlus then Settings, set Backup Schedule to Daily for both files and database, set Backup Retention to 30, connect to Google Drive under Remote Storage and authorize the connection. Total setup time: under 15 minutes. The backup and restore guide covers the complete UpdraftPlus configuration including multiple storage destinations, scheduled backups, and restore verification procedures.

Recovery Myths That Cause Re-infection

These are the specific beliefs that lead people to incomplete recoveries. Each one sounds reasonable. Each one leaves a specific gap that attackers exploit within days of a "completed" cleanup.

After Recovery: Building the Foundation That Prevents This from Happening Again

You have been through the complete recovery protocol. The cleanup is done. If you followed the hardening steps in Section 5, you have closed the structural vulnerabilities that made the original compromise possible. Three resources support what comes next:

The WordPress security threats guide covers the four primary attack vectors in detail — DDoS, brute force, SQL injection, and XSS — with live detection commands, log analysis, and prevention configuration for each. If you want to understand how to recognize an attack before it becomes a compromise, that guide provides the detection signatures. The managed versus unmanaged VPS guide covers how your hosting type affects the baseline security posture you are working with — managed hosts apply server-level security patches automatically and often include security assistance as part of the service, which changes the calculation when evaluating hosting after a security incident. The backup and restore guide covers the complete UpdraftPlus configuration, multi-destination backup setup, and restore testing procedures — the operational foundation that determines whether a future compromise costs 2 hours or costs everything.

If you are evaluating whether your current hosting provides the right security posture for your site going forward, the options that stood out in our testing for managed security support and fast response to security issues: ScalaHosting's managed VPS includes SShield security and active malware assistance as part of managed support. Cloudways provides SSH access, server-level firewalls, and active security support across five cloud providers — the right choice when you want managed infrastructure with control over your configuration. Both are meaningfully different from shared hosting when a security incident requires fast access and expert support.