How to Check If Your WordPress Core Files Were Modified

There’s a specific, verifiable way to answer “has someone changed my WordPress core files,” and it doesn’t require guessing based on file names or trusting a plugin’s word for it. WordPress publishes official checksums, a kind of fingerprint, for every single file in every release, specifically so this comparison is possible.

Here’s how it actually works, and how to run it yourself right now.

What a Checksum Actually Proves

A checksum is a short string generated from a file’s exact contents. Change even one character inside that file and the checksum changes completely. WordPress.org calculates and publishes the correct checksum for every core file in every release, at a public, official endpoint anyone can query.

That means checking your core files isn’t a matter of “does this look right to me.” It’s a direct comparison: does the file on your server produce the exact same checksum as the official version WordPress actually shipped. If it doesn’t, something changed it, and it wasn’t a normal WordPress update.

Doing This Yourself With WP-CLI

If you have command-line access to your site (many hosts provide this, and it’s genuinely worth learning if you manage WordPress regularly), WP-CLI has a real, built-in command for exactly this:

wp core verify-checksums

Run that from your WordPress root directory and it downloads the official checksums for your exact installed version, compares them against your actual files, and tells you plainly:

Success: WordPress installation verifies against checksums.

or, if something’s wrong:

Warning: File doesn't verify against checksum: wp-includes/version.php
Error: WordPress installation doesn't verify against checksums.

There’s also a version for checking your installed plugins the same way, at least the ones distributed through WordPress.org:

wp plugin verify-checksums --all

Worth knowing the limit here honestly: this only works for plugins actually hosted on WordPress.org, since that’s the only place official checksums exist for third-party code. A premium plugin you bought directly from a developer has no public checksum to compare against, there’s nothing wrong with that plugin, it’s just outside what this specific technique can verify.

What a Real Result Actually Tells You

A clean result is genuinely reassuring, but it’s worth being precise about what it does and doesn’t mean. It confirms your core files match the official release exactly. It says nothing about your database, your uploads folder, or any custom code, because those were never part of the official release to begin with, there’s no “official” version of your specific content to compare against.

A flagged file needs a closer look, but not automatic panic. Occasionally a host or an unusual setup legitimately modifies a core file for a real reason. Most of the time, though, an unexpected core file mismatch is exactly what it looks like: something changed a file that should never change outside of an official WordPress update.

The Case for Doing This Regularly, Not Just Once

Running this command once, right now, tells you about right now. It doesn’t tell you if something changes next week. The genuinely useful version of this check happens automatically and repeatedly, comparing your files against the current official checksums every day, so a change gets noticed within hours instead of whenever you happen to think to check again.

That’s the difference between a one-time check and actual monitoring. Manually running wp core verify-checksums is a completely legitimate thing to do right now if you’re worried about a specific incident. It’s not something most people are realistically going to do every single day, forever, by hand.

What This Looks Like Automated

SecondGate runs this exact kind of comparison daily, against WordPress.org’s own official checksums, the same underlying data WP-CLI uses. If something doesn’t match, it can optionally restore the file automatically, pulling the replacement directly from WordPress.org’s own official release archive and verifying the checksum matches before and after writing, never overwriting anything with something merely assumed to be correct.

Files that shouldn’t exist at all, ones with no official version to compare against, get quarantined rather than deleted, moved somewhere they can’t execute, but never destroyed, in case it turns out to be a false alarm.

Get free access to SecondGate

Source: WP-CLI’s official core verify-checksums documentation