A plugin kill switch is a way for the host or marketplace to disable or remove a plugin on every installation after the fact. It works through a block list the product checks, so a plugin that turns out to be malicious or vulnerable can be stopped without waiting for each user to act.
Two layers, two speeds
Removing a listing and disabling installed copies are different jobs. Doing only the first leaves existing users exposed.
The Visual Studio Marketplace documentation describes both. If a malicious extension is reported and verified, or a vulnerability is found in an extension dependency, the extension is removed from the Marketplace and added to a block list. If it is already installed, VS Code automatically uninstalls it.
Chrome Web Store enforcement is slower by design for some cases. After a takedown, the item no longer appears in the store, but end users are not notified immediately. If the violation stays unresolved for several weeks, Chrome automatically disables the extension and tells the user it violates policy. Users may choose to re-enable it. For malware and extreme violations, the review documentation says the team has special procedures, which is the path for urgent cases.
WordPress.org takes another approach for its directory: a plugin found to have security issues is closed until the issue is resolved, and in extreme cases the WordPress Security team may update the plugin and propagate the fix.
What a kill switch needs
| Need | Why |
|---|---|
| A block list the client checks regularly | Disables installed copies, not only new installs |
| Block by plugin and by version | Lets you stop one bad release and keep earlier ones |
| Block by publisher | Handles a compromised account |
| User notice with a reason | Reduces confusion and support load |
| An override path with a warning | Some admins need time, but it must be a conscious choice |
| An audit record | Shows who pulled the switch and why |
Steps to build one
- Decide who can trigger a block and how a second person confirms it.
- Ship a signed block list that clients fetch on a schedule and on start. Sign it so an attacker cannot disable good plugins.
- Define behavior when the client is offline. Fail safe for high-risk plugins, fail open for low-risk ones, and write that down.
- Support version level blocks so rollback is possible.
- Notify the developer and the users through separate channels.
- Drill it. A kill switch that has never been used on a test plugin may not work during an incident.
Where kill switches fail
The most common failure is delay. If clients only check the list once a day, you have a day of exposure. Another is scope: blocking a plugin ID does nothing if the attacker republished under a new name, which is why name and publisher checks sit alongside the block list.
Also decide what happens to the data a blocked plugin already holds. Disabling stops new actions but does not undo past ones, so pair the switch with an investigation checklist.
Quick check
Is removing a plugin from the store the same as a kill switch?
No. Removal stops new installs. A kill switch also disables copies that are already installed.
Should the block list be signed?
Yes. An unsigned list can itself become an attack, because someone who can alter it can disable legitimate plugins or avoid blocking bad ones.
Safeguard supports this with continuous monitoring of dependencies and SBOM data, so you can find which plugins bundle a newly flagged library. Policies and gates then stop new releases that carry it. Try the free scan.
Sources
- Extension runtime security, Visual Studio Code
- Chrome Web Store review process
- Detailed Plugin Guidelines, WordPress Plugin Handbook
Last reviewed: 19 October 2026.
