Practical security advice for website owners
WordPress Multisite Malware Recovery: Scope the Whole Network
Security guidance · References checked 2 November 2026
In this guide
A WordPress Multisite network is not simply a folder of unrelated websites. Shared code, network administration and site-specific data create dependencies that change incident scoping. Cleaning the one site where a warning appeared may leave the rest of the network unexamined.
Start by defining the network, affected symptoms and administrative boundaries. The goal is a recovery plan that accounts for shared components while preserving the legitimate content and operations of individual sites.
Confirm that the installation is Multisite
Ask the authorised maintainer to confirm the architecture, network domains, mapped domains and relevant hosting accounts. Several standalone WordPress installations on one hosting plan are not the same architecture as one Multisite network, even though both may require broader incident scoping.
The WordPress Multisite administration handbook explains network administration, plugins, themes and other structural differences. Use it to frame questions for the maintainer rather than assuming ordinary single-site instructions apply unchanged.
Create a private inventory of sites, responsible business owners and critical functions. Include inactive or archived sites where they remain part of the installation. Do not publish internal network paths or private site data as part of a marketing case study.
Separate shared and site-specific findings
Record which observations affect shared code or configuration and which appear limited to a particular site’s content or settings. A file-level change in a shared component may have broader implications than one altered post, but the actual effect still needs verification.
Review network-level privileges separately from individual site roles. A person administering one site may not have authority to approve changes for every business in the network. Confirm who can authorise containment, credential changes and downtime.
Do not infer that every site is infected because one is affected, and do not infer that the rest are clean because their homepages look normal. Define a representative investigation and expand it where evidence warrants. Report what was checked and what remains outside the coverage.
Protect network data before changes
Plan appropriate backups of shared files and the relevant database structures. Confirm how the backup product handles the network and whether recovery of an individual site is supported. An export of public posts is not equivalent to a complete operational recovery point.
Preserve legitimate changes made during the incident, including orders, registrations and enquiries. A whole-network rollback may replace data for sites that were not visibly affected. Agree how those records will be reconciled before choosing a restore.
Store incident copies privately and limit access according to the information they contain. A network database can include data from several businesses or departments. Recovery access should be authorised for that scope, not inherited casually from a single-site support request.
Contain with dependencies in mind
A network-wide plugin change can affect every site using it. Disabling it may be justified, but assess which workflows depend on it and communicate the temporary impact. Where immediate harm requires urgent action, record the reason and follow with controlled verification.
Coordinate hosting, deployment and network administrator access. Removing an unwanted site-level account may not address network-level or server access. Likewise, changing a shared credential can interrupt multiple integrations if those dependencies were not inventoried.
Avoid bulk cleanup scripts that assume one table prefix or one site context. Have the developer verify the target scope for every command. A tool’s ability to operate across a network is not a reason to use its broadest option by default.
Review custom code and scheduled work
Inspect the relevant shared plugins, MU-plugins, themes and custom integrations according to the evidence. WordPress’s MU-plugin documentation describes automatically loaded components that may not appear in the ordinary active-plugin list.
MU-plugins are not inherently malicious; hosts and developers use them legitimately. Record their source and purpose. Removing an entire directory without understanding its contents can disable hosting or application functions while leaving other incident paths unchanged.
Include site-specific scheduled tasks and integrations in the scope where relevant. A recovered shared codebase does not establish that every site’s settings or external destinations are correct. Check the behaviours the business actually uses.
Verify more than the network homepage
Build a test matrix of representative sites and important functions. Include different themes, mapped domains, forms, media delivery, logins and store functions where present. Use harmless data and supported payment test modes.
Verify the administrative experience at both site and network level. Confirm that legitimate owners retain the intended access and that restricted roles cannot perform the actions reserved for network administrators. Do not use real customer accounts as test identities.
Record which sites and functions were tested individually and which shared checks apply across the installation. A transparent coverage statement is more useful than a broad “all sites checked” claim without evidence.
Agree the handover and follow-up scope
The recovery report should distinguish shared changes, site-specific repairs, unresolved issues and ongoing maintenance responsibilities. Each affected owner should understand the impact on their site without receiving another site’s private information.
For a quote, provide the public network domains, approximate number of sites, symptoms and major business functions. Do not send the complete database or all credentials in an initial enquiry. Multisite recovery often requires a tailored assessment because the shared architecture and permissions affect both the work and the precautions.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.