A WordPress website gets infected. Someone runs a malware scanner, deletes several suspicious PHP files, and the website starts working again.
Everything looks normal.
Then, a few hours or days later, the same malicious files reappear.
This is one of the most frustrating problems in WordPress incident response. The malware was removed, but the infection wasn't actually resolved.
The underlying issue is usually that the attacker still has a way into the website or hosting environment.
Let's examine why this happens and how developers can investigate it properly.
Malware Removal and Incident Recovery Are Different
A malware scanner can identify suspicious files, but it may not reveal how the attacker entered the system.
Consider a WordPress website compromised through a vulnerable plugin.
An attacker might use that vulnerability to upload a PHP backdoor. The website owner later removes the backdoor but doesn't update the vulnerable plugin.
The attacker can potentially exploit the same vulnerability again.
Alternatively, the attacker may have created a second backdoor, added an unauthorized administrator, or established a scheduled task that restores malicious files.
A successful cleanup therefore requires identifying both the visible malware and the mechanism that allowed the compromise.
1. Check for Hidden PHP Backdoors
Attackers sometimes disguise malicious code as legitimate WordPress components.
Suspicious files may appear in upload directories, inactive themes, plugin folders, or unexpected subdirectories.
One useful first step is looking for recently modified PHP files.
On a Linux server, an administrator can use:
find /var/www/html -type f -name "*.php" -mtime -7 -print
This lists PHP files modified within the past seven days.
It does not prove that those files are malicious. Legitimate updates and development activity may also modify PHP files.
The results should be compared against known deployment activity and trusted WordPress package files.
Avoid deleting files solely because they appear in this list.
2. Review WordPress Core File Integrity
WordPress provides tools for verifying whether installed core files match official release checksums.
If WP-CLI is available, run:
wp core verify-checksums
This can help identify modified or unexpected core files.
However, checksum verification has limitations.
A successful result doesn't establish that plugins, themes, the database, or other server files are clean.
For supported plugins, checksum verification can provide additional information:
wp plugin verify-checksums --all
Some commercial or custom plugins may not have WordPress.org checksums available.
Unexpected results require investigation rather than immediate deletion.
3. Audit Administrator Accounts
Attackers sometimes create unauthorized WordPress administrator accounts.
A compromised administrator account may allow malicious plugins or scripts to be installed again.
WP-CLI provides a way to review users:
wp user list --role=administrator
Compare the output with the people who should legitimately have administrative access.
Investigate unfamiliar accounts, unexpected privilege changes, and suspicious recent activity.
Potentially compromised credentials should be rotated, and multifactor authentication should be enabled where available.
Don't forget hosting accounts, SFTP credentials, database credentials, and associated email accounts.
4. Investigate Scheduled Tasks
Recurring malware sometimes involves persistence mechanisms that execute code after a cleanup.
WordPress includes WP-Cron, while hosting environments may also support system cron jobs.
Review scheduled tasks for unexpected behavior.
With WP-CLI:
wp cron event list
Look for unfamiliar hooks, unusual schedules, and jobs associated with plugins that are no longer installed.
A scheduled task isn't malicious simply because its name is unfamiliar. Its purpose and implementation should be verified before removal.
System-level scheduled tasks should also be inspected where administrators have appropriate access.
5. Inspect the Database
Not every WordPress infection is stored as a standalone PHP file.
Attackers may inject malicious JavaScript, spam links, altered configuration values, or unauthorized content into the database.
Common places worth investigating include posts, options, and application-specific metadata.
A database review should be conducted carefully.
WordPress and its plugins store structured and serialized information. Removing unfamiliar records without understanding them can break website functionality.
Preserve a backup and document changes before modifying production data.
6. Check Other Websites on Shared Hosting
This step is frequently overlooked.
A hosting account may contain multiple WordPress installations.
If those websites share filesystem permissions or the same system user, a compromise affecting one installation may create risks for others.
Cleaning only the most visibly infected website may leave another compromised installation untouched.
Administrators should review all applications and directories accessible through the affected hosting account.
Where supported, isolating websites under separate system users can reduce the impact of a future compromise.
7. Never Trust a Backup Without Verification
Restoring a clean backup can be an effective recovery method.
However, a backup created after the original compromise may contain the same malware.
Before restoration, evaluate when the infection likely began and inspect the backup where practical.
After restoring, patch the original weakness and rotate compromised credentials.
Otherwise, the same infection may return.
A Practical WordPress Malware Recovery Workflow
A structured investigation generally follows this sequence:
- Preserve logs and capture a protected backup of the affected environment.
- Contain unauthorized access where practical.
- Identify suspicious files, accounts, database changes, and scheduled tasks.
- Determine the likely entry point.
- Remove malicious components or rebuild from trusted sources.
- Patch vulnerable software and rotate affected credentials.
- Verify normal website functionality.
- Monitor the environment for signs of recurring compromise.
At Xequent, we approach WordPress malware removal as both a cleanup and a root-cause investigation.
The goal is to address the security weakness behind an infection rather than repeatedly deleting its symptoms.
Final Thoughts
Recurring WordPress malware usually requires more investigation than a single scan.
A compromised plugin, hidden backdoor, stolen credential, or infected backup may allow an attacker to regain access after the visible malware disappears.
Developers should approach recovery as an incident-response process that includes evidence preservation, technical investigation, vulnerability remediation, and verification.
Removing malicious code is one step. Preventing the same compromise from returning is the real objective.
About the author: Rana Shahwaiz Aslam is a Certified Ethical Hacker (CEH) and founder of Xequent, a website security company specializing in WordPress security and Cloudflare protection.
Top comments (0)