What matters first: A monitoring tool reports that files were added, modified or removed. The alert is valuable evidence only when compared with an expected deployment and trusted release.
What this symptom actually tells you
Restoring every changed file can erase legitimate work or attacker evidence. Paths, hashes, owner and process history help separate routine changes from unauthorised writes.
Capture evidence before changing anything
- Export the complete change set with old/new hashes and timestamps.
- Compare it with deployment, update and administrator activity.
- Verify core, plugin and theme files against exact trusted packages.
- Prioritise executable files in uploads, root, mu-plugins and recently writable paths.
Most common causes
- Legitimate update: A controlled component release changed expected files.
- Manual hotfix: An authorised edit occurred outside version control.
- Failed deployment: Only part of a release was copied.
- Compromise: Unknown code or changes appear without a legitimate actor.
Safe diagnostic and repair sequence
- Preserve suspicious files and relevant logs before replacement.
- Restore from trusted releases only after classifying custom changes.
- Close the write path, rotate credentials and inspect persistence if unauthorised.
- Establish a clean baseline and monitor for recurrence.
How to choose between the likely causes
Do not treat Legitimate update and Manual hotfix as interchangeable. A controlled component release changed expected files. By contrast, an authorised edit occurred outside version control. Use two checks to separate them: Export the complete change set with old/new hashes and timestamps; and compare it with deployment, update and administrator activity. Those observations usually show whether the next safe move is to preserve suspicious files and relevant logs before replacement or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not approve a new integrity baseline while unexplained changes remain. That converts attacker files into “known good.”
How to verify the repair
- Every changed file has a documented source or is removed.
- Trusted checksums and deployment manifests match.
- No unexplained write occurs after the new clean baseline.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Restoring every changed file can erase legitimate work or attacker evidence. Paths, hashes, owner and process history help separate routine changes from unauthorised writes.
- Export the complete change set with old/new hashes and timestamps.
- Compare it with deployment, update and administrator activity.
- Verify core, plugin and theme files against exact trusted packages.
- Prioritise executable files in uploads, root, mu-plugins and recently writable paths.
What must be verified
- Every changed file has a documented source or is removed.
- Trusted checksums and deployment manifests match.
- No unexplained write occurs after the new clean baseline.
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.
Should I restore every file an integrity monitor flags as changed?+
No. Restoring every changed file indiscriminately can erase legitimate work just as easily as it removes attacker evidence, since updates, manual hotfixes and failed deployments all produce the same kind of alert. Compare paths, hashes, owner and process history against your deployment records before restoring anything.
What's the difference between a failed deployment and an actual compromise here?+
A failed deployment shows only part of an expected release was copied, which you can confirm by comparing the change set against deployment and update records. A genuine compromise shows unknown code or changes with no legitimate actor behind them, which is why exporting the full change set with hashes and timestamps before acting is the key diagnostic step.
Is it fine to approve a new integrity baseline once the alerts stop appearing?+
No, this is called out as a mistake to avoid. Approving a new baseline while unexplained changes still exist effectively relabels attacker files as known good, so every changed file needs a documented source or removal before you reset the baseline.
Which changed files deserve the most urgent attention?+
Prioritize executable files in uploads, the site root, mu-plugins and any recently writable paths, since these are the locations most likely to run attacker code rather than hold static assets.