A Core File Has Been Silently Altered — What It Means

What just happened

WordPress core — the files in wp-admin, wp-includes, and the files sitting in your site's root — should only ever change when you run a WordPress update. Every official release has a known, published checksum for every one of those files. SecurynAI compares the files actually on your server against those official checksums on a regular basis.

When a file doesn't match what it should be, and no update happened to explain the change, that's a core checksum mismatch — the alert you just received.

Is this actually bad?

Usually, yes, and it's treated as a high-severity finding by default. A modified core file outside of an update is one of the most reliable signs of a compromise: it's a classic way attackers plant a backdoor, because core files are trusted by definition and rarely inspected line-by-line by a human.

There are two situations where the severity gets adjusted automatically:

• If the same file was already flagged by malware scanning, the finding gets escalated to critical — two independent signals agreeing is a much stronger indicator than one.
• If the change looks benign on closer inspection, it can be downgraded — but it still shows up, it's never silently dismissed.

If WordPress core couldn't be verified at all (for example, if the official checksum service was temporarily unreachable when the check ran), you'll see a separate, lower-severity "unverifiable" finding instead — that's a "we couldn't confirm either way," not a "you're fine."

What to check

• Did you or your host just run a WordPress core update? If the timing lines up exactly, this may be a false alarm from a check that ran mid-update — but confirm the file content matches the official release before dismissing it.
• What does the diff actually show? Injected code that adds an HTTP call, an eval(), a base64_decode(), or references to an unfamiliar domain are strong signs of tampering, not a benign edit.
• Has anything else happened recently? A modified core file is exactly the kind of signal that gets grouped with other findings (new admin accounts, unusual logins) into a single incident if they're related — check whether this alert is part of a larger picture.

What to do

• Restore the file to its official version. Since core files should never be hand-edited, the safe move is almost always to overwrite the modified file with the clean, official version — not to try to "fix" the injected code manually.
• Don't stop at one file. If one core file was altered, check whether others were too, and extend the same scrutiny to your plugins and themes.
• Change credentials if you find anything conclusive. If the modification is confirmed to be malicious, assume the access that made it possible is still open until you've addressed it directly.

Why this matters even if the change looks small

A one-line addition to a core file can be enough to grant an attacker persistent access, log credentials, or serve malicious content to only some visitors (making it easy to miss on a casual look). Treat "small change" and "low risk" as two separate questions — they're not the same thing here.