What matters first: WP-CLI compares installed core files with known hashes for the selected version and locale. Differences can come from incomplete updates, manual edits, wrong version files or compromise.
What this symptom actually tells you
Not every warning is malware, and not every malicious file is covered by core checksums. The file path, modification time and diff determine the response.
Capture evidence before changing anything
- Record WordPress version, locale and every mismatched or unexpected core path.
- Preserve copies and hashes before overwriting suspicious files.
- Compare modified files with the exact official release package.
- Check wp-content, users, cron and server logs because core verification covers only core.
Most common causes
- Interrupted update: A mixture of old and new core files remains.
- Manual core edit: A developer changed a WordPress file directly.
- Wrong package: Files came from another version or locale.
- Compromise: An attacker modified or added executable files in core directories.
Safe diagnostic and repair sequence
- Take a file and database snapshot before cleanup.
- Replace core with the exact trusted release while preserving wp-config.php and wp-content.
- Investigate unexpected modifications and the entry path if compromise is possible.
- Re-run checksums after cache purge and verify users, cron and writable directories.
How to choose between the likely causes
Do not treat Interrupted update and Manual core edit as interchangeable. A mixture of old and new core files remains. By contrast, a developer changed a WordPress file directly. Use two checks to separate them: Record WordPress version, locale and every mismatched or unexpected core path; and preserve copies and hashes before overwriting suspicious files. Those observations usually show whether the next safe move is to take a file and database snapshot before cleanup or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. 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 delete suspicious files before preserving hashes, timestamps and a copy when the incident may involve customer data or repeated compromise.
How to verify the repair
- Core checksums pass for the exact version and locale.
- No unexplained executable files remain in core or writable directories.
- The site stays stable and integrity monitoring shows no recurrence.
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
How to narrow the fault without guessing
Not every warning is malware, and not every malicious file is covered by core checksums. The file path, modification time and diff determine the response.
Record WordPress version, locale and every mismatched or unexpected core path.
Preserve copies and hashes before overwriting suspicious files.
Compare modified files with the exact official release package.
Check wp-content, users, cron and server logs because core verification covers only core.
What must be verified
- Core checksums pass for the exact version and locale.
- No unexplained executable files remain in core or writable directories.
- The site stays stable and integrity monitoring shows no recurrence.
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.
Does a checksum mismatch always mean the site is infected with malware?+
No. Interrupted updates, manually edited core files, or files copied from the wrong WordPress version or locale can all produce mismatches with no compromise involved. The file path, modification time, and an actual diff against the official release are what determine whether this is corruption or something worse.
If checksums come back clean, does that guarantee the site has no malware?+
No. Core checksum verification only covers WordPress core files, so malicious code placed in wp-content, uploads, or elsewhere outside core will not be flagged. wp-content, users, cron, and server logs need to be checked separately.
Is it okay to just delete the flagged files once they're identified?+
Not immediately. Suspicious files should have their hashes, timestamps, and a copy preserved before removal, especially if the incident could involve customer data or repeat compromise. Deleting first can destroy the evidence needed to confirm the entry point and prevent recurrence.
How do I tell an interrupted update apart from a deliberate manual edit to a core file?+
An interrupted update typically leaves a mixture of old and new core files consistent with a partial deployment, while a manual edit shows a deliberate, isolated change to one file that a developer made directly. Comparing the modified files against the exact official release package for that version clarifies which pattern is present.