How to Remove Malware from a Hacked WordPress Site

First, confirm it's actually malware

Before you start tearing files apart, make sure you're dealing with a real infection and not a false alarm. The genuine signs are specific:

• A Security Issues report in Google Search Console — the clearest, least ambiguous signal. It exists specifically for this: Google's own documentation describes it as "indications that your site was hacked, or behavior on your site that could potentially harm a visitor," covering malware, phishing, and hacked-with-spam.
• A browser warning — "Deceptive site ahead" or a red Safe Browsing interstitial when visiting your own site.
• Behavior you didn't create — unexpected redirects to another domain, spam content appearing in posts or pages, new admin accounts, or a host support email saying your site is sending outbound spam or resource abuse.

If none of these are present and you're just reacting to a vague "your site might be at risk" email from an unrelated third party, slow down — that pattern itself is a common phishing tactic aimed at panicked site owners.

Before you touch anything: preserve, then isolate

Two things first, in this order:

1. Back up the site exactly as it is right now — infection included. This sounds counterintuitive, but a backup of the compromised state is what lets you (or a host, or a forensic tool) go back and identify exactly what happened if cleanup goes wrong or you need to prove what was fixed later.
2. Put the site in maintenance mode if you can without deleting anything — this stops the infection from actively harming visitors while you work, without destroying evidence the way a panicked file-by-file deletion spree would.

Finding where the infection actually lives

Malware doesn't announce itself with a label. Work outward from the most reliable checks to the broadest:

1. Verify WordPress core against official checksums. If you have shell access:

wp core verify-checksums

This flags any core file that doesn't match the official release — see our core-file-tampering guide for what to do with a specific mismatch. One important limit: this only covers wp-admin, wp-includes, and root-level files. It says nothing about wp-content — your themes, plugins, and uploads — which is exactly where most real infections actually sit.

2. List files modified recently. A fresh infection usually touches files more recently than your last legitimate update or edit:

find wp-content -type f -mtime -7 -printf '%T@ %p\n' | sort -rn

This lists everything under wp-content modified in the last 7 days, newest first (adjust the -7 to match roughly when you think the problem started). A theme or plugin file with a modification date you can't account for is worth opening and reading.

3. Check the database, not just the filesystem. Malware that injects spam links or redirects often lives in wp_options (a tampered siteurl/home value, or a fake widget/template entry) or directly inside post/page content in wp_posts. The active_plugins option is also a known target — some infections re-add themselves to this list after you delete the plugin file, which is one reason a cleanup can seem to "not stick."

Where malware most commonly hides

• Theme files, especially functions.php. It runs on every page load and is rarely read end-to-end by a human, which makes it a favorite injection point.
• Near the top or bottom of wp-config.php. This file loads before almost anything else, so a single injected line here runs on every single request.
• The uploads folder. wp-content/uploads is writable and meant to hold media, not executable code — a .php file sitting there, or a file disguised with a double extension, is a strong red flag.
• Plugin files that were never part of the plugin. Compare a suspect plugin's files against a freshly downloaded copy from wordpress.org if you're unsure something belongs.

Why "just restore from backup" isn't automatically safe

Restoring a backup feels like the fast fix, and sometimes it is — but only if you know the backup itself predates the infection. If you're not sure exactly when the compromise started, restoring a recent backup can simply restore the malware right along with everything else, especially for the kind of persistence mechanisms (a rogue cron job, a modified core file) that can sit quietly for weeks before doing anything visible. If you do restore from backup, still run through the checks above afterward rather than assuming a restore equals clean.

Actually removing it

Sucuri's own cleanup guide — built from years of doing this professionally — recommends a specific order that holds up well: identify the type of hack first, then work from the most trustworthy fix outward.

1. Replace WordPress core entirely. Rather than trying to patch individual flagged files, download a fresh copy of your exact version and overwrite wp-admin, wp-includes, and the root-level files completely. It's faster and more certain than surgical edits.
2. Go through themes and plugins by hand. If core is clean (or freshly replaced) and the site is still compromised, this is where it's hiding. Deactivate and remove anything you don't recognize or don't actively use — an unused, outdated plugin is a common entry point even when it isn't itself the payload.
3. Clean the database entries you found earlier. Remove injected content from posts/pages, correct any tampered wp_options values, and check active_plugins against what should actually be active.
4. Remove any admin account you don't recognize. Don't just downgrade it — delete it, after confirming it isn't someone on your own team.

Skipping any one of these and calling it done is exactly how a "cleaned" site gets reinfected within days — usually because the actual entry point, not just its visible symptom, was left in place.

Close the door you didn't know was open

A clean scan today doesn't mean much if the mechanism that let the attacker in — or the one they used to keep coming back — is still there. Two of the most common persistence mechanisms are worth checking specifically once the obvious mess is cleaned up: a rogue scheduled task re-creating the infection on its own schedule, and a quietly modified core file serving as a backdoor. Both are exactly the kind of thing that makes cleanup "not stick" if they're missed.

Change every credential — not just the WordPress password

Once you've confirmed a genuine compromise, assume every credential the site touches may be exposed, not just the WordPress admin login:

• WordPress admin passwords, for every account
• Hosting control panel login
• FTP/SFTP credentials
• Database password
• Any API keys stored in the site (payment gateways, email services, the AI provider key if you're using SecurynAI's AI explanations)

Do this after cleanup, not before — changing credentials on a still-infected site just means the attacker's foothold gets to watch you set new ones.

What your host's own scanner might not catch

Many hosts run their own baseline malware scanning, and it's genuinely useful — but it isn't a substitute for the steps above. Host-level scanners are typically tuned for known, widely-seen malware signatures across many customers at once; a targeted or newly-modified piece of injected code, or a single tampered database row, can fall outside what a broad, automated pass is built to catch. Treat a clean host scan as one data point, not proof the site is clear, especially if you already have a concrete signal (a Search Console flag, a browser warning, an unexplained redirect) telling you otherwise.

Getting the warning removed from Google

Google doesn't clear a Security Issues warning automatically, even once your site is genuinely clean — per Google's own documentation, you have to request it. In Search Console, open the Security Issues report and select Request a review, describing what you found and how you fixed it. Processing time depends on the issue type: malware reviews typically take a few days, phishing about a day, and hacked-with-spam can take up to several weeks. Requesting review before the problem is actually fixed just resets that clock, so confirm cleanup is complete first.