Why a cleaned site gets reinfected

The short answer

A site that gets reinfected was not fully cleaned. The visible malware was removed but the way in was left open: an unpatched plugin, a password nobody changed, a hidden backdoor file, or a scheduled job that downloads the malware again.

Treat the second infection as unfinished business from the first. Change every password, revoke every token, patch or delete every outdated plugin, and have support look specifically for backdoors and scheduled tasks, not just the symptoms.

What it means

Most cleanups focus on what the owner can see: the redirect, the spam pages, the defaced homepage. Removing those stops the symptoms but does nothing about the cause. Attackers expect to be cleaned up, so the first thing most malware does after landing is plant a backdoor: a tiny file, often disguised with an innocent name or hidden inside an image folder, that lets the attacker run commands on your site without logging in.

Some malware also installs a scheduled task, either inside WordPress (WP-Cron, the built in scheduler that runs when pages are visited) or on the server, that quietly re-downloads the payload every day. Clean the files and they are back by morning.

The other common pattern is that the attacker still has a valid key. If the password, the application passwords, the SFTP login or the database password were not changed, they can simply log in again. The same is true if the WordPress salts, the secret values in wp-config.php that sign login cookies, were left alone, because old session cookies keep working.

Common causes

• The original hole was never closed. The vulnerable plugin or theme is still installed at the same version, or was updated but the attacker had already added an administrator account.
• A backdoor file was missed. Common hiding places are wp-content/uploads, wp-content/mu-plugins, a plugin folder with a plausible name, and files added inside wp-includes.
• Credentials were not rotated. WordPress passwords, application passwords, SFTP, the database password and the salts all need changing. Missing one is enough.
• Another site on the same account is still infected and reinfects its neighbours through shared file access.
• The cleanup restored an infected backup. If the backup was taken after the break-in, the malware came back with it.
• Your own computer is infected and leaking the new passwords as fast as you set them.

How to fix it

1. Write down the timing. If the malware returns at the same time each day, suspect a scheduled task. If it returns straight after you log in from one computer, suspect that computer. (Host independent.)
2. Find and remove the backdoor. In File Manager, sort wp-content by modified date and inspect recent files. Remove any .php file in wp-content/uploads. Open wp-content/mu-plugins and delete anything you did not put there. Compare the folder list in wp-content/plugins against Plugins > Installed Plugins; a folder with no matching plugin is suspicious. Dashboard > Updates > Re-install Now replaces anything hidden in core.
3. Check scheduled tasks. Install the WP Crontrol plugin and open Tools > Cron Events; delete any event you cannot attribute to a plugin you use. In the management console (Plesk with WP Toolkit), open Scheduled Tasks for the subscription and remove unknown entries.
4. Rotate everything. Passwords for every WordPress user with elevated rights (Users > All Users), every Application Password (Users > Profile), the SFTP and SSH users in the console, the database password (change it in the console and in wp-config.php), and the salts block in wp-config.php.
5. Patch or remove the entry point. Under Plugins > Installed Plugins, check each plugin’s last updated date on its listing page. Delete anything abandoned or unused. Replace pirated software with licensed copies.
6. Clean every site in the account, not just the one showing symptoms. If you host several sites, ask support to separate them so one cannot write to another’s files.
7. Scan your own devices with up to date antivirus, and remove saved passwords from old FTP programs.
8. If you restore a backup, choose one from before the first symptom, then immediately update and change passwords before the site is reachable again, or the same hole will be used again.
9. Harden for the future. Turn on two-factor authentication for every administrator, block xmlrpc.php if nothing uses it, and keep the number of administrators as small as possible.

On WP Alpha

Every WP Alpha site is scanned daily by Imunify and cleanup is included on every plan, so a reinfection is something to report to support straight away rather than fight alone. Tell them the site was cleaned before and when; that changes where they look first.

Backups run every two hours and are kept for 30 days, which gives a wide choice of restore points from before the original break-in, and any restore is queued from the management console (Plesk with WP Toolkit). WordPress, plugin and theme updates are tested on a staging copy with before and after screenshots and an error log check before they go live, so the most common entry route (an outdated plugin) is closed without you having to choose between security and a site that might break. A business grade web application firewall with brute force protection sits in front of every site.