A PHP file is cleaned, then returns when a plugin setting is saved or a scheduled job runs. The payload may be stored in an option, template, snippet or plugin table, while plugin code writes that data into a cache or generated file.
Cleaning only the filesystem leaves the source intact; deleting database rows blindly can destroy legitimate configuration.
Build a trigger timeline
Record which action precedes the rewrite: settings save, cache regeneration, cron, page-builder compile or visitor request. Note the file path/hash before and after.
Preserve a database dump and plugin directory before repeating the trigger in an isolated staging copy. Do not continue generating malicious files on production.
Match timestamps across PHP, database and access logs.
Identify the writing component
Search verified plugin/theme source for the generated filename and directory. Determine which callback writes it and which database value supplies content.
Legitimate cache/minification plugins write PHP or JavaScript derivatives, so file-write behaviour alone is not malicious. Compare the stored value with known settings and inspect how it entered the database.
Do not execute generated output during analysis.
Locate the database source safely
Use read-only queries or WordPress-aware search tools for a distinctive payload string, external domain or option name. Avoid generic searches that return customer content.
Inspect options, posts/widgets, reusable blocks, snippet-plugin tables and scheduled-action arguments. Protect dumps because they may contain personal data and credentials.
Export the specific row before any change, preserving serialisation and encoding.
Determine whether the writer is compromised
Compare the plugin with its verified package. A clean plugin can faithfully compile a malicious database template; a modified plugin can inject code regardless of stored settings.
Review plugin version, update source, administrator actions and vulnerability history. Check whether the settings form lacked capability, nonce or input validation.
Patch both the data and code route. Removing one without the other allows recurrence.
Correlate database writes where logging permits
Managed database audit logs or binary-log records may show when and from which database user a value changed. Ask the provider before enabling verbose logging; it can affect performance and capture sensitive queries.
WordPress normally connects through one application user, so the database username may not identify the human actor. Correlate the timestamp with web/admin logs and application callbacks. Preserve only the relevant records and avoid exporting customer data into the incident report.
Clean without corrupting configuration
Use the plugin’s supported settings/reset method where available. For a targeted database change, work on a backup and preserve serialised structures through WordPress APIs.
Remove only confirmed malicious fields or rows. Rebuild generated files from reviewed data, or reinstall the plugin from a verified package.
Never run a broad SQL REPLACE across serialised options; changed string lengths can break deserialisation.
Review accounts and other persistence
Inspect administrators, application passwords, cron, SFTP/panel access and neighbouring sites. A stolen admin session may reinsert the database value.
Rotate affected credentials after securing endpoints. Review audit logs for the settings change and remove unknown automation.
Check database users and remote access if direct database compromise is possible.
Verify the full cycle
Delete/quarantine the generated malicious file, clean the database source and trigger the legitimate regeneration in isolated staging. Confirm output matches expected reviewed code.
Repeat scheduled runs and settings saves, then monitor production hashes and database values past the former return interval.
When specialist help is needed
Request an assessment when serialised options, snippet plugins or generated PHP are involved. Share option/table names and hashes with values redacted.
The repair should clean both storage and writer, preserve legitimate configuration and prove normal regeneration can no longer recreate malware.