A WordPress core checksum mismatch tells you that one or more core files differ from the trusted release you expected. It does not tell you why. The cause can be an incomplete update, a manual change, filesystem corruption or a compromise, so the safe response is classification before replacement.
Confirm the exact WordPress version before comparing files
Checksums are meaningful only against the matching release. Record the installed core version, locale where relevant and the exact files that fail comparison. Separate missing files, modified files and unexpected additions.
What the mismatch pattern can tell you
- A small set around a recent update may indicate a partial deployment.
- A hand-edited core file may be legitimate history but still needs to be removed from core.
- Unexpected PHP files or modifications with no known owner require incident triage.
- Repeated changes after replacement indicate an active writer, not simple corruption.
Preserve evidence before restoring trusted core
Save hashes, timestamps and copies of suspicious files outside executable paths. Compare the broader change set with WordPress file-integrity triage before deciding whether the mismatch is isolated or part of a larger incident.
Restore core without overwriting application content
- Back up the site and preserve suspicious files.
- Replace only WordPress core files from the exact trusted release.
- Do not overwrite
wp-contentor configuration as part of a blind core refresh. - Patch the update/deployment path or remove the writer that caused the mismatch.
Do not treat a clean checksum as proof the incident is over
A core refresh can temporarily remove altered files while a compromised plugin, account or scheduled task remains able to write them again.
Verification
Run the checksum comparison again after normal traffic, scheduled tasks and any deployment process has executed. The same trusted core must remain stable and no unexplained file should reappear.
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.