WordPress Multisite Hacked: Cleaning a Compromised Network
By Glenn Lyvers · Updated · 5 min read
If you're running WordPress Multisite — one install powering several sites under different subdomains or domains — a hack on any one of them is rarely just that site's problem. Multisite shares its filesystem, its core codebase, and its highest-privilege account across every subsite on the network, which is exactly what makes a network-wide cleanup a different job from a single-site one. Here's how to do it without leaving a door open on the subsite nobody was watching.
Why one hack becomes a network problem
A standalone WordPress site has one wp-content folder, one set of plugins, one admin layer. A multisite network has one wp-content folder and one set of plugin/theme files serving every subsite, plus a super admin role that sits above all of them. That shared foundation is the whole point of multisite — install a plugin once, use it everywhere — but it means an attacker doesn't need to compromise every subsite individually. A single vulnerable plugin, reachable through any one subsite's uploads folder or an editable theme file, gives them a foothold that every other subsite on the network shares by definition.
Finding patient zero
Start by identifying which subsite was actually compromised first, rather than treating the whole network as an undifferentiated mess. Check each subsite's content, users, and file-modification timestamps for the earliest sign of tampering — the subsite with the oldest evidence is usually the entry point, and understanding how it happened there (a vulnerable plugin only activated on that one subsite, weak credentials on a local admin) tells you what to check for network-wide. The detection approach is the same as any single-site case; my how sites get hacked guide covers the usual entry points in detail.
Cleaning every subsite without missing one
This is where multisite cleanups go wrong: someone cleans the subsite they noticed the problem on, confirms it looks fine, and stops — leaving the low-traffic subsite nobody checks as a live backdoor. Every subsite has its own database tables (WordPress prefixes them by site ID — wp_2_options, wp_3_posts, and so on) and its own local users, and each of those needs the same scrutiny you'd give a standalone hacked site: unfamiliar admin or editor accounts, unexpected posts or pages, altered theme files if that subsite runs its own child theme, and options-table tampering — my database malware guide covers what that looks like. Go through the network admin's Sites list and check every single one, including sites marked archived or inactive; a dormant subsite is still a live PHP install an attacker can reach.
The super admin account: your first and last check
Network admin → Users → All Users, filtered to super admins, is the single most important screen on a compromised multisite network. A regular subsite admin can damage one site; a super admin can install network-activated plugins, create users anywhere, and reach every subsite's database — it's the multisite equivalent of the WordPress root account, and it's exactly what the pattern in my hidden admin users guide describes, just with higher stakes. If the super admin list has an account you don't recognize, or the registered super admin email has been changed, treat the entire network as breached until you've confirmed otherwise — don't scope the incident down to "just that one subsite" based on where you happened to notice it.
Network-activated plugins and themes: infect once, run everywhere
A plugin or theme activated network-wide runs its code on every subsite from a single copy of the files. That cuts both ways during cleanup: it means you only need to update or replace an infected plugin once rather than per-subsite, but it also means a single compromised or nulled network-activated plugin (see my nulled themes guide) was never contained to one site in the first place. Audit the network's active plugin and theme list the same way you'd audit a single site's, and remove anything you can't account for.
Hardening a multisite network after cleanup
Once it's clean: rotate the super admin password and any other super admin credentials, review who actually needs super admin rather than leaving it as a default for every site owner, restrict who can register new subsites if that's open, and put the network under the same file-change monitoring you'd want on any single site — with the added value that one monitoring setup covers every subsite at once. If you'd rather have someone who's done this before handle the sweep across every subsite and the super admin layer in one pass, that's exactly the kind of job my malware removal service takes on.
Common questions
Can one hacked subsite infect the others on the same network?
Yes, in the ways that matter most: they all share the same wp-content/plugins and wp-content/themes folders on disk, so a backdoor or infected file dropped through one subsite's uploads or an editable theme file is reachable by every subsite on the install. They also share one WordPress core codebase and one super admin layer, so a compromised super admin account compromises the entire network at once, not just one site.
Do I need to clean each subsite separately, or can I do it once for the whole network?
Both. Network-activated plugins, themes, and WordPress core only need cleaning once, because there's only one copy on disk. But each subsite has its own database tables (wp_2_posts, wp_2_options, and so on for site ID 2, etc.) and its own set of local admin and editor accounts, so each subsite's content, users, and options have to be checked individually. Skipping a low-traffic subsite because 'nobody visits it' is exactly how reinfection happens.
What's the single most important account to check first?
The network super admin account, always. A regular admin on a subsite can only affect that one site; a super admin can install plugins, add users, and reach the database prefix for every site on the network. If the super admin account or its email has been touched, treat that as a network-wide breach, not a single-site incident, no matter which subsite you originally noticed the problem on.
Is multisite inherently less secure than single-site WordPress?
Not inherently, but it does raise the stakes of any single vulnerability, because a hole in one subsite's plugin gives an attacker filesystem access shared by every subsite. The security fundamentals are identical to single-site WordPress; multisite just makes 'one weak link' a network-wide problem instead of a one-site problem, so those fundamentals matter more, not less.
Should I split a hacked multisite network into separate installs?
Usually not purely for security reasons — a properly cleaned and hardened multisite network is no more vulnerable going forward than separate installs would be, and splitting is a significant migration project of its own. It's worth considering only if the subsites have genuinely different risk profiles or owners who shouldn't share infrastructure, which is a business decision separate from the cleanup itself.