Why does my WordPress site get reinfected after cleanup?

When a WordPress site gets reinfected after cleanup, the deleted malware did not simply grow back. A remaining mechanism allowed an attacker or hidden code to recreate it. The cause may be a backdoor, an unpatched plugin, stolen credentials, another compromised site in the same hosting account or a backup that was already infected.

A durable recovery therefore cannot end with deleting visible malware. You need to know how the attacker entered, what access they gained, what they changed and how they maintained persistence. Without those answers, a site can look clean for hours or days and then start redirecting visitors, generating spam or creating unfamiliar files again.

Common signs of reinfection

• a deleted PHP file reappears in the same location,
• new randomly named files are created,
• mobile or search-referrer redirects return,
• Search Console discovers new spam URLs,
• another administrator account appears,
• .htaccess is rewritten repeatedly,
• a scanner deletes the same payload after every scan,
• several sites in one hosting account infect each other,
• the incident returns after a cron run or suspicious request.

Timing matters. If the payload reappears immediately after a specific HTTP request, login or scheduled event, that sequence can identify the persistence mechanism.

Why malware returns

A backdoor survived

The obvious payload is often only one part of the compromise. A small loader or webshell may remain in uploads, mu-plugins, a legitimate plugin file or outside the WordPress directory. Its only purpose may be to download the full payload again when it receives a particular request.

The vulnerable component is still exposed

Deleting files does not patch the plugin endpoint that allowed the original compromise. Automated scanners can exploit the same version again within minutes.

Credentials are compromised

The attacker may have a WordPress admin password, application password, hosting-panel login, SFTP key or database credential. XML-RPC and the normal admin login can also be abused with leaked credentials. Rotating only one password may leave another path open.

Another website can write into this one

Multiple installations often run under the same system user. An abandoned WordPress site in a sibling directory can allow malware to modify the cleaned production site.

The restored backup was already compromised

A backup can predate visible symptoms while still containing a dormant backdoor. File dates alone cannot prove that a restore point is clean.

Indicators of persistence

Inspect:

wp-content/uploads/**/*.php
wp-content/mu-plugins/*.php
wp-content/cache/**/*.php
wp-config.php
.htaccess
../logs/
../tmp/

Look for:

unknown WordPress cron callbacks
system cron jobs or scheduled tasks
autoloaded malicious options
unknown admins or application passwords
remote code loaders inside plugins
direct POST requests to hidden PHP files

Attackers can preserve timestamps, hide code in the database or fetch it from a remote server. Sorting files by modification date is useful, but never sufficient.

Finding the original entry point

1. Preserve the compromised state and all available logs.
2. Build a timeline from the first symptom to reinfection.
3. Compare files from both compromised states.
4. Identify which suspicious artifact appeared first.
5. Find the HTTP requests immediately before its creation.
6. Audit admin logins, users and application passwords.
7. Inspect WordPress and system cron jobs.
8. Review every website under the same hosting account.
9. Match plugin versions against known vulnerabilities.
10. Rotate every credential that could provide write access.

WebShield's advanced logging helps connect a created malware file to the request or event that initiated it. That is more useful than repeatedly removing the final payload without understanding its origin.

A durable cleanup process

• Replace WordPress core files with an official package.
• Reinstall required plugins and themes from trusted sources.
• Remove unused components and abandoned installations.
• Search every hosted site for backdoors.
• Patch or replace the vulnerable component.
• Inspect database options, cron events and users.
• Rotate WordPress, hosting, SFTP, database and API credentials.
• Regenerate WordPress salts.
• Enable multifactor authentication.
• Purge every cache layer.
• Monitor file and HTTP activity closely after recovery.

For conditional redirects, use the investigation steps in our WordPress redirect malware guide. If scanners disagree with visible symptoms, read why Wordfence can say clean while infection remains.

Why backup restoration is not enough

Backups protect availability. They do not identify the attacker or close an entry point. If the vulnerable plugin, stolen password or compromised sibling site remains, the restored copy is exposed to the same attack.

Backups should still be frequent, stored outside the hosting account and tested through real restoration. The WordPress security FAQ covers backup limitations, while managed WordPress protection adds monitoring and expert recovery.

Building an incident timeline

Do not stop at a list of suspicious files. A timeline connects actions and helps distinguish the initial entry point from later payloads. Start with the earliest confirmed symptom and work backwards through every available log source.

