WordPress Multisite Hacked: How We Investigated and Recovered the Network

The client ran a WordPress Multisite network, with several business websites managed from a single WordPress installation. That setup keeps updates and management in one place, but it has a sharp edge: anything affecting the core installation can reach every site on the network at once. What came in as a routine report of broken pages and missing stylesheets turned, within hours, into a full security and infrastructure investigation.

The Setup

Because the sites all ran from one WordPress Multisite installation, they shared core files, plugins, themes, and user management, while keeping their own configurations and content. The client told us several sites were behaving unexpectedly. Some pages looked broken, stylesheets were missing, and overall performance and functionality had become unreliable. The shared architecture meant we could not look at any single site in isolation. We had to examine both the shared infrastructure and the individual site configurations.

The Challenge

When we started the assessment, several warning signs were visible right away:

• Several sites showed broken layouts.
• CSS and JavaScript assets were not loading correctly.
• The browser console logged numerous errors.
• Certain pages behaved differently than expected.
• PHP warnings and compatibility issues appeared throughout the environment.

With everything running on a shared Multisite installation, finding the root cause meant working through the infrastructure methodically rather than patching symptoms on one site at a time.

Initial Investigation

Reviewing the server configuration

We started with the server configuration and site routing. During that review we found unauthorized redirect rules inside the site’s .htaccess file. The rules served no legitimate business purpose, and their presence pointed to a compromised environment. Finding redirect logic that nobody had put there on purpose immediately moved this from a troubleshooting job to a security incident.

Inspecting WordPress core files

We then checked the integrity of key WordPress core files. One of the first discoveries was that the site’s index.php had been modified. Instead of the standard WordPress bootstrap, the file carried extra custom logic written to profile visitors and selectively serve different content. That behaviour is a familiar signature of SEO cloaking and malware. Unauthorized code sitting inside a core file confirmed the installation could no longer be trusted without deeper analysis.

Analyzing suspicious PHP files

Digging further turned up heavily obfuscated PHP. The code carried the usual malware traits:

• Encoded strings
• Dynamic function execution
• Hidden routing logic
• Visitor detection
• External communication routines
• Search engine targeting behaviour

The level of obfuscation told its own story. The code was written to dodge detection and make manual analysis as awkward as possible.

WordPress Multisite Assessment

Next we reviewed the Multisite architecture itself. Multiple sites ran from one installation, which meant they shared:

• WordPress core files
• Plugins
• Themes
• User management

Each site kept its own configuration and content, but the shared layer was the real concern. Any compromise touching those shared resources could reach every site on the network, so understanding the structure was essential before recommending any fix.

Browser Console Analysis

To understand the broken front end, we worked through the browser console logs. Several issues stood out.

Missing assets

Multiple CSS and JavaScript files were returning 404 errors, which explained why some sites looked unstyled or only half-rendered.

Mixed content issues

Some resources were trying to load over HTTP while the sites themselves ran over HTTPS. Modern browsers block those insecure requests, so stylesheets, fonts, and scripts simply failed to load.

Rate limiting errors

The console also showed 429 responses, meaning some requests were being blocked by rate limiting or security restrictions. That sent us to look at the security tools, firewall rules, and plugin-level protections that might be involved.

PHP Compatibility Review

While we were in the environment, we also found a number of PHP compatibility warnings. Several plugins and theme components were throwing deprecation notices under newer PHP versions. These were not the cause of the compromise, but they added instability and made troubleshooting harder than it needed to be. Our recommendation was to review plugin compatibility and validate the PHP version against the rest of the software stack.

Key Findings

The investigation surfaced several independent problems across the environment.

Security

• Unauthorized redirect rules
• Modified WordPress core files
• SEO cloaking behaviour
• Obfuscated PHP malware
• Indicators of unauthorized access

Infrastructure

• Multisite configuration complexity
• Shared resources affecting multiple sites
• Missing front-end assets
• Mixed-content configuration issues

Compatibility

• Deprecated PHP functionality
• Theme compatibility concerns
• Plugin framework compatibility warnings

Performance and reliability

• Asset loading failures
• Browser security blocks
• Rate limiting responses
• Front-end rendering issues

Recovery Strategy

With the picture clear, we put together a structured recovery plan:

1. Remove the malicious redirect rules.
2. Replace the compromised WordPress core files.
3. Remove unauthorized PHP files and backdoors.
4. Verify the integrity of the Multisite configuration.
5. Audit themes and plugins.
6. Correct the HTTPS and mixed-content issues.
7. Review firewall and security plugin settings.
8. Reset privileged account credentials.
9. Run a complete malware scan.
10. Put ongoing security monitoring in place.

The point of this sequence is not just to restore the environment, but to harden it so the same thing does not happen again.

Outcome

The investigation pinned down the root causes behind the client’s website problems and exposed evidence of a wider compromise across the WordPress environment. By working methodically through the server configuration, core files, Multisite architecture, console logs, and security indicators, we established a clear recovery path and a set of concrete recommendations for restoring the network safely. It was a good reminder that complex site issues often need WordPress knowledge, security analysis, and infrastructure troubleshooting working together, not any one of them alone.

Key Lesson

WordPress Multisite is powerful, but it asks for careful attention to security and maintenance. When a compromise hits shared resources, the damage spreads across every site at once. A structured investigation is what let us find the hidden issues, uncover the malicious changes, and lay out a route back to a secure, reliable environment. If a WordPress site is behaving strangely, showing security warnings, or rendering broken layouts, a thorough technical investigation is usually the fastest way to find the real problem before it does more damage.