Fix a Hacked WordPress Site: 9-Step Cleanup That Sticks

Cleaning only what a scanner finds is how hacked WordPress sites end up “cleaned” twice. To fix a hacked WordPress site for good you have to find the way in, not just the files it left behind: the first cleanup removes what the scanner can see, and the malware comes back through a backdoor the scanner missed. It isn’t rare, and it isn’t bad luck. In its 2023 analysis of compromised sites, Sucuri found that 49.21% had at least one backdoor (Sucuri, 2023 Hacked Website Report). Miss that door and you clean the same site next week.

The pressure is real, too. In the second quarter of 2026 alone, Wordfence blocked 10.4 billion firewall attacks and 18.2 billion brute force attacks against WordPress sites (Wordfence, Q2 2026 Threat Intelligence Report). Below is the recovery sequence I follow on client sites, with the exact WP-CLI commands, and it’s built around one idea: close the entry point, not just the mess.

Why do most hacked WordPress cleanups fail?

Because the cleanup deletes the visible malware but leaves the backdoor that invited it in. In its 2023 report, Sucuri found at least one backdoor on 49.21% of the compromised sites it worked on (Sucuri, 2023 Hacked Website Report). A backdoor is a small, innocuous-looking file or database entry that quietly re-downloads the payload after you think you’re finished.

That’s the reinfection engine. A single scheduled task, a stray line in a legitimate file, one rogue admin account, any of them rebuilds the infection overnight. So the goal when you clean a hacked WordPress site isn’t a clean scan. It’s proving there’s no way back in.

How do you clean a hacked WordPress site, step by step?

Work in this order; each step removes a way back in. Commands are WP-CLI, run over SSH from the site root.

1. Back up the infected state first. Don’t delete anything yet. Copy the files and the database, infected as they are, to somewhere off the server. It’s your forensic evidence, and WordPress.org’s hacked-site FAQ recommends this snapshot before cleaning.
2. Take the site offline. Use a static maintenance page from your host that keeps your phone number visible, or wp maintenance-mode activate as a quick stopgap. Visitors shouldn’t be served malware while you work.
3. Reset every password and the salts. WordPress admins, the database user (then update wp-config.php), SFTP, SSH and the hosting panel. Then replace the eight keys and salts in wp-config.php with a fresh set from the WordPress.org secret-key API, or run wp config shuffle-salts. That logs out everyone, including the attacker.
4. Replace core with a fresh copy. Delete wp-admin and wp-includes, run wp core download --skip-content --force --version=X.Y.Z with your current version, then wp core verify-checksums. Treat every “File should not exist” warning as a finding. If the site shows a blank page afterwards, my white screen of death guide covers the usual causes.
5. Verify the plugins. Run wp plugin verify-checksums --all. It checks against WordPress.org’s checksums, so reinstall premium plugins and your theme from the vendor, and open every file in wp-content/mu-plugins by hand.
6. Hunt PHP in uploads. find wp-content/uploads -name "*.php" should return nothing on most sites. Checksum tools never look in that folder.
7. Check users, options and cron. wp user list --role=administrator for admins you didn’t create, wp option get siteurl and wp option get home for redirects, wp cron event list for hooks you don’t recognize, and a search of wp_options for base64 and <script.
8. Scan, then change the passwords again. Run an application scanner such as Wordfence or Sucuri plus a remote scanner, then rotate credentials once more now that the site is clean, as WordPress.org advises.
9. Ask Google for a review. If Search Console shows a security issue, request a review in the Security Issues report. Google says a review can take from a few days to a few weeks.

On 14 October 2026 I tested step 4 with WP-CLI 2.12.0 on a fresh WordPress 7.1.3 download. After I appended a line to wp-includes/functions.php and planted two extra PHP files, wp core verify-checksums flagged all three. wp core download --skip-content --force then restored functions.php but left both planted files on disk, and the next verify still printed “Success” under the two warnings. A PHP file I dropped in wp-content/uploads was never reported at all. That’s why steps 4 and 6 exist as separate checks.

Check	What it caught	What it missed
wp core verify-checksums	The edited wp-includes/functions.php, plus both planted files as “File should not exist”	The PHP file in wp-content/uploads; it also printed “Success” under the two warnings once core files matched
wp core download --skip-content --force	Restored the original functions.php	Left both planted files on disk, one in wp-includes and one in the site root
find wp-content/uploads -name "*.php"	The PHP file planted in uploads	Nothing outside uploads; it does not check core files

Where does WordPress malware actually hide?

Malware sits everywhere the scanner isn’t looking. Signature scanners catch known payloads; the persistent stuff lives in the gaps between them. In client cleanups, the same four hiding places come up again and again.

• Fake plugin folders with plausible names (wp-cache-tools, seo-optimizer-pro) holding a single loader file, and must-use plugins. In a case published in September 2026, Wordfence described malware installed in wp-content/mu-plugins that hid itself from the admin, re-created itself and added rogue administrators (Wordfence, 2026).
• The database: base64 payloads in wp_options, injected scripts inside post content.
• Cron jobs: WordPress scheduled events (list them with wp cron event list) and server crontabs re-downloading the payload nightly, the classic reinfection engine.
• Legitimate files: one appended line in wp-config.php, .htaccess, or the theme’s functions.php.

