On WordPress Multisite, a network-activated plugin runs on every site in the network. One vulnerable or compromised plugin therefore affects all sites at once, which is a larger blast radius than a normal single-site activation. List network-active plugins separately and give each a named owner.
Definitions
WP-CLI's plugin list command reports a status for each plugin. The options include active, active-network, inactive and must-use. Active-network means the plugin is activated for the whole network. The plugin header documentation also lists a Network field, which marks whether a plugin can only be activated network-wide.
Must-use plugins also load across all sites in the installation, and the handbook notes they are useful for network-wide functionality on Multisite.
Why the blast radius matters
| Setup | A vulnerable plugin affects |
|---|---|
| Single site, plugin active | That site |
| Multisite, activated on one subsite | That subsite, though files are shared by the network |
| Multisite, network-activated | Every subsite |
| Must-use on a network | Every subsite, with no switch in the admin to turn it off |
The plugin files live once for the network, so an update changes all subsites together. That is efficient, and it also means a bad release lands everywhere at the same moment.
Steps to review a network
- Run the list command with the status filter set to active-network and keep the output.
- For each plugin, write down what it does and who owns it.
- Ask whether it truly needs to be network-wide. If only two subsites use it, activate it on those two instead.
- Check each for pending updates and for status on WordPress.org.
- Repeat for must-use plugins.
- For per-site activations, the handbook shows looping over every site URL so each subsite is listed.
wp plugin list --status=active-network --format=json
wp site list --field=url | xargs -I % wp plugin list --url=%
Update strategy
Because every subsite changes together, update on a staging network first. Choose a low-risk subsite as a canary where you can. Keep a rollback path and recent backups, and see what to back up on a client WordPress site.
Access also scales
A super administrator can install plugins for the whole network. Limit who has that role and require MFA, as in our post on MFA for agency staff.
A practical test
For each network-active plugin, ask whether you would be comfortable if it broke every subsite at once. If the answer is no, it needs staged updates, a named owner and a tested rollback. If only a few subsites use it, move it to per-site activation and reduce the exposure. Record the decision in the inventory so the next person sees why it is set that way.
Documenting the network
Keep one page per network that lists the network-active plugins, the must-use plugins, who owns each, the super administrators, and the date of the last review. When a client asks how many sites a plugin issue touches, you can answer from that page. It also helps a new team member understand the shape of the network on their first day, instead of learning it during an incident.
Quick check
Can I activate a plugin on only some subsites?
Yes, unless its header limits it to network-wide activation.
Does a network update all subsites at once?
The plugin files are shared, so an update applies to the whole network.
Sources
- wp plugin list, WP-CLI handbook
- Header Requirements, Plugin Handbook
- Must-Use Plugins, WordPress Advanced Administration Handbook
Last reviewed: 19 October 2026.
