Published on 2 September, 2026 by Lana Miro
What it took to recover a compromised 40-site WordPress network
All responses in this series were submitted by real people and reviewed by the Melapress team. Some details may be generalized to protect anonymity.
When a VP of Technology was asked to help a nonprofit political organization with its WordPress multisite in September 2024, he was stepping into much more than a routine maintenance job.
The network hosted around 40 websites used by affiliated local groups. Around half were very active, with activity across the network increasing at particularly busy times of the year.
The symptoms [of compromise] were Russian text on the front page of a number of their websites. Also, all of the antivirus software seemed to go crazy over the site. There were no backups. Although hosted on AWS Lightsail, backups were only a checkmark away [hadn’t been enabled].
What followed was a huge amount of effort to regain control of the WordPress network. This included removing thousands of infected files, tightening excessive access, addressing outdated software and abandoned plugins, and gradually rebuilding the surrounding infrastructure.
How the security incident started
One of the first things they noticed was that the multisite had multiple Super Admin accounts. He reduced this to two, reset their passwords, and enabled two-factor authentication.
Based on his findings, one of the existing Super Admin accounts was compromised.
As far as I could tell, one of the Super Admin accounts had been compromised and used to write Russian text everywhere. It was also used to load bogus backdoor plugins and compromise the files in the root directory.
He began by removing the visible Russian content and manually deleting obvious malicious files. Security scans revealed how extensive the problem was, as there were more than 6,000 infected files.
Although the organization was already paying for a security/malware scanning tool, he found its advanced features had not been fully configured. At the same time, WordPress had not been updated for at least a year.
After updating WordPress and its components, around 1,500 infected files were removed. He then used the available security tools to repair many of the remaining files, but about 600 JavaScript files could not be fixed.
So I wrote an ad hoc Go routine [a custom script] that fixed the remaining 600 files.
Cleaning the files was only one part of regaining control
The compromised files were only one symptom of deeper, long-standing issues.
He discovered around 1,000 administrator accounts with no associated domain and email addresses that appeared to be fake or invalid. Removing them took several days.
He then reviewed plugins across the network.
Numerous plugins couldn’t be updated because they were abandoned. I deleted any plugins that had no activations. I then focused on the remaining plugins that had been abandoned but were still active and determined which ones were still in use and which could be safely deleted.
He had to stabilize the live websites while simultaneously dealing with the missing security and recovery controls.
Then the sites became unusable again
Around December 2024, during the ongoing recovery work, the network was hit by a major distributed denial-of-service attack. Server load spiked above 12, and the sites became unusable.
Around December 2024, we were hit with a tremendous DDoS attack, which caused load factors of 12+. The sites became unusable. Since we were hosted on AWS Lightsail, I increased the instance size as a temporary fix while I started implementing CloudFront. Luckily, the ‘DDoS as a service’ perpetrators were found and arrested in Europe, and the DDoS attack stopped.
This incident added more complexity to an already complicated recovery.
From cleaning WordPress to rebuilding the environment around it
The original server ran a Bitnami-based stack that limited system-level changes and was still on PHP 7.4.
The organization has since migrated to Ubuntu 24.04 LTS with PHP 8.3.
With help from ChatGPT, I implemented all of the modern security features – fail2ban, AIDE, etc. I also wrote numerous shell scripts to automate the server’s care and feeding and documented them, along with general server duties. Certbot has taken over certificate updating. Netdata monitors my server.
The scope extended beyond WordPress itself. Domains were split across two registrars, while DNS was managed via DigitalOcean. He began consolidating everything into AWS in batches of five domains to manage costs across 40+ registrations, while also removing unused domains.
CloudFront and AWS WAF are planned next steps. What began with Russian text on WordPress sites evolved into a full review of nearly every layer of the environment, including access control, plugins, backups, monitoring, server infrastructure, DNS, and domain management.
Much of that work was done by an unpaid volunteer
Behind the technical details is a less visible part of the incident. The person carrying out the recovery was doing it as an unpaid volunteer.
I have over 50 years of experience in the software industry, and I am fully retired at this point – except for taking care of the organization’s needs.
The work continued long after the initial compromise was stopped.
The lesson
This story is about what can happen when important security and recovery controls have not been fully implemented or maintained.
Looking back, the volunteer does not point to a single advanced tool or complex fix, but to underused fundamentals. Their security and malware scanning tool was paid for but not fully configured, Super Admin access was too broad, and two-factor authentication was not enforced.
He believes stronger access control could have prevented the situation from escalating:
If they had implemented 2FA for their Super Admins and limited the number of Super Admins to two or three, this disaster probably would not have happened.
The key lesson is not about any single vulnerability, but about properly configuring existing security tools, enforcing least-privilege access, and maintaining backups.
The broader takeaway is how much work can sit behind the phrase “compromised WordPress site.” In this case, the response expanded from malware cleanup into months of unpaid effort rebuilding the systems and processes behind roughly 40 websites.
Have you dealt with a WordPress security incident?
Your story can show what security incidents really look like beyond the statistics, including the impact and lessons that are easy to miss.
Tell us what happened, what the experience was like, and what you learned from it. Stories may be published anonymously.
