Set a fix window in your partner rules, escalate in stages, warn administrators, and be ready to close or patch the plugin yourself if the author stays silent. Decide this path before an incident, because deciding during one is slow and contested.
What platforms already do
WordPress.org's plugin guidelines require developers to keep contact details up to date so they receive notices, and they forbid auto replies and support system routing for those emails because they have historically stopped humans from answering promptly. If a plugin is found to have security issues, it is closed until the situation is resolved, and in extreme cases the WordPress Security team may update the plugin and propagate that update for the safety of the general public.
Atlassian's marketplace rules require partners to name at least one security contact who can receive vulnerability tickets, to notify the platform of all security incidents and to fix vulnerabilities within stated timeframes.
Chrome Web Store handles unresolved violations with a warning period, then takedown, then an automatic disable for installed copies if the problem persists for several weeks.
An escalation ladder
| Stage | Trigger | Action |
|---|---|---|
| 1 | Report received | Notify the security contact, start the clock |
| 2 | No acknowledgment by the first deadline | Second channel: contact the account owner by another route |
| 3 | No fix by the severity deadline | Mark the plugin with a warning visible to administrators |
| 4 | Still no fix, exploit likely | Remove from the listing, block new installs |
| 5 | Active exploitation or high impact | Disable installed copies, or ship a platform patch where your rules allow it |
Prepare the contract and the tooling
- Require a monitored security contact at submission and verify it by sending a test message.
- Publish severity levels with fix windows, and state the consequences.
- Reserve the right in your terms to patch or disable plugins for the safety of users, as WordPress.org describes for extreme cases.
- Build a way to flag a plugin as unmaintained and show that to admins.
- Keep a list of customers using each plugin so you can tell them quickly.
- Offer alternatives. Suggest replacement plugins or an official first party feature where one exists.
What customers can do now
If you are a customer and not the platform, you still have options. Check whether the plugin's vulnerability is reachable in how you use it. Disable it if the feature is not essential. Restrict its permissions if your platform allows. Put it on a watch list and set a date to replace it. Waiting for an author who has gone quiet is a decision, so record that you made it.
Quick check
Can a platform patch a plugin without the author?
Some can. WordPress.org says its security team may update a plugin in extreme cases. If you want that ability, put it in your terms before you need it.
How long should a fix window be?
It depends on severity and your risk. Atlassian refers partners to a published bug fix policy with timeframes. Publish yours and keep it consistent.
Safeguard helps customers see which plugins and libraries they depend on through asset discovery and SBOM data, and continuous monitoring tracks new advisories. Try the free scan.
Sources
- Detailed Plugin Guidelines, WordPress Plugin Handbook
- Security requirements for cloud apps, Atlassian
- Chrome Web Store review process
Last reviewed: 19 October 2026.
