Malware Removal Checklist for WordPress Multisite Networks (2026)

A single infected plugin file on a WordPress Multisite network doesn't just take down one storefront or blog — it can quietly infect every subsite sharing that install. If you're running a malware removal checklist for WordPress multisite networks, the rules are different from a standard single-site cleanup: one shared wp-config.php, one shared plugins directory, and one Network Admin panel mean a single compromised credential can escalate into a network-wide incident in minutes. This guide walks through exactly what to check, in what order, and why multisite infections behave differently than anything you've dealt with on a standalone WordPress install.

Why WordPress Multisite Malware Is Different

On a normal WordPress site, malware is usually contained to that one install. On a multisite network, everything that matters — core files, the database, plugins, themes, and secret keys — is shared across every subsite in the network. That shared architecture is efficient to manage, but it also means one weak point compromises the whole network.

• Shared wp-config.php and database — a leaked database credential or exposed secret key exposes every subsite, not just one.
• Network-activated plugins and themes — a single injected or nulled plugin file in the shared /wp-content/plugins directory infects every subsite simultaneously.
• Super Admin accounts — compromising one Super Admin login hands an attacker control of the entire network, every theme, plugin, and setting.
• mu-plugins backdoors — files placed in wp-content/mu-plugins/ auto-load on every subsite, don't appear in the standard Plugins list, and can't be deactivated from wp-admin — they can only be removed by deleting the file directly from the server.

The 2026 Malware Removal Checklist for Multisite Networks

Use this checklist before, during, and after any cleanup engagement on a WordPress Multisite network. It's written to be actionable — work through it in order rather than jumping straight to a plugin scan.

• Isolate, don't shut down. Take the specific infected subsite offline or restrict public access rather than pulling the entire network — unless core files themselves are compromised.
• Audit every Super Admin account. Check wp_users and network user meta for accounts granted Super Admin status that shouldn't have it.
• Scan the shared plugin and theme directories once — not per-subsite. Since they're shared, one pass covers the whole network, but it must be thorough.
• Manually inspect wp-content/mu-plugins/ for unfamiliar PHP files — this folder is invisible in the dashboard and is a favored backdoor location.
• Check every subsite's upload directory individually — /uploads/sites/{id}/ for each subsite ID — for PHP shells disguised as images or cache files.
• Diff .htaccess / nginx rewrite rules against a clean multisite template. Attackers hide malicious redirects inside the "required" multisite rewrite block because admins rarely touch it.
• Replace WordPress core files network-wide from a trusted source rather than patching individual files.
• Rotate all secret keys and salts in wp-config.php — this invalidates every session across every subsite at once, logging out any attacker session immediately.
• Force password resets for all Super Admins and individual site admins, and enable MFA for every Super Admin account.
• Check each mapped domain separately against Google Safe Browsing, McAfee SiteAdvisor, and Norton Safe Web — a multisite network with ten mapped domains can generate ten separate blacklist entries from a single infection.
• Disable open subsite self-registration and restrict plugin/theme installation rights to Super Admins only going forward.
• Deploy file integrity monitoring across the shared core, plugin, and theme directories plus every subsite's uploads folder, so the next unauthorized file change is caught in hours, not months.

Cleanup: What Actually Happens During Remediation

Triage and Isolation

The first job is figuring out whether you're dealing with a single compromised subsite or a network-wide infection. A subsite-specific vulnerable plugin or a weak subsite admin password usually stays contained — until it's used as a pivot to reach the shared filesystem or database, at which point it becomes a network problem. That triage decision shapes everything that follows.

Removing Backdoors

Because plugins and themes are shared, a single infected file can re-infect a "cleaned" subsite within hours if the source isn't found and removed everywhere at once. This is why manual file review of mu-plugins and a full diff of core files against a known-clean WordPress release matters more on multisite than on a single install — automated scanners frequently miss backdoors planted outside the standard plugin structure.

Blacklist and Reputation Cleanup

Domain mapping means a multisite network rarely gets away with a single blacklist entry. Each mapped domain or subdomain is indexed and flagged independently by search engines and antivirus vendors, so recovery involves filing individual delisting requests for every affected domain — not one blanket request for the network.

Hardening After Cleanup

Removing the malware is only half the job. Without hardening, reinfection through the same shared attack surface is common within weeks. At minimum:

• Set DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT in wp-config.php to block in-dashboard file editing.
• Enforce FORCE_SSL_ADMIN across the network.
• Limit the number of Super Admin accounts to the minimum required — every additional Super Admin is another attack surface for the entire network.
• Review network settings for WPMU_REGISTER_SITE and disable open registration unless it's explicitly required.
• Keep network-activated plugins and themes updated on a fixed schedule rather than ad hoc.

For businesses without the internal resources to maintain this on an ongoing basis, CloudHouse's malware removal service includes post-cleanup hardening and monitoring specifically scoped for multisite and network-managed WordPress environments.

