A missing WordPress plugin update is not proof that a security scanner blocked it. Start with the release status and the committer notification, then distinguish a distribution delay from an actual code finding.
Establish which problem you have
WordPress.org now reviews plugin releases during its cooldown. High-risk findings can stop distribution, and committers receive a notification. The Plugins Team announcement says a risk score does not establish malicious intent. Do not describe a vendor as compromised solely because a release is delayed.
Build a private release record with the plugin slug, intended version, commit revision, previous distributed version, notification timestamp and the affected file. Keep credentials and exploit details out of public support tickets. Ask another authorized committer to confirm the notification if your mailbox is unreliable.
If there is no block notification, check the expected release version, package metadata and ordinary update channel first. Our update cooldown guide covers the site-owner side. Repeatedly forcing update checks cannot correct a code finding.
Turn the finding into a small test
- Reproduce the reported behavior on an isolated copy of the released package, not only your development branch.
- Identify the input, the permission boundary and the operation it reaches. For example, an editor who can open a settings screen should not automatically be able to change an administrator-only option.
- Add a negative test using the insufficiently privileged role. Record the expected refusal without exposing a real customer account.
- Correct the boundary and repeat the legitimate administrator workflow. Blocking everyone is not a complete fix.
- Check the built distribution again. Excluding a corrected file from the package can leave the shipped release vulnerable while source tests pass.
Package: Test the distributed build. Role: Include an unauthorized case. Review: Record actual release status. Site: Recheck the real workflow. Explanatory checklist, not a customer test result.
Keep review, release and recovery separate
| Evidence |
What it establishes |
What it does not establish |
| Local security test passes |
The fixture behaves as expected |
WordPress.org has accepted the release |
| New version distributed |
The update channel offers it |
Every customer has installed it |
| Installed version matches |
That site has the package |
The affected workflow still works |
For a finding you believe is incorrect, give the Plugins Team a minimal reproduction, exact code path and explanation of the relevant authorization checks. Do not flood the review with a full customer database or a general claim that the scanner is wrong. An appeal and a corrected release are different actions; track which one you actually submitted.
Verify the repair on one representative site
Use a staging site with the affected feature enabled. Confirm the installed version, run the valid workflow, then repeat the negative permission case. Preserve an appropriate rollback package, but do not automatically reinstall a version with a known security flaw.
Tell customers precisely what is known: offered version, installed version and tested behavior. Avoid saying every installation is safe because one test passed. If an update has already broken a live installation, HandL WP can investigate the release conflict using the redacted error and version record.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.