Verifying WordPress Core Files Against Official Checksums

By · Updated · 4 min read

Most of the effort in a cleanup goes into deciding whether a file belongs. For everything inside WordPress core, that question has a definitive answer available for free, because WordPress publishes a cryptographic hash for every file in every release. Comparing your install against that list takes one command and produces a list of exactly what has been changed or added.

What a checksum actually proves

A checksum is a fingerprint computed from a file's contents. Change one character and the fingerprint changes completely. WordPress.org publishes the fingerprints for every file in every official release, so you can compute the fingerprints of your files and compare.

The result is binary and reliable: either your copy of a core file is byte-for-byte identical to the official release, or it is not. There is no judgement involved and no signature database to fall behind, which is why this is one of the few checks in security work that gives a genuinely definitive answer.

The one-command version

If you have shell access and WP-CLI, the whole job is wp core verify-checksums. It downloads the official hashes for your exact version, checks every core file, and reports anything that does not match along with anything present in core directories that should not be there.

Two kinds of finding come back. A file that does not match means its contents were changed — commonly injected code appended to a legitimate file. A file that should not exist means something was added to a core directory, which is where fake core files hide. Both deserve immediate attention, and neither is ambiguous.

Doing it without WP-CLI

Without shell access you can achieve the same thing by comparison. Download the exact WordPress version you are running from wordpress.org, unzip it locally, and compare it against a copy of your site's core directories. Any decent folder comparison tool will show you added files and changed files in seconds.

Getting the version exactly right matters, since comparing against a different release will flag hundreds of legitimate differences and drown the real findings. Your version is shown at the bottom of the WordPress dashboard. Several security plugins also implement this check in their own scanning, which is a reasonable substitute if a manual comparison is impractical.

What this does and does not cover

It covers core comprehensively: everything in wp-admin and wp-includes, plus the core files in your web root. That is a large fraction of the files on a typical site and it is now definitively accounted for, which is enormously useful narrowing.

It does not cover wp-content. Your plugins, themes and uploads are not part of core and have no official checksums, so the verification stops at the boundary. Plugins and themes from the repository can be compared against fresh downloads individually, which is the same technique applied by hand, but your uploads and any custom code remain a matter of judgement.

Acting on the results

For modified core files, do not try to edit the injected code out — reinstall core cleanly, which replaces every core file with the official version in one step and is both faster and more reliable than surgery. For unexpected files in core directories, read them to understand what they do, then delete them.

Then keep going, because a modified core file means something had write access to your site and core was not necessarily the only thing it touched. Check wp-content thoroughly, sweep the database, audit administrator accounts, and look for persistence in mu-plugins and scheduled tasks.

Making it routine

This check is cheap enough to run regularly rather than only during an emergency. It takes seconds, it needs no subscription, and a clean result on core removes a large area of doubt when you are trying to work out whether something is wrong.

It is also the check I run first on nearly every site I look at, precisely because it converts a vague worry into a specific list. If it comes back with findings and you would rather not work through what they mean, that is exactly the kind of case my malware removal service handles routinely.

Common questions

What does wp core verify-checksums actually check?

Every file in WordPress core — wp-admin, wp-includes and the core files in your web root — against the official hashes published for your exact version. It reports files whose contents differ from the official release and files present in core directories that should not exist.

Does it check my plugins and themes?

Not by default. Core verification covers core only. Plugins and themes from the repository can be compared against fresh downloads individually, but there is no single command that covers everything in wp-content, and custom code has nothing official to compare against.

Can I do this without command line access?

Yes. Download the exact WordPress version you run from wordpress.org, then compare its wp-admin and wp-includes folders against yours with a folder comparison tool. Getting the version exactly right is essential, or you will see hundreds of legitimate differences.

A core file failed verification. What do I do?

Reinstall WordPress core from a clean copy rather than trying to edit the injected code out. That replaces every core file with the official version in one step. Then keep investigating, because whatever modified a core file almost certainly touched other things too.

Does a clean checksum result mean my site is clean?

No, but it is valuable. It means core is definitively untouched, which eliminates a large area of doubt. Infections in plugins, themes, uploads or the database are entirely outside its scope, and those are where most WordPress malware actually lives.