A different kind of check than malware scanning
Most security scanning looks for known-bad patterns: signatures of known malware, suspicious code structures, files sitting somewhere they shouldn't. That approach is powerful but inherently reactive -- it can only catch what it's been built to recognize. Core file integrity checking asks a completely different, more absolute question: does this exact file, byte for byte, match what WordPress.org actually published for this version?
That distinction matters because a sufficiently careful attacker doesn't need to introduce an obviously suspicious file. A single modified line in a legitimate-looking core file -- one that doesn't trip any pattern-based scanner -- can be enough to create a backdoor. Checksum verification catches that regardless of how well the modification is disguised, because it doesn't care what the change looks like, only whether the file matches the official original.
How the checksums actually work
WordPress.org publishes an official release archive for every version, and a checksum -- a short cryptographic fingerprint -- can be computed for every file inside it. Two files are identical if and only if their checksums match; even a single-character change produces a completely different checksum. Building a checksum manifest directly from the official release archive, rather than trusting a list from a third party, means the comparison is always against the real, unmodified source.
A full scan checks every core file against this manifest and reports exactly three things: files present but modified, files that should exist but are missing, and unexpected PHP files sitting inside core directories that shouldn't contain any custom code at all. That last category catches a specific, common attacker pattern -- dropping a malicious file into a WordPress core folder where an admin is unlikely to look, since core directories are assumed to only ever contain official files.
What a failed check means, and what to do about it
A core file failing its checksum doesn't automatically mean compromise -- a failed or interrupted WordPress update can leave a file in an inconsistent state too, and that's worth ruling out first by checking whether an update was recently attempted. But a modified core file with no corresponding recent update, especially one paired with other findings like an unfamiliar admin account or a suspicious file elsewhere on the site, is a strong signal that something is genuinely wrong.
Because the WordPress.org release archive contains the exact correct version of every core file, the fix is a real repair, not a guess: download the matching official release and replace only the files that failed verification, leaving everything else untouched. WPFixAgent runs this exact check on a schedule and, when it finds a failure, can perform that precise repair automatically -- after taking a restore point first, so the repair itself is reversible if anything about the finding turns out to be more complicated than a simple modified file.