PHP files inside wp-content/uploads deserve immediate investigation because uploads should normally contain media, not executable application code. The file may be a malicious payload, a dropper left by another compromise or, less commonly, a deliberate custom component stored in the wrong place.
Contain execution before deleting the evidence
Prevent public execution of the suspicious file or directory while preserving a copy, hash, owner and timestamps. Record requests that reached it. Deleting the file first can remove the best clue to the component or account that wrote it.
Trace how PHP reached a writable media directory
- Look for vulnerable upload handlers and recently changed plugins.
- Review file ownership and the PHP/web-server account.
- Correlate creation time with access logs and administrator activity.
- Search for references to the file from themes, plugins, cron and database options.
One PHP file often points to wider persistence
If the payload is part of a visible fake-update campaign, compare theme-level malware such as WP-VCD. If the compromise also changes core or root files, use file-integrity triage to scope the wider change set.
Recover the write path, not only the uploads folder
- Remove confirmed malicious files after evidence capture.
- Patch or replace the component that allowed the write.
- Reinstall affected application code from trusted sources.
- Rotate credentials that could upload or modify code.
- Block PHP execution in media directories where compatible with the application.
Do not chmod the whole site read-only as a permanent answer
WordPress still needs controlled writable areas. The goal is least privilege: only the expected process should write to the expected paths.
Verification
No executable files should reappear in uploads through normal traffic, scheduled tasks or restarts, and legitimate media uploads must continue to work without restoring excessive permissions.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Deleting one shell does not reveal how it arrived or whether another loader can recreate it. Timestamps, ownership, access logs and related files connect the payload to an entry point.
- List every executable extension and suspicious double extension under uploads.
- Record hashes, timestamps, owner and paths before quarantine.
- Match creation times with access, plugin upload and authentication logs.
- Search for references to the files in cron, options, themes, plugins and server rules.
What must be verified
- No executable files remain in writable media directories.
- The server refuses execution attempts under uploads.
- Monitoring shows no recreation and the original write path is closed.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it enough to just delete the malicious PHP file once I find it in uploads?+
No. Deleting the file removes the immediate payload but does not reveal how it got there or whether a separate loader can simply recreate it. Timestamps, ownership, access logs, and related files need to be traced back to the actual entry point before the incident can be considered closed.
Should I open the suspicious PHP file in a browser to see what it does?+
No, this is explicitly unsafe. A web shell can execute attacker logic the moment it is requested, so it should be analyzed as a preserved offline copy rather than triggered live, on the assumption that any request to it could run malicious code.
Why does malware keep appearing in wp-content/uploads specifically, rather than in plugin or theme folders?+
The uploads directory is normally meant only for media, but it is writable by WordPress and frequently survives full plugin or core replacement, which makes it an attractive target for attackers wanting a payload that persists through cleanup.
If only one site is affected, should other sites on the same server be checked too?+
Yes. When multiple sites share the same hosting account or system user, a vulnerable upload endpoint or stolen credentials on one site can be used to write files into others, so neighbouring sites and accounts sharing that system user should be scanned as well.