Updated on 2 September, 2026 by Lana Miro
The hidden compromise behind a WordPress website defacement
All responses in this series were submitted by real people and reviewed by the Melapress team. Some details may be generalized to protect anonymity.
On the surface, it [the incident] looked like someone had just tried to hack the website to put out a message. But [the defacement] was actually a false cover for what was going on. Under the surface, there were [malicious] files scattered throughout the site’s file system, and [the compromise] wasn’t limited to just one website.
When Rick Curran first looked at the compromised WordPress website, the problem appeared relatively straightforward. Someone had replaced the usual homepage with a page containing Arabic text and what appeared to be a political or religious message.
Removing that page brought the website back, but the visible defacement was only the surface of the incident. Underneath it, malicious PHP files had been spread throughout the WordPress installation and across other websites accessible on the same server. Even after Rick and another developer removed them, the files returned the following day.
At first, it looked like a simple defacement
Rick has worked with WordPress since around 2010, across projects ranging from small websites to more complex web applications.
Among the compromised websites he has dealt with over the years, one incident stands out for both the scale of the infection and the work required to fully resolve it.
At first, the most obvious sign was the homepage. A file placed on the website was overriding its usual homepage. Deleting that file made the site appear normal again, but Rick was not convinced that the problem had been resolved.
I was like, well, if someone’s going to put an index HTML file [in the website’s root directory], then they’ve also got permissions to [write other files there]. So I was just very suspicious.
That suspicion led him deeper into the server’s file system.
Then they found what was hidden underneath
Rick began manually checking the WordPress directories.
It did not take long to find files that did not belong there: randomly named PHP files mixed in with legitimate WordPress files, including the wp-admin directory.
Being familiar with the folders that are meant to be inside of wp-admin and the various other folders as part of a WordPress installation, it was like, yeah, that’s not meant to be there.
Examining the files revealed obfuscated PHP and other signs of malicious code.
You could see that there was basically a lot of obfuscated PHP in there. And you could see there were PHP eval calls and various kinds of things, which are sort of hallmarks of some of the things that malware will do.
Rick was running a small three-person company at the time, so another developer joined the investigation. Together, they wrote shell scripts to work through the directories and identify the suspicious files.
At first, that seemed to work, but:
The next day, all the files were back again. All those weirdly named files came back into the server.
The question was no longer simply how to remove the malware. They had to find out why the attacker could still put the files back.
Finding the way back in
The team then had to move from removing the malicious files to finding out how they were getting there.
Because of how the server permissions were configured, someone who gained file access through one website could also reach other WordPress installations on the same server. Rick and his team had to investigate all the affected sites, not only the website that had been visibly defaced.
Rick traced the entry point to an older website that had been running for around six or seven years and still depended on a plugin that was no longer being maintained.
The problem was that there was one particular plugin that was basically obsolete. And there hadn’t been any updates to that. And it just had a big vulnerability in it that was allowing effectively unfiltered file uploads to be pushed in there.
Rick remembers the plugin as Flutter, which had been used to configure custom post types.
That plugin, at the time it was built, was fine. There were no kind of real issues. But then obviously some kind of vulnerability became known.
The vulnerable plugin provided a route into one website, while the server’s permission settings allowed the malicious files to be distributed across other accessible WordPress installations.
Removing the plugin closed the route the attackers had been using. Rick then rebuilt the affected websites using fresh WordPress installations and clean copies of their themes.
This time, the malicious files were gone.
The incident changed how they maintained client websites
After the incident, Rick and his colleagues increased their efforts in security monitoring, server permissions, and the review of long-running software across client websites.
We kind of wrote our own tools to specifically look for the telltale signs of that particular hack. We set them up to run as cron jobs on the server every night, and also incorporated some checks of the plugin versions. It meant we kept much more awareness of what plugins were sitting on websites that had been there for quite some time.
They also started paying much closer attention to software that had been sitting on client websites for a long time.
We certainly kept a much greater awareness of what plugins we have got sitting on websites that have been on there for quite some time.
The lesson
It’s much easier to prevent it than it is to try and fix and clear these issues up.
For Rick, the experience led to a more continuous approach to WordPress security.
That includes keeping WordPress and its wider server environment maintained, reviewing software installed for a long time, limiting permissions, monitoring for unexpected changes, using security controls on WordPress sites, and making security part of an ongoing maintenance process rather than something addressed only after a compromise.
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.
