Published on 2 September, 2026 by Lana Miro
The website hack that cost a small agency nights, revenue, and family time
All responses in this series were submitted by real people and reviewed by the Melapress team. Some details may be generalized to protect anonymity.
There were several times that we thought we had resolved the issue, but then it popped up again.
What happens when you run a small two-person agency and one of your nonprofit clients’ websites gets hacked? That is exactly what happened to this WordPress agency.
The compromise quickly became much more than a website cleanup. It meant nights and weekends spent investigating what had happened, lost revenue from hours they did not feel comfortable billing, less time for other clients, and personal time taken away from their families.
It was so stressful! It took a lot of our personal time. We are a 2-person agency and had to work nights and weekends on this, which directly cut into our lives and our time with our families.
They didn’t find out until the client said, “Our site is hacked”
The agency did not learn about the incident through an automated security alert. The client found the problem and opened a support ticket.
The client submitted an ‘our site is hacked’ support ticket. We were horrified to see the website so hijacked when we checked it.
By then, the compromise was visible to anyone visiting the nonprofit’s website. Its homepage had been replaced with gambling-related content.
The site was compromised at the server level. We think they gained access to a client’s admin-level account at the host. They created FTP users, added files to the site, and inserted code into the child theme’s functions.php. They took control of the website and replaced the homepage with content promoting what appeared to be an Indonesian gambling site.
Restoring the homepage was only part of the job. The agency also had to find out how the attacker was getting in, clean up the site, and deal with the compromise returning after they thought it was fixed.
The cost went far beyond cleaning the website
The cleaning and site recovery process quickly began affecting nearly every part of the business.
We lost revenue because we didn’t feel comfortable charging them for the full number of hours we spent on remediation, partly because we felt we couldn’t charge them for having to learn the security topics we had to get up to speed on quickly.
It cut into our time and ability to do the work we needed to do for other clients.
Honestly, it was also existentially depressing – there were several times that we thought we had resolved the issue, but then it popped up again, and each time it was maddening but also super disheartening to wonder why people out in the world decide to be the kind of person who hacks a nonprofit website and makes me, personally, miss bedtime with my daughter, etc.
This is the kind of impact that is difficult to see in security statistics. A compromise may be recorded as a technical incident, but the experience of dealing with it can reach much further into the people and businesses behind the website.
What changed after the incident
After the incident, they changed how they approach security across their client sites. One of the biggest changes was reconsidering who had access to what.
In general, we have implemented Patchstack on our client sites, reassessed who gets admin-level access to things, and tried to educate ourselves about preventative measures and how to ensure this doesn’t happen again.
The incident made the team realize that good WordPress development practices alone weren’t enough to prevent this kind of attack.
We had thought we were building sites securely, so it was frustrating to realize that the underlying issue was ultimately out of our hands (since the problem was not our WordPress setup, our tech stack, or our choice of host, but a hacker who came in through a host-level client account via unknown means beyond our control).
The lesson
Now, we definitely consider security at more stages of the process than we used to.
The incident did not lead them to one magic security fix. It made them look at the whole environment around the website: WordPress, hosting accounts, credentials, file access, and who has permission to do what.
That is a useful habit for any agency, and it should extend beyond keeping WordPress, plugins, and themes up to date. It also means regularly reviewing access, limiting administrator-level privileges, using strong authentication like MFA, and ensuring that unexpected changes can be detected.
It’s important to ask yourself:
- Who currently has administrator-level access to WordPress and the hosting account, and is it still required?
- Are there any inactive, legacy, or unnecessary accounts, credentials, or API keys still in place?
- Do we have a way to detect or be alerted to unexpected changes in files, users, or configuration?
- If a compromise was reported today, do we have a clear understanding of where to start investigating?
You cannot prevent every security incident, but you can make one less likely and reduce the impact if it happens.
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.
