How to Check If Your WordPress Core Files Were Modified

WordPress core files, the ones in wp-admin, wp-includes and the root of your site, are never meant to change between updates. Plugins live in wp-content, and so does your theme and everything you upload. So if a core file differs from the official release, either someone edited it by hand (a bad idea) or malware did.

Checking takes a minute. WordPress.org publishes a checksum, a fingerprint, for every file of every release. You compare your files against it.

Why attackers edit core files

Malware wants to survive. Plugins and themes get updated, deactivated and deleted. A line added to wp-includes/functions.php or wp-settings.php, or a new file such as wp-includes/class-wp-cache-helper.php that looks like it belongs there, keeps running on every page load. It stays there until the next WordPress update, and some infections re-add themselves after it.

Two things to look for:

• Modified files: a core file whose contents differ from the release.
• Extra files: PHP files inside wp-admin or wp-includes that are not part of WordPress at all. Nothing legitimate puts files there.

Option 1: WP-CLI (if you have SSH)

From the site’s folder, run:

wp core verify-checksums

A clean site prints Success: WordPress installation verifies against checksums. Otherwise you get a warning for each changed file (“File doesn’t verify against checksum”) and for each file that should not be there (“File should not exist”).

The same works for plugins downloaded from WordPress.org:

wp plugin verify-checksums --all

Premium plugins and anything not hosted on WordPress.org cannot be verified this way. WP-CLI will say it could not fetch their checksums.

Option 2: without SSH

Many shared hosts have no SSH, or only on higher plans. Without it you have two choices:

1. Re-install WordPress. Go to Dashboard → Updates and click Re-install version x.y.z. This overwrites every core file with a clean copy. Your content, plugins and themes are not touched. Extra files that malware added are not removed, though, so this is a repair, not a check.
2. Use a plugin that compares checksums. Several security plugins do this. The Pro add-on of the Ovanap Admin Toolkit does it as part of its Security Check. It downloads the official checksums, lists every modified, missing or unknown file in wp-admin and wp-includes, and stores the report so you can compare later runs.

What to do when a file does not match

1. Do not panic-delete. Note the file names first. If you have SSH, open the file and look at what was added, often a long encoded string or an eval( near the top or bottom.
2. Take a backup of the site as it is. If the cleanup goes wrong, you can go back, and the evidence is kept.
3. Re-install core from Dashboard → Updates, or with wp core download --force --skip-content --version=$(wp core version).
4. Delete unknown PHP files in wp-admin and wp-includes, after checking you noted them.
5. Check the places malware hides next: PHP files in wp-content/uploads (see PHP files in the uploads folder), unknown administrator accounts under Users, and must-use plugins in wp-content/mu-plugins.
6. Change passwords for every administrator, your hosting panel, FTP/SFTP and the database. Then replace the security keys in wp-config.php with fresh ones from api.wordpress.org/secret-key, which logs everyone out.
7. Find the way in. Usually an outdated plugin, a nulled theme or a reused password. If you do not close it, the files come back.

Frequently asked questions

Is wp-config.php checked?

No. It is created during install and is different on every site, so there is no official checksum for it. Look at it by hand. It should contain settings, not code that runs things.

A translation file or readme.html shows as changed. Is that bad?

Non-PHP files are low risk. Localized releases also ship slightly different files. WP-CLI uses the locale of your install, so most of these differences disappear when the checksums match your language. PHP files are the ones to worry about.

How often should I check?

After any security incident, when a site behaves oddly (unexpected redirects, spam pages in Google), and as a routine every month or so on client sites.