You delete the infected file.
A few minutes later, it is back.
You clean the website again. The same suspicious PHP file appears. Maybe a new administrator account is created. Maybe a strange script shows up inside wp-content, or a malicious redirect starts working again.
If this sounds familiar, you are probably not dealing with a single infected file.
Something else is putting it back.
This is one of the most frustrating WordPress security problems because deleting the visible malware does not necessarily remove the mechanism that created it.
That mechanism is often called persistence.
In this guide, we will look at why WordPress malware can return after cleanup, where the reinfection mechanism can hide, what you can check manually, and how a security scanner such as Nexura Security can help you investigate the problem.
Why Does WordPress Malware Keep Coming Back?
A common mistake during malware cleanup is focusing only on the file that was discovered.
For example, suppose you find:
/wp-content/uploads/cache.php
You delete it.
But what if another compromised PHP file contains code that executes something similar to:
file_put_contents(...);
and recreates cache.php?
The deleted file was only the symptom.
The actual problem was the code that recreated it.
This is why repeatedly deleting suspicious files can turn into an endless cycle.
A better question is:
What is creating this file again?
Once you identify the writer or persistence mechanism, you can remove the underlying cause instead of repeatedly cleaning the same symptoms.
Common Reasons WordPress Malware Returns
There are several places worth investigating when malicious files repeatedly reappear.
- Malicious PHP File Writers
One of the first things to investigate is code capable of creating or modifying files.
Common PHP functions include:
file_put_contents()
fwrite()
fopen()
touch()
copy()
rename()
These functions are not malicious by themselves.
WordPress plugins and themes legitimately use filesystem operations.
The problem is when unexpected code uses them to create PHP files containing malicious payloads.
For example, a compromised script could write another PHP file into a writable directory.
Removing the generated file does nothing if the original writer remains.
What to investigate
Look for:
unexpected PHP files
recently modified PHP files
PHP inside upload directories
suspicious encoded strings
unfamiliar functions
files with unusual modification times
PHP files that do not belong in their directory
Do not automatically delete every file that looks unusual.
First determine what created it and whether the file is actually part of WordPress, a plugin, a theme, or your hosting environment.
- WP-Cron Can Be Used for Persistence
WordPress has a scheduled task system called WP-Cron.
Plugins use it for completely legitimate tasks such as:
scheduled publishing
database maintenance
cache cleanup
email processing
updates
But if an attacker manages to create a malicious scheduled event, it can potentially execute unwanted code again later.
That can make a cleanup problem appear mysterious.
You delete the malware.
Later, a scheduled task runs.
The malware comes back.
What should you check?
Look for cron events that:
you do not recognize
belong to an uninstalled plugin
call unexpected PHP functions
reference suspicious files
execute unusually often
appeared around the time the compromise started
The important thing is not simply finding an unknown cron event.
You need to understand what the event executes and where that code comes from.
- Must-Use Plugins Can Be Easy to Miss
WordPress has a special plugin directory:
wp-content/mu-plugins/
These are called must-use plugins.
They are loaded automatically and do not behave exactly like normal plugins in the WordPress Plugins screen.
That makes the directory important during a security investigation.
A malicious file placed there can survive normal plugin cleanup and may continue executing even when the administrator believes all plugins have been checked.
Look for:
wp-content/mu-plugins/
Then inspect unfamiliar files carefully.
Again, unfamiliar does not automatically mean malicious.
Some hosting companies and legitimate systems install must-use plugins.
The goal is to establish whether the file is expected and what it actually does.
- Drop-ins and Other Special WordPress Files
WordPress also supports special files known as drop-ins.
Examples include files associated with:
advanced-cache.php
object-cache.php
db.php
depending on the site's configuration and installed software.
Caching, database, and hosting systems may legitimately use these files.
However, because they are loaded differently from ordinary plugins, they deserve attention during an investigation.
If suspicious code exists in a drop-in, deleting a normal plugin may not solve the problem.
- .user.ini and auto_prepend_file
Another area that can be overlooked is PHP configuration.
A compromised site may contain configuration that causes another PHP file to be loaded automatically.
One example is:
auto_prepend_file=/path/to/file.php
The exact behavior depends on the PHP and hosting configuration, but the important security concept is simple:
A malicious file does not always need to be directly included by WordPress code.
Server or PHP configuration can cause additional code to execute.
During an investigation, check for unexpected:
.user.ini
php.ini
and relevant server configuration.
If you find auto_prepend_file, determine exactly what file it references and why.
- Server Cron Can Recreate Malware
WordPress is not the only scheduler on a server.
Depending on the hosting environment, attackers may also abuse operating-system-level scheduled tasks.
For example:
crontab
could execute a script periodically.
This is particularly important on VPS, dedicated servers, and environments where users have shell access.
If the same malware appears at predictable intervals, timing can provide a useful clue.
For example:
The suspicious file appears every 15 minutes.
That does not prove a cron job is responsible, but it gives you something specific to investigate.
- Compromised Administrator Accounts
Sometimes the malware is not automatically recreating itself at all.
An attacker may still have access to the website.
If a compromised administrator account remains active, malicious files can simply be uploaded again.
Check:
WordPress administrator accounts
unknown users
recently created users
suspicious login activity
hosting control-panel accounts
FTP/SFTP credentials
SSH keys
API credentials
Changing the WordPress administrator password alone may not be enough if another credential is compromised.
A complete incident response should consider all possible access paths.
- A Vulnerable Plugin or Theme May Be the Entry Point
Persistence and initial compromise are two different questions.
You might successfully remove the persistence mechanism but leave the original vulnerability untouched.
Then the attacker can simply compromise the website again.
Common entry points include:
outdated plugins
vulnerable themes
abandoned extensions
compromised credentials
insecure file permissions
vulnerable custom code
outdated WordPress or server software
This creates another frustrating cycle:
clean → compromise → reinfect → clean → compromise
Therefore, malware removal should be followed by vulnerability investigation.
How to Investigate a Reappearing File
Suppose you have this file:
/wp-content/uploads/2026/09/cache.php
and it keeps coming back.
Instead of deleting it repeatedly, work backwards.
Step 1 — Record the filename
Write down:
cache.php
Also record:
full path
file size
modification time
permissions
owner
suspicious functions
Step 2 — Inspect the contents
Look for things such as:
eval()
base64_decode()
gzinflate()
assert()
preg_replace()
file_put_contents()
These functions can have legitimate uses, so their presence alone is not proof of malware.
Look at the surrounding code and understand what it actually does.
Step 3 — Search for references
Search the WordPress installation for:
cache.php
You may discover another script referencing it.
That reference could reveal the persistence mechanism.
Step 4 — Check timestamps
Compare the modification times of:
the recreated file
suspicious PHP files
plugin changes
theme changes
cron events
login activity
Timeline analysis can be extremely useful.
Step 5 — Identify the writer
The key question is:
Which process or code is writing this file?
Once you answer that, the investigation becomes much easier.
Why Deleting Malware Is Not the Same as Cleaning a Website
Malware cleanup is often described as:
Find bad file → delete bad file → website clean.
Real incidents can be more complicated.
A compromised website may contain:
Entry point
↓
Persistent access
↓
Malicious writer
↓
Generated PHP file
↓
Redirect / spam / backdoor
If you only remove the generated PHP file, the rest of the chain may remain.
The file simply comes back.
That is why a good investigation looks for the source, not only the visible payload.
Using Nexura Security to Investigate Reinfection
Manually investigating a compromised WordPress site can take time, especially when you are dealing with many files.
This is where Nexura Security can help.
Nexura Security is designed as a WordPress security toolkit with features for malware detection, vulnerability scanning, security auditing, headers, audit logs, and other security checks.
For a reinfection investigation, the useful approach is not simply:
"Delete suspicious files."
Instead, the goal is to identify suspicious activity and understand where it originates.
Nexura Security can help surface security findings that deserve investigation, including suspicious PHP code and WordPress-level security issues.
Free Nexura Security
The free version can be useful as a starting point for WordPress security investigation.
You can use it to inspect your site's security posture and identify findings that require attention.
This is especially useful when you want visibility before making changes.
Nexura Pro
For sites dealing with recurring infections or more advanced incidents, the Pro direction focuses on deeper investigation and response capabilities.
Depending on the available Pro features, this can include more detailed findings, quarantine workflows, and additional persistence-oriented checks.
The important principle remains the same:
Detect first. Understand the source. Then remove the cause.
A Practical Reinfection Investigation Checklist
If malware keeps returning, go through this checklist.
WordPress
Update WordPress
Update plugins
Update themes
Remove unused plugins
Remove unused themes
Check administrator accounts
Review recent login activity
Files
Search for recently modified PHP files
Check wp-content/uploads
Check mu-plugins
Check drop-ins
Check unexpected PHP files
Search for references to recreated files
Scheduled Tasks
Review WP-Cron events
Check server cron where available
Look for unknown scheduled scripts
PHP Configuration
Check .user.ini
Check auto_prepend_file
Review relevant PHP configuration
Hosting
Review FTP/SFTP users
Review SSH access
Review hosting-panel users
Rotate compromised credentials
Check server logs when available
Security
Run a malware scan
Run a vulnerability scan
Review audit logs
Check security headers
Monitor the site after cleanup
What If the Malware Still Comes Back?
If you have completed the cleanup and the same file returns, do not immediately start deleting files again.
Instead, collect evidence.
Record:
File path
Creation time
Modification time
File contents
Related PHP files
Cron events
User activity
Server logs
Then compare the timeline.
For example:
10:00 — suspicious file deleted
10:05 — file appears again
10:05 — WP-Cron executes
10:05 — another PHP file modified
A pattern like this gives you a much stronger lead than repeatedly deleting the same file.
Prevention After Cleanup
Once the infection is gone, prevention matters just as much.
Keep WordPress and extensions updated.
Remove software that is no longer required.
Use strong unique passwords.
Enable two-factor authentication for administrator accounts.
Limit unnecessary access.
Use appropriate file permissions.
Monitor important file changes.
Review scheduled tasks.
Keep reliable backups.
And most importantly, investigate the original entry point.
A clean website today can become compromised again tomorrow if the vulnerability that allowed the attacker in remains open.
Final Thoughts
When WordPress malware keeps coming back, the problem is usually bigger than the file you can see.
The suspicious PHP file may only be the final result of another process.
The real source could be:
a malicious file writer
a WP-Cron event
a server cron job
an MU-plugin
a drop-in
PHP configuration
a compromised account
a vulnerable plugin
or another persistence mechanism
That is why effective cleanup starts with one question:
What keeps recreating the malware?
Find that answer, and you can move from repeatedly deleting symptoms to actually addressing the cause.
If you are investigating a WordPress site with recurring malware, Nexura Security can give you a practical starting point for scanning, vulnerability detection, auditing, and security investigation.
Scan your WordPress site with Nexura Security and investigate the source of the reinfection—not just the file that keeps coming back.
[Get Nexura Security on WordPress.org]
FAQ
Why does WordPress malware keep coming back after I delete it?
Usually because another malicious file, scheduled task, compromised account, vulnerable component, or configuration is recreating it. Deleting the visible file may remove only the symptom.
Can WP-Cron cause WordPress malware to return?
A malicious or compromised scheduled task can potentially execute unwanted code. WP-Cron should therefore be reviewed when a file repeatedly appears.
Can malware hide inside wp-content/uploads?
Yes. PHP files in an uploads directory can be suspicious, although legitimate configurations can vary. Investigate unexpected executable files rather than automatically deleting everything.
What is a WordPress MU-plugin?
A must-use plugin is automatically loaded by WordPress and is handled differently from ordinary plugins. The wp-content/mu-plugins directory should therefore be included in a thorough security investigation.
Does scanning remove all WordPress malware?
A scan can identify suspicious files and security issues, but detection is not the same as complete incident response. Recurring infections require investigating the persistence mechanism and original entry point.
How can I stop WordPress malware from returning?
Identify the mechanism recreating the malware, remove the underlying persistence, patch the original vulnerability, rotate compromised credentials, and monitor the site after cleanup.
Top comments (0)