WordPress File Integrity Checks: What WP-CLI Checksums Actually Prove

Security guidance · References checked 2 November 2026

In this guide

1. Understand the reference and the scope
2. Check WordPress core from a trusted environment
3. Check repository plugins and record missing coverage
4. Interpret a mismatch before replacing anything
5. Inspect the gaps outside the checksum result
6. Repair, then repeat the defined checks
7. What to ask for in the final report

A file-integrity check compares installed files with a reference. That makes it useful when investigating unexpected WordPress changes, but it is not a complete malware assessment. A successful checksum result answers a limited question about the files checked; it does not prove that your database, uploads, credentials and hosting account are clean.

Before running tools, identify the correct WordPress installation, the component versions and the source you will use for comparison. Preserve a snapshot and the available logs when investigating a possible incident. Do not overwrite suspicious files before you have recorded what changed.

Understand the reference and the scope

A checksum is a fingerprint of file contents. If the installed file differs from the reference, its fingerprint changes. That difference might be malicious, but it could also be a legitimate customisation, a partial update, a modified translation package or an unexpected version mismatch.

Your report should name the component, installed version, expected reference, command used and any skipped items. “Files verified” is incomplete if it does not say which files or which reference. A missing reference is a gap in the check, not a pass.

The trusted reference matters as much as the comparison. Downloading a random ZIP from a discussion thread and matching against it does not establish integrity. Obtain the exact component release from WordPress.org, the legitimate commercial vendor or your controlled deployment repository, as appropriate.

Check WordPress core from a trusted environment

WP-CLI includes a core checksum command:

wp core verify-checksums

Use it only with authorised access and the correct installation context. WordPress documents that this command runs before WordPress loads. Its available options can differ with the installed WP-CLI release, so check the command’s help before adding flags from an article. Core checksum command reference.

A trusted command runner still needs a trusted environment. Review the WP-CLI configuration and any required bootstrap files with your host or responder if compromise is suspected. Do not execute an unknown “repair tool” found inside the affected account merely because it has a familiar filename.

Save the exact output, time and command context privately. A success message for core files does not cover every file elsewhere in the WordPress directory or every custom path your installation uses. Read warnings as well as the final line.

Check repository plugins and record missing coverage

For plugins with suitable WordPress.org checksum references, the corresponding command is:

wp plugin verify-checksums --all

The plugin checksum documentation explains its options and scope. Unlike the core pre-load check, plugin verification should not be assumed to avoid all WordPress bootstrap activity. On an actively compromised site, a specialist may prefer an isolated copy or another host-approved inspection method.

Commercial, custom or otherwise unsupported packages may not have the expected public checksum reference. An unavailable checksum response does not establish that a plugin is malicious or safe. Record it as unverified and arrange a comparison against the legitimate version-specific vendor package or controlled source.

Do not weaken TLS verification to make a failed checksum download succeed. Fix the certificate, connectivity or trusted environment problem. A comparison performed against an untrustworthy download defeats the purpose of the exercise.

Interpret a mismatch before replacing anything

For each unexpected result, ask whether the reference version and locale are correct, whether an update was interrupted and whether the developer intentionally changed the file. Then inspect the actual difference in a controlled environment. Preserve the original file, its path and relevant metadata for investigation.

A mismatch in a readme file deserves a different response from unexplained executable code, but neither should be interpreted from the filename alone. Likewise, an attacker-controlled timestamp can look ordinary. Treat modification times as clues, not a trustworthy history of who changed a file.

The WordPress Developer Blog demonstrates how checksum checks can identify changes and also leave some components unverified. Its examples are a useful reminder to examine coverage and warnings rather than treating one green result as a certificate. WordPress security checks with WP-CLI.

Inspect the gaps outside the checksum result

Build a separate list of areas that were not covered: custom themes, must-use plugins, uploads, configuration files, server rules, scheduled tasks and database content. The precise paths depend on the installation. A WordPress site can behave maliciously even when its core release files are unchanged.

Review access controls and unexpected users as a separate workstream. A stolen legitimate credential does not need to modify a core PHP file to cause harm. Similarly, unwanted JavaScript stored in content or settings may not appear in a filesystem comparison.

For an example coverage report, divide the findings into “matched trusted reference”, “different and awaiting review”, “no trusted reference available” and “outside this check”. That structure is more useful to an owner than a single clean/infected label. This is an example reporting method, not a claim that a particular site has passed.

Repair, then repeat the defined checks

After investigation, an approved repair may replace affected release files from the legitimate source, update vulnerable components and address the identified entry route. Do not replace the entire content directory blindly: it can contain original uploads, custom work and configuration your business needs.

Repeat the original checks with the correct updated reference, inspect the remaining gaps and test important website functions. On a store, that includes the supported checkout flow in a safe test environment, not a live charge made merely to prove that a page loads.

Document any intentional customisations that prevent an exact package match. Otherwise the next maintainer may mistake approved differences for a new compromise—or overlook new changes because the directory has always produced warnings.

What to ask for in the final report

Ask which versions were compared, where trusted packages came from, which checks passed, which files differed, which areas were excluded and what repairs were verified. Include the remaining uncertainties and a plan for follow-up.

If you also need to review ownership and write access, use the permissions and configuration guide. Integrity checks and permission reviews answer different questions. Both are useful, and neither justifies a promise of permanent protection or complete recovery by itself.

Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.