09:12 suspicious POST request reaches a plugin endpoint
09:12 a PHP file appears under uploads
09:14 the new file receives a direct request
09:15 an unknown administrator is created
09:18 .htaccess is modified
10:03 the first visitor redirect is reported

This sequence is more useful than saying that five infected files were found. It suggests which request started the incident, which file acted as a backdoor and what secondary access the attacker established.

Combine web-server access logs, hosting audit logs, file metadata, database timestamps and external monitoring. Normalize time zones before correlation; otherwise, the same action may appear hours apart in different systems.

Verifying that recovery is durable

One scan cannot provide absolute certainty. Confidence comes from several independent checks:

• WordPress core checksums match,
• plugins and themes come from known clean packages,
• executable PHP is absent from inappropriate directories,
• every administrator and application password is understood,
• scheduled events have legitimate owners,
• the vulnerable entry point is patched,
• every affected credential has been rotated,
• file monitoring reports no unexplained changes,
• symptoms do not return over multiple expected attack cycles.

Observation time depends on the persistence mechanism. An hourly cron job can be tested quickly, while an occasional exploitation wave requires longer monitoring. Document what was checked, which credentials changed and which vulnerability or access route was closed.

Is it the same infection or a new compromise?

Distinguish reactivated persistence from a new attack through the same or a different weakness. Matching filenames, code patterns, external domains and HTTP routes suggest that a previous backdoor survived or the original entry point remained open.

A new compromise may show:

• a different malware family or obfuscation style,
• another vulnerable plugin endpoint,
• new source IP and user-agent patterns,
• a different objective, such as data theft instead of redirects,
• a recently disclosed vulnerability that was not available during the first incident.

Preserve samples from both incidents. Compare file hashes, full code, remote domains, requests and timelines. If every cleanup deletes files and logs immediately, this evidence is lost.

The same attacker may also switch techniques. They might first exploit an upload endpoint and later use a previously created administrator to install a plugin. Those actions look different technically but belong to one compromise chain.

What to check on multi-site hosting accounts

Inventory every domain, subdomain, staging copy and forgotten test installation. Determine which system user owns each directory and whether PHP running on one site can write into another.

Review versions, administrators, cron events and unfamiliar PHP files in every installation. One abandoned site can reinfect the entire account. For durable isolation, use separate system users or containers, independent PHP pools and file permissions limited to what each application actually requires.

Prevention

Reduce the probability of reinfection with:

• managed, timely updates,
• vulnerability monitoring,
• minimal administrator privileges,
• multifactor authentication,
• file-change and login monitoring,
• HTTP request logging,
• isolation between hosted sites,
• frequent off-site backups,
• tested recovery procedures.

When expert incident response is needed

Escalate when malware has returned once, several websites are involved, logs are incomplete, a revenue-generating site is affected or you cannot identify which access method was compromised.

This requires incident response, not another quick deletion. The SOS recovery service focuses on restoring operation while removing persistence and closing the compromise path.

Common mistakes during reinfection incidents

Repeating the same cleanup is one of the most common failures. If the first scanner found only the final payload, another run will delete the same artifact while the backdoor that creates it remains untouched.

It is also risky to focus only on recently modified files. Attackers can change old files, preserve timestamps, store code in the database or retrieve payloads from a remote server. File time is a useful signal, not a verdict.

Avoid:

• deleting logs before investigation,
• overwriting the compromised state without preserving a copy,
• rotating only the administrator password,
• ignoring other websites in the hosting account,
• reinstalling the same vulnerable plugin version,
• automatically allowing unexplained files,
• skipping post-recovery monitoring.

In an agency relationship, define ownership explicitly. Who patches plugins, controls hosting, owns administrator access and responds to monitoring alerts? When each party assumes the other is responsible, the original weakness can remain exposed.

What a recovery handover should contain

A proper incident closure should document:

• a short description of the infection,
• the confirmed or likely entry point,
• removed backdoors and unauthorized accounts,
• components that were updated or replaced,
• credentials that must be rotated,
• validation steps performed,
• remaining uncertainty,
• monitoring recommended for the following days.

This record makes a later event easier to compare. Investigators can determine whether the same attack route returned or an unrelated vulnerability caused a new compromise.

Conclusion

WordPress gets reinfected because some route back remains: a backdoor, vulnerable plugin, stolen credential, infected backup or compromised neighboring site. A durable recovery examines the whole hosting environment, correlates logs and builds an incident timeline. The goal is not only to delete malware, but to demonstrate that the attacker's route has been closed.

• WordPress
• reinfection
• backdoor
• incident response