To verify WordPress core files with WP-CLI, run wp core verify-checksums against the correct installation. The command compares the files with the official WordPress release. Read both the success message and any warnings: a match checks core file integrity, but it does not certify the entire website as malware-free.
Last updated: September 6, 2026. Skill level: intermediate; SSH access required.
This guide covers a read-only integrity check for self-hosted WordPress. It does not replace an incident investigation or explain how to remove an infection. The examples work independently of the block or Classic Editor.
What does a WordPress checksum check actually verify?
A checksum check compares the contents of a file against a reference fingerprint for the same WordPress version and language package. A difference tells you the file is different, not why it changed. An interrupted update, an intentional edit, and an unauthorized modification all need investigation rather than an automatic deletion.
According to the WP-CLI command reference, reviewed September 5, 2026, this command obtains WordPress.org checksums and runs before WordPress loads. That makes it useful when you want to inspect core without executing the site’s normal plugin stack.
Keep the scope clear: uploaded images, database content, user accounts, custom code, plugins, and themes require separate checks. For a plugin-selection overview, see our WordPress security plugin comparison.
What should you prepare before running the command?
Prepare authorized SSH or hosting-terminal access, the exact WordPress document root, a working WP-CLI installation, and a place outside the public web directory to keep the results. The verification command does not repair files. If you later decide to replace anything, preserve evidence and create a recoverable backup first.
- Confirm which domain and environment you are inspecting. A staging directory can look almost identical to production.
- Ask your host for the document root if you are unsure. Do not infer it from a folder name alone.
- Open the terminal as the hosting account user. Avoid running routine WordPress commands as the operating system’s root user.
- Keep the result private if it includes internal paths or filenames. Send a redacted copy when requesting help.
The WordPress developer walkthrough for WP-CLI security checks explains how to locate the installation and use hosting-provided command-line access. If terminal access is unavailable, ask the host to run the check and return its complete result.
How do you run the core checksum check?
Point WP-CLI at the installation with --path, then run the checksum command. Use the installed release as the reference rather than the latest release number. If the tool reports a language or version mismatch, confirm those values before interpreting the output as an unexpected file change.
Replace the example path below with the document root supplied by your host. These are terminal commands, not PHP to paste into a theme or plugin:
wp --info
wp core version --path=/path/to/wordpress
wp core verify-checksums --path=/path/to/wordpressIf explicit version and locale values are necessary, use the values for that installation. This is the command used for our isolated demonstration, not a recommendation to install this older release:
wp core verify-checksums --path=/path/to/test-copy --version=6.9.4 --locale=en_USAfter running the command, read the complete output. A successful exit code is useful for scripts, but do not discard warning messages. If you want a broader inventory of unexpected items at the installation root, run a separate check with --include-root and review the additional findings individually.
What happened in our controlled checksum test?
In our September 5, 2026 test, a fresh WordPress 6.9.4 English download passed verification. We added one harmless HTML comment to its readme file, which caused verification to fail. Restoring the original bytes returned the check to a pass. No live website files were changed for this experiment.
| Test state | Observed outcome | Exit code |
|---|---|---|
| Fresh official download | Core files matched | 0 |
| Comment appended to readme.html | Modified file identified | 1 |
| Original readme.html restored | Core files matched again | 0 |
The modified-file run identified readme.html. The experiment demonstrates sensitivity to changed file contents; it does not demonstrate malware detection. A harmless edit and a malicious edit can both cause a mismatch. The useful next question is whether the difference is expected and supported by your deployment history.
You can reproduce this comparison in a disposable download using your own release. Keep the original file outside that copy, make a clearly documented change, compare the results, and restore it. Do not create artificial mismatches on production just to test the command.
How should you interpret warnings and failures?
Separate mismatched files, missing files, unexpected files, and failures to retrieve reference checksums. They are different findings with different next steps. A network error means verification could not complete. A mismatch means comparison completed for that file and found different contents. Neither message alone identifies an attacker or a cause.
| Finding | Sensible next step |
|---|---|
| File differs from its reference | Compare with the correct release and check deployment records |
| Expected file is missing | Investigate an incomplete update, deletion, or packaging difference |
| Unexpected file is reported | Identify its owner and purpose before changing it |
| Reference download fails | Resolve connectivity, certificate, version, or locale issues and retry |
An unexpected log file is still worth reviewing, but its name alone is not proof of infection. Similarly, do not add a suspicious file to an exclusion list merely to produce a passing result. Record why an exception exists and who approved it.
Keep certificate validation enabled. If reference retrieval fails over HTTPS, fix the connection or ask the host for help instead of weakening the transport check.
What should you check after core verification?
Choose the next check from the symptom you are investigating. Core verification cannot explain a suspicious administrator, a redirect stored in the database, or a modified premium plugin. Preserve the report, compare it with your maintenance history, and pass unresolved findings to the person responsible for recovery before making changes.
For WordPress.org-hosted plugins, WP-CLI has a separate plugin verification command. Checksum availability differs for commercial and custom packages; a missing reference is not a malware verdict.
If unknown accounts are the concern, use our guide to finding rogue WordPress administrators. For a confirmed incident, continue with the relevant WordPress cleanup workflow and your host’s incident-response process.
Frequently asked questions
Does this command change my website?
The core verification command compares files and reports results; it does not replace them. Keep subsequent repair commands separate so a diagnostic check does not become an unplanned production change.
Does a successful checksum check mean my site is secure?
No. It establishes a match for the checked core files. Database content, accounts, uploads, plugins, themes, server configuration, and other access paths remain outside that conclusion.
Why can an intentionally edited file fail verification?
The reference represents the distributed release, not your customized copy. Even a harmless content change can produce a different fingerprint, as our readme experiment demonstrated.
Should I delete every unexpected file?
No. Identify the file and preserve relevant evidence first. Some extra files have legitimate operational uses, while others need investigation. A filename alone is insufficient to decide.
Leave a Reply