The host found one malicious plugin. There were eleven.

The situation

The client had asked us for a confidential technical audit: performance, mobile navigation and how maintainable the site was. Before that could start, the site went offline. It had moved to a new host in July, had an outage within two weeks, and then the admin slowed to a crawl with "508 Resource Limit Is Reached" errors. The host's scanner had found one malicious plugin, removed it, and considered the matter closed.

The site stayed offline behind a maintenance page while we worked, so visitors were not exposed.

What the investigation found

• Eleven malicious plugin folders and twelve tampered files, in four distinct families, against the single plugin the host had flagged.
• Two of the files allowed anyone to run commands on the server without logging in. Their payload was obfuscated, and none of the 77 scanner records we reviewed had flagged them.
• The error logs showed the malware already running on the previous host two months before the move. The migration had carried the infection across rather than causing it.
• The most likely way in was a known upload flaw in an outdated version of the theme's companion plugin. Its updates had silently stopped for ten months because the update licence was never registered. We say "most likely" because the host's access logs for that period no longer existed.
• We also checked a WordPress core flaw announced in the same weeks. There were attempts against it in the logs, and no sign any of them worked.

The cleanup

Every malicious folder was removed and every tampered file replaced from an official copy. WordPress, the theme and its companion plugin were brought up to date, 18 plugins were reinstalled from clean sources and 10 updated, and all security keys were regenerated. We blocked PHP from running in the uploads folder, switched off file editing and XML-RPC, added firewall rules, and replaced the shared admin login with three named accounts protected by two-factor authentication.

A final scan before going live found one more hidden payload inside a legitimate plugin. We removed it, scanned again, and only then put the site back online, five days after we were hired.

Then the slowness

With the site clean, the client asked us to look at speed. The homepage was taking 5 to 11 seconds before the server sent its first byte, with 125 requests, 53 of them stylesheets. The cause was not the hosting: page caching had never been switched on, and an unused calendar plugin was disabling it. The server was also missing the image libraries WordPress needs to create smaller images.

After the second phase the server responded in about half a second, the admin page list loaded in about a second instead of thirty, and the homepage weighed about half as much, with 1,068 images served as WebP and fonts hosted on the site itself. We advised against a paid CDN and a hosting upgrade, because neither was the problem.

Results

• A site cleaned of malware that a host-level scanner had missed, with the likely entry point closed.
• Back online five days after hire, and hardened against the same thing happening again.
• Server response roughly ten times faster, without spending more on hosting.
• The client moved onto a monthly care plan with us afterwards.

This was a security incident, so the client, the site and anything that could identify them are withheld. Details are taken from the project record.