WordPress itself is made up of hundreds of files in wp-admin, wp-includes and the site’s root folder. On a healthy site, none of them should ever change except during an update. That makes them one of the easiest parts of a site to check after a suspected hack, because there is an exact reference copy to compare them with.
This post explains how a core file integrity check works, the ways to run one with or without command-line access, how to read the results, and the important limits of what it tells you. It is aimed at owners and site managers who want to confirm whether WordPress has been tampered with, without guessing from file dates.
What “integrity” means here
For every WordPress release, WordPress.org publishes a checksum for each core file. A checksum is a short string calculated from a file’s exact contents. Change one character in the file and the checksum changes completely. If your copy of wp-includes/version.php produces the same checksum as the official one for your version, it is byte-for-byte identical to the file WordPress.org released.
A core integrity check simply calculates the checksum of every core file on your server and compares it with the published list. Anything that does not match has been changed. Anything on the published list that is missing has been deleted. Some tools also report files that sit inside the core folders but are not part of WordPress at all.
That is the strength of the method: it does not depend on recognising a particular piece of malware. A scanner looking for known malicious patterns can miss new or heavily disguised code. A checksum comparison does not care what the change is. It only cares that there is one.
Why attackers modify core files
Core files load on every request to the site, so code injected into them runs everywhere. Files such as wp-load.php, wp-settings.php, wp-blog-header.php and files inside wp-includes are favourite targets for that reason. A few lines added at the top of one of them can redirect visitors, inject spam for search engines or reopen a backdoor every time a page loads.
Attackers also add new files inside wp-admin or wp-includes, often with names that look official, such as wp-config-sample-backup.php or class-wp-cache.php. Owners rarely look in those folders, so a file there can go unnoticed for a long time. If you already know the site is compromised and need it handled as a whole, our hacked website repair page sets out how we approach it; the rest of this post is about the check itself.
Method 1: WP-CLI
If your host gives you SSH access and WP-CLI, the WordPress command-line tool, this is the quickest and most reliable route. From the folder where WordPress is installed, run:
wp core verify-checksums
WP-CLI works out which WordPress version you have, downloads the official checksums for that version from WordPress.org, and compares every core file. If everything matches, it reports success. If not, it lists each problem. The two messages you are most likely to see are that a file “doesn’t verify against checksum”, meaning it has been changed, and that a file “should not exist”, meaning it is inside a core folder but not part of the release.
The official documentation for the command, including its options, is on the WordPress developer site.
WP-CLI has a matching command for plugins:
wp plugin verify-checksums --all
This compares installed plugins against the versions published in the WordPress.org plugin directory. It cannot check premium plugins bought elsewhere, or custom plugins, because there is no public reference copy for them. Those will show as skipped or unverifiable, which is not the same as clean.
Method 2: a security plugin
Without SSH, a security plugin is the usual alternative. Wordfence’s scanner, for example, can compare core, theme and plugin files against the versions in the WordPress.org repository and flag differences. Other security plugins have similar file comparison features.
There is a catch. A plugin runs inside the WordPress installation it is checking. If an attacker controls the site, they can in principle interfere with what a plugin sees or reports. That is rare in practice, but it is one reason to treat a plugin scan as a strong hint rather than proof, and to repeat important checks from outside WordPress where you can.
Method 3: compare by hand
With nothing but FTP or the host’s file manager, you can still compare, more slowly. Find your WordPress version in wp-includes/version.php, download the same version from WordPress.org’s release archive, and compare the folders. A file comparison tool on your own computer makes this practical, as it will highlight files that differ or exist only on one side.
Make sure the versions match exactly. Comparing against a newer release will flag hundreds of legitimate differences and hide the one that matters.
Reading the results
A clean result means the WordPress core matches the official release. It is good news, but it is narrower than it sounds, as the next section explains.
If files fail the check, look at each one before replacing anything. Open it in a text editor and look at the difference. Typical findings include:
- Obfuscated code at the top or bottom of a file, often a long line using base64_decode, eval or similar functions.
- An include line pulling in a file from an odd location, such as an image folder or a file with a random name.
- Small, readable edits that redirect visitors from search engines or show different content to crawlers.
Occasionally a mismatch has an innocent cause. A previous developer may have edited a core file directly, which is bad practice but not malicious. A hosting company may add a small file of its own in the root folder. A failed update can leave some files from the old version and some from the new. Each of these still needs fixing, but none of them means a hack.
Files that “should not exist” deserve particular attention. Old WordPress versions sometimes left files behind that later releases removed, and those are usually harmless. Unfamiliar PHP files with plausible names are a different matter, and should be read carefully before deletion.
What the check does not cover
This is the part people most often misunderstand. A core integrity check covers WordPress core and nothing else. It does not look at:
- wp-config.php, which is unique to each site and so has no reference checksum. It is a common hiding place for injected code. Read it yourself, and compare it with wp-config-sample.php if you are unsure what belongs there.
- Anything in wp-content, which is where your themes, plugins and uploads live. Most malware sits here. Plugin checksums help for directory plugins, but themes, premium plugins and uploads need other checks. PHP files in the uploads folder, for instance, are covered in our post on why PHP in uploads is a red flag.
- .htaccess and other server configuration files, which can redirect visitors or change how files run.
- The database, where injected scripts, spam content and rogue admin users are stored.
- Files outside the WordPress folder, such as other sites on the same hosting account or scripts above the web root.
So a clean core check means one specific part of the site is untouched. The rest of the site could still be badly infected. Our guide to scanning a website for malware covers the other tools you need alongside it, and what each of them misses.
Fixing modified core files
Once you have copied the modified files somewhere safe as evidence, the simplest fix is to replace all of core with a fresh copy of the same version.
From the dashboard, Dashboard then Updates offers a button to reinstall the current version. With WP-CLI, wp core download --force --skip-content downloads a fresh copy of core over the existing files without touching wp-content. By hand, upload fresh wp-admin and wp-includes folders and the root files from the downloaded zip, leaving wp-config.php and wp-content alone.
Note that all three methods overwrite files but do not delete extras. A backdoor added to wp-includes with its own name will survive a reinstall. After reinstalling, run the check again and remove any file still reported as one that should not exist, after reading it.
If WordPress is out of date, this is also the time to update it. Our comparison of core, plugin and theme updates explains what each kind of update changes.
Running it as a habit
A core integrity check is quick enough to run regularly, not just after a hack. Running it after every core update confirms the update finished properly. Running it weekly or monthly on a site you look after can catch a compromise early, sometimes before any visible symptom appears. Some hosts and security plugins can run file change checks on a schedule and email you the results.
It is also a useful first check when taking over a website from another developer, because it tells you quickly whether core has been edited, cleanly or otherwise.
If your check finds changed core files, the important question is how they were changed, because whatever modified them is probably still present elsewhere. That is what our backdoor removal service is for. Message us on WhatsApp starting with the word HACKED if you would like us to look at your results.
Next in this series: Website Security Incident Plan: A One-Page Template
