Verify WordPress Files After an Update with WP-CLI

An update replaces WordPress files, but it does not prove that every file on your server is now clean. Two WP-CLI commands, wp core verify-checksums and wp plugin verify-checksums --all, compare your files with the official copies on WordPress.org and tell you exactly which ones differ. You run them in a minute from cPanel Terminal or SSH, and they change nothing on your site.

Here is the context. WordPress 7.1.3 came out on 6 October 2026, and at the time of writing (18 October 2026) its release post lists 7 security fixes and 4 bug fixes. Sites with automatic background updates started updating on their own. That is good news, but an update only writes the files it ships. A file that someone changed or added before the update can still be sitting there afterwards.

By the end of this guide you will be able to run both checks, read every kind of result, and fix a failed check safely, with a full backup taken first.

What a checksum check actually is

A checksum is a short fingerprint calculated from a file's contents. Change one character in the file and the fingerprint changes completely.

WordPress.org publishes the fingerprints of every official core file for each version and language. The WP-CLI documentation describes the core command in one line: it "Verifies WordPress files against WordPress.org's checksums." WP-CLI downloads the list, calculates the fingerprints of your files, and compares them one by one.

Think of it like checking a delivery against the packing list from the shop. The shop's list says what should be in the box. If something in the box does not match the list, or there is something extra, you know before you start using it.

Why this matters: the core command runs on the before_wp_load hook, which means it works without loading WordPress itself. The documentation says this is for security reasons. If your site has a bad file, the check does not run that file to do its job.

There is one limit to keep in mind. The checksums only cover files that WordPress.org ships. Your theme customisations, your uploads and your settings are not on the packing list, so the tool cannot judge them.

Before you start

You need very little, and the checks themselves are read-only. The fixes later in this guide do write files, which is why the backup comes first.

• Shell access: cPanel Terminal or an SSH login. Your host must enable the SSH Access & Terminal feature for your account.
• WP-CLI installed. Many hosts include it. If not, you will install it in Step 2.
• PHP 7.2.24 or later on the command line, which WP-CLI requires.
• The path to your WordPress folder, for example ~/public_html or ~/public_html/blog.
• A fresh full backup before any fix. Step 1 shows how.
• About 5 minutes for the checks, plus 15 to 30 minutes if you need to fix something.
• Risk level: none for the checks; low to medium for the fixes, and low once you have a backup.

Quick tip: if you plan to use SSH regularly, set up key login instead of passwords. Our guide on SSH key login for cPanel hosting walks you through it.

Run the checks step by step

Step 1: Take a full backup first

The checks do not change anything, but the fixes in the troubleshooting section overwrite files. Take the backup now so you never have to think about it later.

In cPanel, find Backup Wizard (use the search box at the top of cPanel if you do not see it). Click Back Up, choose the full backup, set Home Directory as the destination, enter your email for a notice, and click Generate Backup. When it finishes, download the file from the Download section to your computer.

Heads up: the cPanel documentation says "You cannot automatically restore a full backup file in cPanel." A full restore needs your host, through WHM. For a quick self-service safety net, also take two partial backups in the same wizard: Home Directory (a .tar.gz file) and MySQL Databases (a .sql file). Those can be restored from cPanel yourself.

If you prefer a manual copy, download your WordPress folder over SFTP and export the database. Either way, keep one copy off the server. Our guide on backing up a cPanel site with an offsite copy and a test restore covers the full routine.

What you should see: a backup file in the Download list with today's date, and the same file saved on your computer.

Step 2: Open Terminal and make sure WP-CLI works

In cPanel, open Terminal. On first use you must read the warning and click I understand and want to proceed. Take that warning seriously: cPanel says commands entered there "can render your cPanel account inoperable." The commands in this guide are safe, but type carefully.

This command moves you into your WordPress folder and prints WP-CLI's details. Change public_html if WordPress lives somewhere else.

cd ~/public_html
wp --info

What you should see: a few lines of details, including one that starts with WP-CLI version:. If you see wp: command not found instead, WP-CLI is missing. Install it with the official Phar method below.

This downloads the WP-CLI Phar file (a single PHP archive that contains the whole tool) into your home folder and tests it.

cd ~
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info

The official handbook then makes it executable and moves it to /usr/local/bin/wp with sudo. On shared hosting you normally do not have sudo. Our suggestion, which is not from the handbook: keep wp-cli.phar in your home folder and run it as php ~/wp-cli.phar wherever this guide says wp. Test it once with php ~/wp-cli.phar --info before you rely on it.

Step 3: Verify the WordPress core files

This command compares every core file in wp-admin, wp-includes and the root wp-* files with the official checksums for your installed version.

cd ~/public_html
wp core verify-checksums

What you should see on a clean site is exactly one line:

Success: WordPress installation verifies against checksums.

