WordPress Malware Reinfection After Cleanup: What Was Missed
WordPress malware reinfection usually means the first cleanup removed the visible symptom but missed a backdoor, vulnerable plugin, rogue user, scheduled task, infected database row, exposed credential, or stale cache layer.
Use this when redirects, spam pages, unknown admins, malicious scripts, or suspicious PHP files return days after a WordPress cleanup.
Quick answer
WordPress Malware Reinfection After Cleanup should be handled with a narrow evidence-first workflow: rebuild timeline, find persistence, close entry point, then verify the result before making broader changes.
What to check first
- Compare the new infection timestamp to plugin updates, logins, and file changes.
- Search uploads, mu-plugins, cache folders, and wp_options for persistence.
- Review administrators, application passwords, FTP, SFTP, hosting, and database users.
- Patch or remove the vulnerable plugin or theme that reopened the door.
- Rotate credentials and salts after files and database rows are clean.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|---|---|
| Rebuild timeline | Compare the new infection timestamp to plugin updates, logins, and file changes. | The same indicator does not return after cache purge and one full crawl window. |
| Find persistence | Search uploads, mu-plugins, cache folders, and wp_options for persistence. | No unknown admin, application password, or hosting user remains. |
| Close entry point | Review administrators, application passwords, FTP, SFTP, hosting, and database users. | Vulnerable plugins and abandoned themes are removed or patched. |
| Rotate access | Patch or remove the vulnerable plugin or theme that reopened the door. | Monitoring is active for changed files, users, and redirects. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
find wp-content -type f -mtime -7 -name '*.php' -print
find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' \) -print
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list
wp option list --search='script' --format=table
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Rebuild timeline
- Find persistence
- Close entry point
- Rotate access
- Monitor recurrence
Production verification checklist
- The same indicator does not return after cache purge and one full crawl window.
- No unknown admin, application password, or hosting user remains.
- Vulnerable plugins and abandoned themes are removed or patched.
- Monitoring is active for changed files, users, and redirects.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix recurring WordPress malware.