Why WordPress malware keeps coming back after cleanup

A “no threats found” scan does not prove that a site is clean. When redirects, warnings, or suspicious files return after an earlier cleanup, the visible infection may have been removed while the entry point or persistence mechanism remained.

You cleaned the site. Perhaps you handled it yourself, used a security plugin, or paid for a one-time removal. For a while it looked fixed. Then the redirect returned, the warning reappeared, or the same files were flagged again.

In many cases, the cleanup removed what was visible without closing the original entry point or finding every place the infection was hiding. Until that changes, another scan-and-delete pass only resets the timer.

A cleanup and a fix are not the same thing

Many quick cleanups stop as soon as the visible symptoms disappear. The redirect stops, the browser warning clears, or the scanner reports no known threats. That proves the symptom changed, not that the cause was removed.

Reinfection can happen within hours when the mechanism that created the malware—or the mechanism planted to survive detection—was never addressed. The files changed. The reason they changed did not.

Where malware can hide after a normal cleanup

Backdoors disguised as ordinary files

Attackers rarely leave a file named hack.php. Malicious code may be renamed to resemble a core file, cache file, plugin asset, or maintenance script and placed where a quick manual review is unlikely to inspect it closely. Signature-based scanning can miss code it has never seen before.

Malicious code inside must-use plugins

WordPress loads files from mu-plugins automatically. They do not appear in the normal Plugins screen and do not need to be activated. That makes the directory useful for legitimate site functionality—and attractive for persistent malicious code.

Scheduled tasks that restore deleted files

WP-Cron or a real server-level cron job can recreate removed files on a schedule. The suspicious file is deleted, the task runs a few minutes later, and the infection appears to have survived. What survived was the process restoring it.

Injected content stored in the database

Scripts and spam links can live in post content, widget settings, theme options, user metadata, or the wp_options table. A cleanup focused only on files can leave database injections untouched.

Credentials that were never rotated

If access came through a stolen WordPress password, hosting login, SFTP credential, API key, or compromised administrator device, deleting malware does not close the account the attacker can still use.

Another compromised site in the hosting account

On shared hosting, one WordPress installation can be reinfected from another neglected or compromised site in the same account. Cleaning only the visible site does not help if the account-level entry point remains elsewhere.

The original vulnerability is still open

An outdated plugin, abandoned theme, weak login, exposed key, or unpatched vulnerability can remain available after the infected files are removed. If nobody identified and closed the likely entry path, the same weakness can be exploited again.

Why a scanner can say “clean” and still be wrong

Many WordPress security tools rely on signatures, checksums, integrity checks, reputation data, and automated rules. These are useful for detecting common infections quickly, but they are not equivalent to a manual reinfection investigation.

Custom or lightly obfuscated code may not match a known signature. Database-only injections may not be covered fully. Files outside the WordPress installation, server-level cron jobs, rogue hosting users, and exposed credentials can sit beyond the scanner’s view.

A clean result means the tool did not detect a problem using the checks it performed. It does not explain why the website was compromised or prove that no persistence mechanism remains.

How to verify that a cleanup held

If a site has already been reinfected once, the next cleanup should include more than repeating the first scan:

• Compare WordPress core files against an official copy of the same version.
• Review every user account and role, including renamed or duplicated administrators.
• Check both WP-Cron and real server-level scheduled tasks.
• Inspect mu-plugins, drop-ins, configuration files, and unexpected PHP in upload or cache directories.
• Review the database for injected scripts, spam content, unfamiliar options, and rogue users.
• Rotate WordPress, hosting, SFTP, SSH, database, API, and related credentials where applicable.
• Replace the WordPress secret keys in wp-config.php.
• Review available access logs, error logs, scheduled tasks, and unexpected file changes after cleanup.

This takes more work than a scan-and-delete pass. It is also the difference between removing an infection and investigating why it kept returning.

When reinfection does not look like malware

Not every unresolved compromise announces itself with spam pages or visible redirects. A recurring critical error, 500 response, or broken checkout may be caused by malicious files returning, a rogue administrator changing the system, or an unresolved scheduled task.

If a website keeps failing after a cleanup, it may be worth treating the pattern as a possible unresolved backdoor rather than assuming every failure is unrelated. The WordPress compromise checklist covers the warning signs to review when the cause is still uncertain.

When to stop repeating the same cleanup

A second or third infection is a reasonable point to change approach. That is especially true when the site runs WooCommerce or another business-critical function, server-level access is required, several WordPress installations share the account, or scanners report a clean site while the symptoms continue.

At that stage, the priority is not finding the same visible malware again. It is understanding how it survived the first cleanup.

Frequently asked questions