No. The check confirms that plugin files on disk match the checksums WordPress.org holds for that release. A match means the files were not altered after download. It says nothing about whether the release itself has a vulnerability, and it cannot verify plugins that are not hosted on WordPress.org.
What the command does
The WP-CLI handbook describes the command as verifying plugin files against WordPress.org's checksums. You can name one or more plugins, or ask for all of them. A strict option makes even soft changes, such as edits to the readme file, count as errors. You can also verify against a specific version and choose table, JSON, CSV, YAML or count output.
wp plugin verify-checksums --all
A passing run prints a success line saying how many plugins were verified.
What a pass tells you
- The files you hold are byte for byte what WordPress.org published for that version.
- Nobody edited a file on the server after install, for example to inject code.
That is useful after a suspected compromise, because modified plugin files are a common sign of tampering.
What a pass does not tell you
| Question | Does the check answer it? |
|---|---|
| Were files changed on the server? | Yes |
| Does this release contain a known vulnerability? | No |
| Was the published release itself malicious? | No |
| Is this plugin still maintained? | No |
| Is a premium or custom plugin intact? | No, there is no WordPress.org copy to compare against |
If an attacker publishes a bad release through a compromised author account, the files on your server will match that bad release. The checksum check would pass.
A sensible place for it in your routine
- Run it after every incident or suspected intrusion on a client site.
- Run it on a schedule as a cheap tamper alarm, and alert on any failure.
- Pair it with a vulnerability check against your plugin inventory, since that is the question this command cannot answer.
- Keep a separate review for premium and custom plugins, which fall outside it.
One caution from the handbook: an insecure option retries downloads without certificate validation if the TLS handshake fails, and the handbook notes this makes the request vulnerable to a man in the middle attack. Do not use it in automation.
Core files have a sibling command, covered in our post on verifying WordPress core files.
Example reading of a result
Suppose the check passes for seven plugins and fails for one. Do not assume the failing one is the compromised one. A developer may have patched it by hand years ago. Compare the changed files with a clean copy of the same version and read the difference. If the change is unexplained, treat the site as suspect, restore the plugin from a clean download, and rotate credentials. If the change is a documented patch, move it into a proper child plugin or a vendor fix so the check can run clean from now on.
Quick check
Will it flag a plugin I edited on purpose?
Yes. Changed files fail verification, which is why direct edits to plugin code are a poor habit on client sites.
Does it work on premium plugins?
Not through WordPress.org checksums. Verify those another way, such as comparing against the vendor download.
Sources
Last reviewed: 19 October 2026.
