It started as a completely ordinary request. A client reached out to us asking for a secure WordPress backup before making some changes to their site. No alarm bells. No red flags. Just a sensible business owner wanting to protect their digital asset before anyone touched it.
We see this regularly at Kinski & Bourke. Clients come to us for WordPress maintenance in Sydney, and a pre work backup is always our first step regardless of what the job involves. Before we update a single plugin or adjust one line of code, we document the full state of the site and store a clean copy offsite.
What we found this time was anything but routine.
What we were working with
The site was running on a premade WordPress theme, one of those widely distributed templates that tens of thousands of sites use simultaneously. Alongside it sat a stack of plugins, most of which had not been updated in years. The WordPress core itself was behind. The theme was behind. The plugins were behind. Everything was sitting in the same state it had been left in, largely untouched for a significant stretch of time.
This kind of setup is extremely common and extremely risky. According to aegiswebs.com, WordPress malware can inject spam links, redirect visitors to malicious domains, create hidden admin accounts, and corrupt your sitemap, all while the site owner remains completely unaware. The client in this case had no idea anything was wrong. The site looked fine to them. It loaded. It functioned. Business continued.
That is exactly what makes this type of infection so dangerous.
Something looked wrong in the files
As we worked through the backup process, certain files caught our attention. They did not belong where they were sitting. The naming conventions were off. The file locations were unexpected. Experienced WordPress developers recognise these patterns because we have seen them before, and what we were looking at did not match any legitimate plugin or theme component.
We reversed the obfuscation on those files and confirmed what we suspected. The site had been carrying malware, and based on the code signatures and the outdated version of the theme it was embedded in, this infection had been sitting dormant or actively operating for approximately five years.
This aligns with what kinskiandbourke.com documented in a separate case: popular premade themes create what security specialists call hackeconomics. When a vulnerability exists in a widely distributed theme, a single exploit can compromise thousands of sites at once. The return on investment for the attacker is enormous. For the site owner, the risk is invisible until something forces a closer look.
In this case, that forcing function was a routine backup request.
How we cleaned the infection
We did not rush the remediation. Cleaning a WordPress site that has been compromised requires a methodical approach, not a fast one.
The process we followed:
- Isolated the infected files and documented exactly what we found before removing anything
- Replaced the compromised theme files using clean source versions, not the existing installation
- Audited every plugin for outdated versions, unused installations, and any files that did not match their official release checksums
- Checked the database for injected content, hidden admin accounts, and any records that referenced malicious domains
- Reviewed the wp-config.php file and server level configurations for any alterations
- Scanned the uploads folder because, as aegiswebs.com notes, PHP backdoors are frequently hidden inside /wp-content/uploads/ where they are easy to overlook
- Ran external scans using tools like Sucuri SiteCheck to verify the domain had not been blacklisted by Google or other services
Once we were satisfied the site was clean, we did not simply declare victory and close the job. We ran a second full audit of the entire installation to confirm nothing had been missed. Only after that secondary check passed did we proceed.
The secure backup happened after cleaning, not before
This is an important distinction that many guides get wrong. We took a backup at the very start of the process to preserve the original state for forensic purposes. That copy was kept separately and was never treated as a restore point.
The secure, offsite backup we delivered to the client was taken only after the full clean. It represented a verified, malware free version of their website. That is the copy they now have stored safely away from the server, ready to be used as a genuine recovery point if anything ever goes wrong in the future.
Storing a backup of a compromised site as though it were clean is one of the most common mistakes in WordPress incident response. You would essentially be preserving the infection and potentially restoring it later. As mdpabel.com correctly states, even a hacked backup has forensic value, but it must never be confused with a safe recovery backup.
What the client did not know was hurting them
The client had no symptoms they could point to. No redirects they had noticed. No Google warnings on their listing. No customer complaints. From their perspective, the website was working.
This is a known pattern. As benryan.com.au explains, compromised sites can carry malware that operates silently for extended periods. Google may or may not have flagged the domain depending on what the malware was doing at any given time. In this case, the infection appeared to be dormant or operating in a way that did not trigger visible symptoms for the end user.
Silent infections are still infections. They still represent a vulnerability that can be activated, escalated, or exploited at any point. The five year window this code sat undetected is not unusual for sites running on outdated, unmonitored installations.
What we put in place after the clean
After delivering the verified backup, we walked the client through a baseline security and maintenance posture:
- All plugins updated to current stable releases
- Theme replaced with a maintained, actively supported version
- WordPress core updated
- Login security strengthened with two factor authentication
- Automated offsite backups scheduled on a regular cycle
- Monitoring configured to flag file changes and suspicious login attempts
These are not advanced measures. They are the minimum viable security posture for any WordPress site in 2026.
The lesson for every WordPress site owner
Your site does not need to look broken to be compromised. The absence of visible symptoms is not evidence of a clean installation. If your WordPress theme is outdated, your plugins have not been touched in years, and you have never had a professional audit of your files, there is a meaningful probability that something is sitting in your installation that should not be there.
A secure WordPress backup is always worth doing. Sometimes, like in this case, the backup process is what saves you.
If you want us to run a backup and security audit on your site, get in touch with the team at Kinski & Bourke.
Photo by Tima Miroshnichenko