A fast first pass: grep the codebase for the usual obfuscation tells, base64_decode, eval(, gzinflate, str_rot13, then list every PHP file changed in the last 30 days with find . -name "*.php" -mtime -30. That list often surfaces something the scanner rated as clean. Attackers can fake timestamps, though, so treat it as a lead, not proof.

How do you find the entry point of a hacked WordPress site?

Cross-reference file modification times with your access logs, and the door usually reveals itself. The odds favor a plugin: in 2025, 91% of the 11,334 new WordPress vulnerabilities disclosed were in plugins, against 9% in themes and just 6 in core (Patchstack, State of WordPress Security in 2026). Patchstack also found that 46% of those vulnerabilities had no fix from the developer by the time they were made public, and that the median time to mass exploitation for heavily exploited ones was 5 hours.

Outdated software is the other half of the story: in 2023, Sucuri found that 39.1% of the CMS installs it cleaned were out of date at the point of infection (Sucuri, 2023 Hacked Website Report). In client work, the entry point is usually one of four things: an abandoned plugin with a public CVE, a nulled theme, credentials reused from a breached service, or hosting stuck on an old PHP version. Skip this step and you’ve done a cosmetic cleanup, not a recovery.

How do you stop a hacked WordPress site from getting reinfected?

Rebuild from known-clean sources, then close the door for good. Never trust existing files after an infection, even the ones that look untouched. This is also where you win Google back. Once the site is clean, the prevention side is a different list, and I keep it in how to secure a WordPress site before it gets hacked.

• Reinstall themes and plugins from official sources or the vendor; don’t patch the infected copies.
• Request a review in Google Search Console once the whole site is clean. Google removes the “This site may be hacked” label only after it confirms the fix, and a review can take from a few days to a few weeks (Google Search Console Help).
• Harden what let them in: a WAF, 2FA on every admin, define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php so the dashboard can’t edit PHP, file-integrity monitoring, staged updates, and off-site backups you’ve actually test-restored.

One more reason to harden aggressively: plugin vulnerabilities accounted for 96% of all WordPress vulnerabilities disclosed in 2024 (Wordfence, 2024 Annual WordPress Security Report). If a plugin got you hacked once, an unmaintained plugin will do it again.

When should you hire someone to fix a hacked WordPress site?

Call in help the moment the infection has returned even once, or if the site takes payments or handles client or patient data. Repeat infections mean a live backdoor you haven’t found, and each recurrence can bring Google’s hacked-site warning back. My malware removal service starts at $450 fixed with same-day triage, and it includes the post-mortem that explains exactly how it happened, so it doesn’t happen twice. If you’d rather never get to this point, ongoing WordPress maintenance is the cheaper insurance; I break down typical prices in what WordPress maintenance costs. Whoever you hire, ask for live sites they have cleaned or built; mine are in my case studies.

Frequently asked questions

How long does it take to clean a hacked WordPress site?

A contained infection can often be cleaned the same day, and my own service quotes same day to 72 hours. Deeper compromises with several backdoors take longer because each one has to be traced. If Google flagged the site, add its review time on top: Google says a security review can take from a few days to a few weeks.

Will a hacked WordPress site hurt my Google rankings?

It can. Google shows “This site may be hacked” in results when it believes pages were changed or spam pages were added, and it tells searchers not to visit until the message disappears. The label stays until you fix the site and request a review in Search Console’s Security Issues report, which can take a few days to a few weeks.

Why does my WordPress site keep getting hacked?

Usually because the cleanup missed a backdoor or never closed the entry point. Sucuri found a backdoor on 49.21% of compromised sites in 2023, and Patchstack found that 46% of 2025’s WordPress vulnerabilities had no fix by public disclosure. Replace core, verify plugins, check for rogue admins and cron jobs, then update or remove the plugin that let them in.

Can I remove WordPress malware with a security plugin?

Partly. Security plugins catch known signatures, but they can miss custom backdoors, database injections, and cron-based reinfection. With 91% of 2025’s new WordPress vulnerabilities living in plugins (Patchstack), a scanner alone rarely identifies the actual entry point. Use it as a first pass alongside checksum checks and a manual look at uploads, users and scheduled events, not as the whole job.

How do I know a hacked WordPress site is clean?

When you’ve found and closed the entry point, not just when the scan turns green. Confirm that wp core verify-checksums passes with no extra-file warnings, that there are no unknown admin users, no PHP files in uploads, no unfamiliar scheduled events, and clean access logs. If the infection comes back, a backdoor was missed; that recurrence is the real test.

How much does professional malware removal cost?

It varies with how deep the infection goes, but many cleanups are sold at a fixed price, so you aren’t watching a meter during a stressful job. My own malware removal starts at $450 fixed with same-day triage and 30 days of support. For context on what WordPress work costs generally, see my breakdown of 2026 developer rates.

Sources

• Sucuri, 2023 Hacked Website & Malware Threat Report, retrieved 2026-10-14.
• Patchstack, State of WordPress Security in 2026, retrieved 2026-10-14.
• Wordfence, Quarterly WordPress Threat Intelligence Report, Q2 2026, retrieved 2026-10-14.
• Wordfence, 2024 Annual WordPress Security Report, retrieved 2026-10-14.
• Wordfence, Inside a Malicious, Stealthy WordPress Must Use Plugin, retrieved 2026-10-14.
• WordPress.org, FAQ My site was hacked, retrieved 2026-10-14.
• WordPress.org, Hardening WordPress, Advanced Administration Handbook, retrieved 2026-10-14.
• WordPress.org, WP-CLI command reference: wp core download, wp core verify-checksums, wp plugin verify-checksums, wp config shuffle-salts, wp user list, wp cron event list, wp maintenance-mode activate, retrieved 2026-10-14.
• Google, Security issues report, Search Console Help, retrieved 2026-10-14.
• Google, “This site may be hacked” message, Google Search Help, retrieved 2026-10-14.
• Google Search Central, Malware and unwanted software, retrieved 2026-10-14.