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.
Triage integrity alerts against a trusted release
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 the complete change set before restoring files
- 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.
Highest-risk paths to inspect first
- 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.
Restore only after classifying legitimate custom work
- 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.
Legitimate update or unexplained write?
A controlled update should map to a known release, operator and deployment window; an unexplained write has no trustworthy actor or package behind it. Compare hashes, timestamps and deployment history before restoring anything. A manual hotfix can be legitimate, but it should still have an identifiable owner and a decision about whether to preserve it in version control.
For core files, compare the alert with WordPress checksum mismatches. If the changed file is .htaccess and the modification returns after cleanup, follow the repeated .htaccess change path. Those cases need different evidence even though both appear as integrity alerts.
Do not approve a contaminated baseline
Do not approve a new integrity baseline while unexplained changes remain. That converts attacker files into “known good.”
Verify the new baseline stays quiet
- 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 clean baseline is justified only when every changed file has a documented source or has been removed, trusted packages and deployment manifests agree with disk, and monitoring shows no unexplained writes after normal updates and traffic.
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.