Build a revocation path before you open a plugin system: a signed blocklist the CLI fetches and checks, the ability to disable a plugin on the next run, a message telling the user why, and a record of which versions were installed. Deleting a plugin from your registry alone does not remove it from machines.
Why removal from the registry is not enough
When a plugin turns out to be malicious, taking it off the listing stops new installs. People who already have it keep running it. Many plugin systems also cache plugins locally, so a copy survives. If your CLI never checks the registry again, the plugin keeps working until the user happens to update.
Assume you will need this at some point, and build it while nothing is on fire.
The four parts of a revocation system
- A blocklist your client fetches. A small file listing plugin identifiers and affected versions, with a reason code. The CLI checks it at start and on a schedule.
- Signature on the list. An attacker who can edit the list can disable good plugins or hide bad ones. Sign it with a key used only for this purpose, and give it an expiry so a stale copy is noticed. The idea of signed metadata with an expiry is described in the TUF overview.
- Client behaviour. On a hit, the CLI refuses to load the plugin, prints which plugin and why, and tells the user what to do. Do not delete files silently, since users may need to inspect them.
- Records. Keep a log of which plugin versions were published and when, so you can tell who might be affected.
Decisions to make in advance
| Question | Option | Trade-off |
|---|---|---|
| What if the CLI is offline? | Use the last signed list until it expires | Offline users stay protected briefly |
| What if the list cannot be fetched? | Fail open or fail closed | Open keeps tools working, closed is safer for high-risk setups |
| Who can add to the list? | Two named people | Speed against mistakes |
| How are plugin authors told? | Email and a public notice | Fairness and transparency |
For enterprise users, let administrators add their own entries to a local blocklist.
Steps to run an incident
- Confirm the finding and note the exact versions.
- Add an entry to the signed list and publish it.
- Remove the plugin from the registry.
- Post a notice that says what the plugin did, which versions, and what users should rotate or check.
- If the plugin could read credentials, tell users which ones to rotate.
- After the fact, add a test to your review process that would have caught it.
Do not forget the author side
Compromised maintainer accounts are a common route. Offer two-factor sign in for plugin authors and let them revoke their own releases quickly. For deeper design questions see five questions to threat model a plugin system before launch.
Quick check
Is deleting the plugin from the registry enough?
No. Existing installs keep running it. You need a client-side check against a signed list.
Should the client delete a revoked plugin?
Disable it and explain why. Keep files so users can investigate, and let them remove it on purpose.
Safeguard's free scan at gold.safeguard.sh/scan can help inventory which packages a project pulls in.
Sources
Last reviewed: 19 October 2026.
