How to secure WordPress Multisite networks?

To secure a WordPress Multisite network, keep the number of Super Admins to a minimum and protect them with two-factor authentication, control which plugins and themes are installed and activated network-wide, lock down user and site registration, restrict upload file types and sizes, keep everything updated from the Network Admin, and harden the shared server configuration. Because every site in a network shares the same codebase and database, one weak spot can affect every site, so network-level controls matter more than anything you do on an individual site.

Multisite is great for agencies, universities, franchises, and publishers who manage many related sites from one installation. That shared foundation is also the main security challenge. This guide explains how Multisite changes the security picture and walks through the settings, roles, and server tweaks that keep a network safe.

How Multisite Changes WordPress Security

In a standard installation, a problem usually affects one site. In Multisite, several things are shared across the whole network:

• One codebase: All sites use the same WordPress core, plugins, and themes. A vulnerable plugin installed once is present for every site.
• One database: Each site gets its own set of tables (like wp_2_posts), but they all live in the same database with the same credentials.
• Shared users table: Users exist network-wide in wp_users and are then added to individual sites.
• One wp-config.php: Security constants apply to every site.
• The Super Admin role: A Super Admin controls everything, across every site.

This means your security strategy has to start at the network level and then work down to individual sites.

Understand the Multisite Roles

Multisite adds one role and changes another.

1. Super Admin: Can manage the network, install and delete plugins and themes, create and delete sites, manage all users, and edit network settings. This is the most powerful account in WordPress.
2. Administrator: In Multisite, a site Administrator can manage their own site but, by default, cannot install plugins or themes, and cannot use unfiltered HTML. This is a deliberate safety limit.
3. Editor, Author, Contributor, Subscriber: Work the same as on a single site, but only within the site they have been added to.

The fact that site Administrators can't post unfiltered HTML (such as arbitrary <script> tags) is an important protection. It stops one site owner from injecting JavaScript that could steal a Super Admin's session when they visit that site. Avoid granting the unfiltered_html capability to non-Super Admins unless you fully trust them.

Limit and Protect Super Admins

Treat Super Admin accounts like root access to your server.

1. Keep the list short: Go to Network Admin > Users and filter by Super Admin. Only people who truly need network-level control should have it.
2. Use separate accounts: Super Admins should use a regular account for everyday content work and only use the Super Admin account for network management.
3. Require two-factor authentication: Plugins like Two Factor and Wordfence Login Security support Multisite. Enforce 2FA for all Super Admins at minimum.
4. Use unique, long passwords stored in a password manager.

You can list and manage Super Admins with WP-CLI:

wp super-admin list
wp super-admin remove olduser

Control Plugins Across the Network

Plugins are the most common source of vulnerabilities, and in Multisite, every installed plugin is available to every site's code.

Only Super Admins Install Plugins

By default, only Super Admins can install plugins. Keep it that way. Under Network Admin > Settings, the Enable administration menus option controls whether site Administrators can see the Plugins menu. If you enable it, they can activate or deactivate plugins that are already installed, but still cannot install new ones.

Network Activate Security-Critical Plugins

Security and essential functionality plugins should be Network Activated from Network Admin > Plugins, so no site owner can deactivate them. This is especially important for your security plugin, 2FA plugin, and any spam protection.

Use Must-Use Plugins for Critical Code

For custom security code you never want disabled, use a must-use plugin. Files in wp-content/mu-plugins/ load automatically on every site and can't be deactivated from the dashboard.

Audit Installed Plugins Regularly

Delete plugins no site uses. WP-CLI can help you find which plugins are active where:

wp site list --field=url | while read -r url; do
  echo "== $url"
  wp plugin list --status=active --field=name --url="$url"
done

Control Themes Across the Network

Themes also run PHP, so treat them with the same care.

• Install themes only from trusted sources.
• Enable themes for the network or per site from Network Admin > Themes or Network Admin > Sites > Edit > Themes, so site owners can only pick from an approved list.
• Delete unused themes, but keep one default theme installed as a fallback.

Lock Down Registration

Multisite can let people register user accounts, create their own sites, or both. Open registration is a common source of spam and abuse.

Go to Network Admin > Settings and review Allow new registrations:

• Registration is disabled: The safest option for private networks like agency or company sites.
• User accounts may be registered: Visitors can sign up as users only.
• Logged in users may register new sites: Existing users can create sites.
• Both sites and user accounts can be registered: The most open option, suitable only for public networks with strong moderation.

If you do allow registration:

1. Use Limited Email Registrations: Restrict sign-ups to specific email domains, such as your organization's domain.
2. Use Banned Email Domains: Block known disposable email providers.
3. Add a bot challenge: Protect the wp-signup.php form with a CAPTCHA plugin that supports Multisite.
4. Review Banned Names: Prevent people from registering site names like admin, login, www, or your brand name.
5. Moderate new sites: Check new sites regularly for spam or phishing content.

Restrict Uploads

Every site in the network uploads files to the same server, so upload settings matter.

In Network Admin > Settings, under Upload Settings:

• Site upload space: Set a storage quota per site to prevent abuse.
• Upload file types: This is a space-separated whitelist of allowed extensions. Keep it limited to what your sites actually need, for example jpg jpeg png gif webp pdf mp4. Never add php, phtml, js, html, svg, or exe.
• Max upload file size: Set a sensible limit.

SVG files deserve special mention. They can contain embedded scripts, so if you need SVG support, use a plugin that sanitizes them on upload, such as Safe SVG.

Block PHP Execution in Uploads

Multisite stores uploads in wp-content/uploads/sites/<site-id>/. Block PHP from running anywhere under uploads. On Apache, create wp-content/uploads/.htaccess:

<FilesMatch "\.(php|phtml|php[0-9]|phar)$">
    Require all denied
</FilesMatch>

On Nginx, add this to the server block:

location ~* ^/wp-content/uploads/.*\.(php|phtml|php[0-9]|phar)$ {
    deny all;
}

Harden wp-config.php for the Network

Because one wp-config.php controls every site, a few constants give you network-wide protection. Add them above the "That's all, stop editing!" line, and back up the file first:

// Prevent editing theme and plugin files from the dashboard.
define( 'DISALLOW_FILE_EDIT', true );

// Force HTTPS for admin and login screens.
define( 'FORCE_SSL_ADMIN', true );

// Keep debug output off in production.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

If you want to stop all plugin and theme installs and updates through the dashboard (for example, because you deploy code with Git), you can also add:

define( 'DISALLOW_FILE_MODS', true );

Only use DISALLOW_FILE_MODS if you have another way to apply updates, such as WP-CLI or a deployment pipeline, or your network will fall behind on security patches.

Also make sure your multisite constants such as COOKIE_DOMAIN are set correctly if you use domain mapping. An incorrect cookie domain can cause login problems, and a too-broad one can share cookies across domains unnecessarily.

Keep the Network Updated

Updates in Multisite are managed from Network Admin > Updates. After a core update, WordPress may ask you to run Network Admin > Upgrade Network so each site's database tables are upgraded too.

With WP-CLI, updating looks like this:

wp core update
wp core update-db --network
wp plugin update --all
wp theme update --all

Test updates on a staging copy of the network first, especially for large networks where a broken plugin affects many sites at once.

Secure Domain Mapping and SSL

Modern Multisite supports mapping custom domains to individual sites natively. Go to Network Admin > Sites > Edit and change the Site Address (URL).

Security points to keep in mind:

• Every mapped domain needs a valid SSL certificate. Use a host or certificate setup that covers all mapped domains, such as automatic Let's Encrypt certificates.
• Subdomain networks need a wildcard certificate covering *.example.com.
• Remove old mappings: If a client leaves and their domain no longer points to your server, update the site URL. Dangling DNS records pointing to a network can be misused.

Protect Against Cross-Site Risks

Because sites share a database and users, a compromise on one site can spread. Reduce that risk by:

1. Keeping untrusted users away from privileged roles: Don't give site Administrator to people you don't trust on a network that also hosts important sites.
2. Not granting unfiltered_html: Keep it limited to Super Admins.
3. Separating very different trust levels: If you host sites for unrelated clients with very different risk profiles, consider separate installations instead of one network.
4. Being careful with network-wide shortcodes and blocks: Custom code that outputs user-supplied data must be escaped properly, because one site's input might be displayed on another.

Example: A Network-Wide Security Check in an MU-Plugin

Here's a small must-use plugin that removes the unfiltered_html capability from everyone except Super Admins, even if a plugin tries to grant it. Save it as wp-content/mu-plugins/sajjad-network-security.php:

<?php
/**
 * Plugin Name: Sajjad Network Security
 * Description: Network-wide security rules for Multisite.
 */

add_filter( 'map_meta_cap', 'sajjad_restrict_unfiltered_html', 10, 4 );

function sajjad_restrict_unfiltered_html( $caps, $cap, $user_id, $args ) {
    if ( 'unfiltered_html' === $cap && is_multisite() && ! is_super_admin( $user_id ) ) {
        $caps = array( 'do_not_allow' );
    }
    return $caps;
}

WordPress already behaves this way by default in Multisite, but this acts as a safeguard against plugins that change capabilities.

Monitor the Whole Network

• Activity logs: Use a logging plugin that supports Multisite, such as WP Activity Log, to track logins, plugin changes, and user role changes across all sites.
• Security scanning: Wordfence and Sucuri both support Multisite and scan the shared codebase.
• New site alerts: If registration is open, get notified whenever a new site is created.
• Backups: Use a backup solution that supports Multisite and can restore both the entire network and, ideally, individual sites.

---

FAQ: WordPress Multisite Security

---

Conclusion

Securing a WordPress Multisite network comes down to recognizing that everything is shared. Keep Super Admins few and protected, control which plugins and themes are installed, lock down registration and uploads, and apply hardening through a single wp-config.php and must-use plugins so protections reach every site automatically.

Once the foundation is solid, keep the network updated from one place, monitor activity across all sites, and back up regularly. A well-managed network can be just as secure as a set of separate installations, while being far easier to maintain.