Ongoing Monitoring for Multisite Networks

A clean scan today doesn't guarantee a clean network next month. Ongoing monitoring for multisite should include periodic re-checks of the mu-plugins folder (since it stays invisible in the dashboard), logging of all Super Admin actions, individual blacklist status checks per mapped domain, and file integrity alerts the moment a shared plugin or theme file changes outside a scheduled update. Networks running a dozen or more subsites benefit the most from automated monitoring, simply because manual review of that many mapped domains and subsites isn't sustainable long-term.

It's also worth tracking uptime and response codes per mapped domain separately after a cleanup. A subsite that briefly returns 500 errors or unexpected redirects immediately after remediation is often a sign that a cleanup step was incomplete on that specific domain, even if the network as a whole looks healthy.

Backups and Recovery Planning for Multisite

Because a multisite network shares one database across every subsite, backup strategy needs more thought than a simple full-site snapshot. A single database backup captures every subsite's content at once, but restoring it wholesale to fix one compromised subsite will also roll back every other subsite on the network — often an unacceptable trade-off for an active e-commerce or membership network with dozens of active subsites.

Before any cleanup begins, take a full backup of the current (infected) state so nothing is lost if a mistake happens mid-remediation, then take a second backup immediately after cleanup and hardening are verified clean. Store both off-server, and confirm the backup schedule going forward captures the shared database on a frequency that matches how often content changes across the network — daily is standard for active multisite networks, weekly is rarely enough.

Why Businesses Choose CloudHouse for Malware Removal

Multisite cleanups require someone who understands the shared architecture — treating each subsite as an isolated case misses backdoors hiding in shared plugin directories or mu-plugins. CloudHouse's team specifically triages subsite-level versus network-wide compromise before touching a single file, which avoids the common mistake of "cleaning" one subsite while the actual backdoor sits untouched in a shared folder. We also handle the tedious part most agencies skip: filing individual blacklist removal requests for every mapped domain affected, not just the primary network URL.

Common Mistakes That Cause Reinfection on Multisite Networks

Most repeat infections on multisite networks trace back to a handful of avoidable mistakes made during the first cleanup attempt. Recognizing these before you start saves both time and a second incident a few weeks later.

• Cleaning only the visibly infected subsite. If the actual malicious file lives in a shared plugin, theme, or mu-plugins folder, every other subsite on the network is still carrying the same backdoor even after the "obvious" subsite looks clean.
• Skipping the mu-plugins folder entirely. Because it doesn't show up in the standard Plugins screen, many DIY cleanups and even some automated scanners never look there — and it's exactly where persistent backdoors are placed for that reason.
• Not rotating secret keys and salts. If an attacker captured session cookies or authentication tokens before the cleanup, failing to rotate wp-config.php keys leaves those sessions valid even after passwords are changed.
• Treating blacklist removal as automatic. Search engines and antivirus vendors don't automatically re-scan and delist a domain once malware is removed — each mapped domain usually requires an explicit resubmission request, and skipping this step leaves the site flagged as dangerous to visitors long after it's actually clean.
• Leaving subsite self-registration open. An open registration setting is frequently how the initial compromise happened in the first place, and it's commonly left unchanged after cleanup simply because it wasn't part of the original infection vector being investigated.

How Long Multisite Cleanup Typically Takes

A single-subsite, contained infection with no core file tampering can often be resolved within a business day once access and backups are confirmed. A network-wide compromise — shared plugin infection, mu-plugins backdoor, and multiple blacklisted mapped domains — realistically takes two to five business days when you include individual blacklist resubmission requests, since several of those reviews are handled by third-party vendors on their own timeline rather than something a removal service can accelerate. Networks with dozens of mapped domains should expect the blacklist cleanup phase specifically to run longer than the technical remediation itself.

What to Ask Before Hiring a Multisite Malware Removal Service

Not every malware removal provider has actually worked on a multisite network before — many are set up for single-site cleanups and treat a network the same way, which misses the shared-infrastructure risks covered above. Before hiring anyone, confirm they will:

• Audit the shared wp-content/mu-plugins, /plugins, and /themes directories as a single pass, not per-subsite.
• Check and request delisting for every mapped domain individually, not just the primary network domain.
• Rotate network-wide secret keys and salts as a standard part of remediation, not an optional add-on.
• Provide a written hardening summary after cleanup — including Super Admin account review and self-registration settings.
• Offer some form of reinfection guarantee or follow-up monitoring window, given how common short-term reinfection is on shared-architecture networks.

Conclusion

WordPress Multisite malware removal isn't a bigger version of single-site cleanup — it's a different problem because of the shared core, shared plugins, and shared Super Admin layer. Working through a structured checklist, rather than relying on a single automated scan, is what actually prevents reinfection across every subsite in the network. If your network has already been compromised or you want a hardening review before it happens, CloudHouse's malware removal team can assess the full network, not just the symptomatic subsite.