A failed check looks like this. Each Warning names a file, and the final Error line tells you the overall result.

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

Step 4: Verify the plugins

This command checks every installed plugin against the checksums WordPress.org holds for that plugin's version.

wp plugin verify-checksums --all

What you should see is a success line that counts your plugins, like the example in the documentation:

Success: Verified 8 of 8 plugins.

If a plugin fails, WP-CLI lists the problem files, each with a message such as Checksum does not match or File was added, and the run ends with an error instead of the success line.

Quick tip: the default is --format=table. If you want to save the results or send them to a developer, --format=json or --format=csv gives cleaner output. If you want the strictest check, add --strict, which also treats small edits such as changes to readme.txt as errors.

Step 5: Look for unexpected files in the root folder

By default the core check only looks at WordPress files. The --include-root option adds every file and folder in the root of your WordPress install and warns about anything that is not part of WordPress.

wp core verify-checksums --include-root

What you should see: the usual success line, or warnings for extra items. Do not panic at the first warning. Many sites have legitimate extras in the root, such as a Google verification file or a .well-known folder. Read each name and decide if you recognise it. The troubleshooting section below explains how.

The complete command block

This is the whole check in one go. It changes nothing; it only reads files and prints results. Replace ~/public_html with your WordPress path.

cd ~/public_html
wp --info
wp core verify-checksums
wp core verify-checksums --include-root
wp plugin verify-checksums --all

If you use the Phar file from Step 2 instead of an installed wp, the same block looks like this.

cd ~/public_html
php ~/wp-cli.phar --info
php ~/wp-cli.phar core verify-checksums
php ~/wp-cli.phar core verify-checksums --include-root
php ~/wp-cli.phar plugin verify-checksums --all

A 5-minute routine after every update

Put this on a list and run it each time WordPress or a plugin updates, whether you clicked Update Now or the update ran on its own.

1. Open Terminal in cPanel, or log in over SSH.
2. Run the command block above.
3. If every line says Success, you are done. Note the date somewhere.
4. If anything fails, stop. Do not delete files yet. Take the backup from Step 1 if you do not already have today's copy.
5. Copy the full output into a text file so you have a record of what failed.
6. Work through the matching entry in the troubleshooting section.
7. Run the command block again until it is clean.

Why this matters: automatic updates are a good habit, and we recommend them. They work best with a backup plan around them, which our guide to WordPress auto-updates with a safe backup plan explains. The checksum routine is the missing last step: it tells you the result really matches the official release.

Made-up example: Amira runs a small bakery site. Her host auto-updated WordPress overnight. In the morning she runs the block. Core passes. One plugin, a contact form, shows File was added for a file called cache-helper.php. She did not add it, and the plugin's official package does not include it. She takes a backup, reinstalls the plugin from WordPress.org with the command in the troubleshooting section, runs the check again, and gets Success. Then she changes her WordPress and cPanel passwords, because an added file means someone or something had write access.

How to check it worked

After any fix, prove it with the same tools. Each check below has a clear expected result.

• Run wp core verify-checksums. Expected: Success: WordPress installation verifies against checksums.
• Run wp plugin verify-checksums --all. Expected: a Success: Verified line where both numbers match, for example 8 of 8.
• Run wp core verify-checksums --include-root. Expected: success, or only warnings for items you have identified and decided to keep.
• Open your site in a private browser window. Expected: the home page loads normally, and you can log in to /wp-admin/.
• In WordPress, go to Dashboard > Updates. Expected: the version and language match what you verified against.

If the plugin numbers do not match (for example 7 of 8), scroll up in the output. One plugin was skipped or failed, and the warning above the summary tells you which.

Troubleshooting

A core file fails the checksum

Symptom: Warning: File doesn't verify against checksum: followed by a path in wp-admin or wp-includes, then Error: WordPress installation doesn't verify against checksums.

Likely cause: the file was edited. Sometimes that is a developer who changed core directly (a bad practice, but common). Sometimes it is malware. Either way, an official core file should never differ.

Fix: take the backup first. Then this command downloads a fresh copy of the same version and overwrites the core files, while skipping the default themes and plugins. Replace 7.1.3 with the version shown under Dashboard > Updates.

wp core download --version=7.1.3 --skip-content --force

The documentation says --force "Overwrites existing files, if present." Run wp core verify-checksums again afterwards. If the same file fails again right away, something on the server is rewriting it, and it is time to call your host.

You might also see a warning saying File should not exist for an extra file inside wp-admin or wp-includes. That file is not part of the official release. Download it to your computer for reference, then delete it from the server and check again.

What about wp-config.php and edits to my theme?

Symptom: you edited your theme or wp-config.php and expected the check to complain, but it did not.

Likely cause: this is normal. Looking at the WP-CLI source code, the core check skips everything under wp-content and excludes wp-config.php. Your themes, uploads and settings file are yours, so there is no official fingerprint for them.

