The command wp plugin verify-checksums checks WordPress.org-hosted plugin files against published checksums. It can reveal changed or unexpected files quickly, especially with --all and --strict. It cannot verify premium, private, custom, or repository-only plugins when no public checksum exists. A skipped plugin is not proof of compromise, but it is also not a clean result. The team needs a separate trusted package or build artifact for that code.
Use this during malware triage, plugin update verification, agency fleet reviews, unexpected PHP change investigations, and release checks for sites with both public and commercial plugins.
Quick answer
Run wp plugin list first, record exact versions and status, then run wp plugin verify-checksums --all --strict in a controlled shell. Export machine-readable output when possible. Split the results into verified, mismatch, checksum unavailable, and unmanaged plugin classes. Preserve a mismatch before reinstalling. For premium or custom plugins, compare against the vendor package, source commit, release artifact, or a known clean deployment instead of assuming a missing WordPress.org checksum means malware.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| WordPress.org plugin | Matching version | Official checksums verify |
| Premium plugin | No public checksums | Trusted vendor artifact required |
| Custom plugin | Repository commit | Deployed tree matches build |
| Unexpected PHP file | Preserved sample | Incident review before removal |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory every plugin class | Inventory active, inactive, must-use, drop-in, premium, custom, and WordPress.org plugins with exact versions and update availability. | Every installed plugin is assigned to an official, vendor, or internally built evidence source. |
| Verify public packages | Run checksum verification with TLS validation enabled and keep the command, output, host, path, version, and UTC timestamp. | All checksum mismatches are explained, preserved, and repaired or approved explicitly. |
| Preserve mismatches | Separate strict readme or metadata changes from executable PHP, JavaScript, binary, and unexpected-file changes. | Commercial and custom plugins match a trusted release package or source commit. |
| Compare private artifacts | For skipped commercial or custom code, obtain a trusted vendor ZIP, signed release, source commit, or build artifact and compare hashes independently. | The public workflow, logs, scheduled actions, users, and outbound traffic remain clean after repair. |
What to check first
- Inventory active, inactive, must-use, drop-in, premium, custom, and WordPress.org plugins with exact versions and update availability.
- Run checksum verification with TLS validation enabled and keep the command, output, host, path, version, and UTC timestamp.
- Separate strict readme or metadata changes from executable PHP, JavaScript, binary, and unexpected-file changes.
- For skipped commercial or custom code, obtain a trusted vendor ZIP, signed release, source commit, or build artifact and compare hashes independently.
- After repair, verify plugin behavior, hooks, scheduled actions, database options, administrator accounts, uploads, and outbound requests for persistence.
Field notes
- Write the expected result before making a change and keep one repeatable canary fixture.
- Record versions and timestamps because release, cache, and delivery behavior can change between tests.
- Use one canonical owner page for each query family and give every supporting page a distinct task.
- Close the incident only after the public workflow and the downstream record both pass verification.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin list --fields=name,status,version,update,update_version --format=csv
wp plugin verify-checksums --all --strict --format=json > plugin-checksums.json
# Do not use --insecure to hide a TLS problem.
# Compare skipped plugins with trusted vendor or build artifacts.
Why this usually happens
- Developers sometimes patch vendor files directly instead of using hooks or a maintained fork.
- Premium and private plugins are outside the WordPress.org checksum service.
- Failed updates can leave old and new files together.
- Malware commonly hides in writable plugin folders or adds files with plausible names.
Decision rule
Treat changed executable files and unexpected additions as incident evidence until explained. Treat unavailable checksum data as an ownership task. Reinstall only from a trusted source after preservation, and do not declare the site clean until persistence and runtime behavior also pass review.
Production verification checklist
- Every installed plugin is assigned to an official, vendor, or internally built evidence source.
- All checksum mismatches are explained, preserved, and repaired or approved explicitly.
- Commercial and custom plugins match a trusted release package or source commit.
- The public workflow, logs, scheduled actions, users, and outbound traffic remain clean after repair.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory every plugin class
- Verify public packages
- Preserve mismatches
- Compare private artifacts
- Reinstall or rebuild and retest
Mistakes to avoid
- Changing production files, recipients, hooks, cache settings, or update policy before preserving the failing request and current configuration.
- Treating one warning, one successful test, or one dashboard status as a complete diagnosis without checking the next system in the path.
- Testing with a different account, order state, form embed, locale, plugin version, or cache state than the real failure.
- Publishing a new broad answer when an established owner already exists, which splits internal links and creates query overlap.
Questions teams ask during testing
Can I run this directly on production?
Read-only inspection is often appropriate on production when access is controlled and output is redacted. Make backups first, test state-changing steps on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact installed version, locale, request, order, form, role, cache state, and integration path. Repeat the same fixture after the fix and keep evidence from both runs.
What evidence should I keep?
Keep UTC time, site and plugin versions, request or record ID, command, expected result, actual result, relevant logs, configuration snapshot, change, rollback point, and final verification. Redact secrets and personal data.
When should a specialist take over?
Escalate when checkout, customer email, lead capture, security, payment state, production updates, or several plugins are affected, or when the safe next step is unclear. A short evidence packet saves time and limits guesswork.
What to tell the client or owner
Give the site owner a concise evidence packet containing the affected workflow, exact versions, UTC test time, fixture or record ID, expected and actual result, logs, change made, rollback point, final verification, owner, and next review date. Remove passwords, tokens, payment details, and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, ask HandL WP to audit plugin integrity and hidden persistence.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references