You delete an unfamiliar PHP file from a month-based uploads folder and it returns hours later. The reappearance proves that another process, account or request can still write it. Repeated deletion removes the symptom while leaving the persistence route active.
Contain execution, preserve a sample safely and identify the writer before restoring public access.
Preserve one occurrence
Record the full path, owner/group, permissions, size and modification time. Calculate a hash without executing the file:
sha256sum /quarantine/suspicious-file.phpWork on a quarantined copy outside the web root. Do not open the URL in a browser, include the file from PHP or upload it to an unapproved public scanner.
Preserve relevant web, PHP, SFTP and control-panel logs around the modification time.
Confirm whether PHP can execute in uploads
The uploads directory should normally contain media, not public PHP applications. Test server configuration from documentation and safe known files—never by executing the suspicious sample.
Use a supported server rule to prevent PHP execution in uploads where compatible with the hosting stack. Apache, Nginx and PHP handlers require different configuration; a copied .htaccess rule may not apply.
Treat this as containment. The writer can still place scripts elsewhere until the entry route is closed.
Correlate creation time with requests and jobs
Compare the file timestamp with access logs, WordPress cron, Action Scheduler, hosting cron, backups and security scans. Note timezone differences and timestamp changes caused by copying or restoration.
Look for upload endpoints, AJAX actions or unusual POST requests immediately before creation. Preserve request metadata without retaining passwords, cookies or customer uploads unnecessarily.
A creation time that matches no web request may point toward SFTP, panel access, cron or another compromised site.
Find the parent process or code path
Search a quarantined copy for the exact filename, distinctive string or code that writes into uploads. Review unknown plugins, must-use plugins, theme code and wp-config.php.
Inspect database options and scheduled callbacks that store encoded or executable content. Do not decode or run payloads on the production server.
If file auditing is available, configure it narrowly and temporarily to record future writes. Broad recursive monitoring on a busy account can create excessive load and sensitive logs.
Review upload vulnerabilities
Identify plugins and forms that accept uploads. Confirm extension validation, MIME handling, permissions and whether the component is current and supported.
Do not rely only on client-side file restrictions. Server-side validation and storage outside executable paths are required for custom upload features.
Patch or disable the vulnerable component after preserving its version and logs. Remove abandoned upload forms rather than hiding them.
Check account-wide access
Review WordPress administrators, application passwords, SFTP/FTP users, hosting sessions and cron. Rotate affected credentials after ensuring administrator devices and deployment systems are clean.
Inspect every site sharing the hosting account. A compromised sibling installation can write into another document root when permissions allow it.
Correct ownership and isolation rather than applying world-writable permissions to make updates work.
Clean and prove non-recurrence
Remove confirmed malicious files, replace trusted packages from verified sources, clean database persistence and close the vulnerable or stolen-access route.
Monitor the directory and original trigger window. Retest the upload feature with a harmless permitted file and confirm PHP is not executable from uploads.
A scanner remaining green for one minute is insufficient; observe scheduled intervals and the prior recurrence period.
When to request specialist cleanup
Request urgent help when files return, several sites share the account or logs show unknown POST/SFTP activity. Send paths and timestamps with usernames redacted—not the PHP sample or credentials.
The repair should explain who or what wrote the file and prove that both execution and reinfection paths are closed.