Fix: nothing to fix, but know the limit. A clean core result does not prove your theme or wp-config.php are clean. For a theme from WordPress.org, compare it with a fresh download. For wp-config.php, open it and look for code you do not recognise, especially long scrambled lines near the top or bottom.

A plugin cannot be checked

Symptom: a warning such as Could not retrieve the checksums for version 2.4.1 of plugin example-plugin, skipping. and a summary where the numbers do not match.

Likely cause: the plugin is not hosted on WordPress.org. Premium plugins, plugins bought from a marketplace and custom plugins have no published checksums there. This is our inference from how the command works; the documentation does not say it in words. It can also happen with a very old version that WordPress.org no longer lists.

Fix: for that plugin, ask the vendor how they publish file hashes, or reinstall it from a fresh copy downloaded from your account on the vendor's site. You can skip it in future runs so the output stays readable with --exclude.

wp plugin verify-checksums --all --exclude=example-plugin

If a WordPress.org plugin fails with Checksum does not match or File was added, take the backup, then reinstall that plugin over itself. This command overwrites the installed copy without asking.

wp plugin install example-plugin --force

The --force option "will overwrite any installed version of the plugin, without prompting for confirmation." Most plugins keep their settings in the database, so they usually survive a reinstall, but that is exactly why you took the backup.

The locale or version does not match

Symptom: several files fail at once, often wp-includes/version.php, readme.html and wp-config-sample.php.

Likely cause: WP-CLI compared your files against the wrong language or version. The documentation shows this exact set of warnings when --locale=ja is used on a site that is not Japanese.

Fix: go to Dashboard > Updates and note the version and language. Then pass both values. This example checks a British English site; replace the values with yours.

wp core verify-checksums --version=7.1.3 --locale=en_GB

If only readme.html fails because you or your host removed or changed it on purpose, you can skip that one file with --exclude="readme.html", the same way the documentation does.

An unknown file in the root with --include-root

Symptom: wp core verify-checksums --include-root warns about a file or folder that is not part of WordPress.

Likely cause: this can be harmless or not. Common harmless items are search engine verification files, a .well-known folder used for SSL validation, or an old .zip backup someone left behind. A random PHP file name you have never seen is a different story. Note that, in the source code, .htaccess, .maintenance, wp-config.php and wp-content are already excluded from this warning.

Fix: for each item, ask "do I know what this is and who put it there?" If yes, keep it. If it is an old backup file, move it out of the web root, because anyone can download it from your domain. If it is an unknown PHP file, download a copy for evidence, delete it from the server, then change your passwords and run all the checks again.

wp: command not found in Terminal

Symptom: wp: command not found (or bash: wp: command not found).

Likely cause: WP-CLI is not installed for your account, or it is installed somewhere that is not on your PATH (the list of folders the shell searches for commands).

Fix: ask your host whether WP-CLI is available, or follow Step 2 to download wp-cli.phar and run it with php ~/wp-cli.phar. If php itself is not found or reports a version below 7.2.24, ask your host which PHP binary to use on the command line.

The check fails with a TLS or download error

Symptom: WP-CLI cannot download the checksum list and mentions a failed TLS handshake.

Likely cause: an outbound network or certificate problem on the server.

Fix: do not add --insecure. The documentation warns that it retries the download without certificate validation, which makes the request vulnerable to a man-in-the-middle attack. That would defeat the whole point of a security check. Ask your host to fix outbound HTTPS from the server, then run the check again.

Security notes and when to ask for help

A checksum failure is a clue, not a verdict. A developer's old edit and a hacked file look the same in the output. What tells them apart is whether you can explain the change.

Heads up: if you find added PHP files in core or in plugins, treat the site as compromised until proven otherwise. Reinstalling files removes what you can see, but it does not tell you how the file got there. Change your WordPress admin, cPanel, SFTP and database passwords, and remove admin users you do not recognise.

Ask your host or a developer when a file comes back after you replaced it, when you see failures in many plugins at once, or when the site breaks after a reinstall. Send them the saved output from the routine; it saves everyone time.

Quick tip: only reinstall from WordPress.org or from your plugin vendor's own site. A plugin or WordPress zip from a random download site cannot be trusted, even if its name looks right.

The one message worth forwarding

Copy this to your developer, your host or the person who manages the site:

"Hi, after each WordPress update, could you please run these from the WordPress folder and send me the output: wp core verify-checksums, wp core verify-checksums --include-root and wp plugin verify-checksums --all? If anything fails, please take a full backup (files and database) before changing anything, then reinstall the affected files from WordPress.org with wp core download --version=<our version> --skip-content --force or wp plugin install <plugin> --force, and run the checks again until they all say Success. Please do not use --insecure. Thanks."

The takeaway: an update gives you new files, and a two-command checksum check tells you they really are the official ones.