The alert that changed the picture
There was no broken homepage or dramatic warning from a browser. The customer had been using their site without knowing anything was wrong, which is why the first result inside BugShield mattered so much. It did not say the site was definitely infected. It said there was a possible infection that needed attention.
The cautious wording is deliberate. WordPress sites contain thousands of files, and not every unfamiliar one is malicious. Developers add custom code, plugins generate files of their own, and old installations can accumulate all sorts of forgotten leftovers. A scanner can tell us where to look, but it takes an investigation to understand what has actually been found.
In this case, the warning held up. We reviewed the suspicious files in context, looked at what the code was doing, and confirmed malware. The more unsettling discovery came next: the infection was not recent. It had been on the server for months, sitting quietly behind a website that still looked normal.
We are keeping the customer, the website, and the precise file locations private. The useful part of this story is not who they are. It is how long a compromised site can continue to look perfectly ordinary.
A working website is not necessarily a clean website
When people imagine a hacked WordPress site, they usually imagine something they would notice straight away. Perhaps the homepage has been replaced, visitors are being redirected, or Google is showing a security warning. Visible symptoms do happen, but they are only the noisy end of the problem.
Malware can be much quieter. It might preserve a hidden way back into the server, wait for instructions, or only act when a particular visitor or search engine arrives. Some infections appear intermittently. Others hide inside familiar plugin or upload folders where one unusual file is easy to miss among thousands of legitimate ones.
From the customer's point of view, the site still loaded and the usual work could continue, so it felt healthy. In reality, a successful page load only tells you that one page worked for one visit. It says very little about the rest of the server, the database, administrator accounts, scheduled tasks, or hidden access an attacker may have left behind.
The scan found the clue. The investigation found the answer.
It would have been easy to treat the first alert as proof and rush straight to the word hacked. Calling the site hacked immediately might make a stronger notification, but it would not make a more accurate one. Security checks are most useful when they narrow the search without pretending to know more than the evidence shows.
The real work begins after the alert. A suspicious file needs to be compared with the software that should be there. Its location, contents, history, and behaviour all matter, along with everything around it. An infection may also involve unfamiliar administrators, altered database records, must-use plugins, scheduled jobs, or other files that were never included in the first warning.
Only after completing the review could we say the finding was genuine. The automated check created the opportunity to catch it; human judgement turned that signal into a confirmed problem we could act on for the customer. Neither part is very useful on its own.
Months of infection change what you can trust
Finding malware is bad enough. Learning that it has been present for months makes the response more involved, because the clean point you would normally return to may be much further back than expected.
Take backups. Restoring yesterday's copy feels like a sensible first move until you realise yesterday's copy probably contains the same infection. The same may be true of last week's and last month's. A backup is still valuable, but its date alone does not make it safe. It has to come from a point before the compromise, or be cleaned and checked before it goes back into service.
The trail also gets colder with time. Hosting logs are not always kept for months, and the change that first let an attacker in may now be buried beneath later updates. Even if the original weakness has since been patched, any backdoor planted before the patch can remain. Updating closes a known entrance; it does not automatically remove someone who is already inside.
Then there are credentials. If the incident reached beyond WordPress itself, changing a single administrator password is not enough. Hosting, SFTP, SSH, database, and other privileged access may all need to be reviewed. Credential changes should happen in a sensible order, after the routes into the site have been understood, so fresh credentials are not handed straight back to the same attacker.
Why deleting the flagged file is rarely the end
A malware alert naturally draws attention to the file named in the warning. Delete that file and the visible problem disappears from the scanner, but that does not tell you whether another copy exists or whether the attacker still has a way to recreate it.
A proper cleanup follows the infection through the site. It checks WordPress core, plugins, themes, uploads, must-use plugins, the database, administrator users, scheduled jobs, and server configuration. It also asks how the code arrived, closes that route where it can be established, and verifies the result before a fresh backup is treated as the new clean starting point.
Taking time over the cleanup helps prevent the familiar cycle where a site appears clean for a few days and the malware quietly returns.
If a malware warning appears on your site
The best response is calm and methodical. Do not ignore the warning because the website still works, but do not start removing unfamiliar files at random either. Both reactions can make the eventual investigation harder.
- Preserve a private copy of the current site. Keep the files and database for investigation, while remembering that this is evidence and not a clean recovery point.
- Have the warning reviewed in context. Confirm what the file is, what it does, and whether anything related has changed elsewhere in WordPress or on the server.
- Trace and close the likely access route. Update or remove vulnerable software and review every privileged route into the hosting account and website.
- Rotate the credentials that may have been exposed. Make the changes from a device and account you trust, once the environment is ready to protect the new details.
- Verify the clean state. Rescan, compare files with trusted copies, test the important parts of the site, and only then create a fresh off-site backup.
Our manual WordPress malware guide goes further into the technical checks. If you would rather have a developer handle the investigation and cleanup, see WordPress malware removal.
What stays with us from this case
The timing is the part that stays with us. BugShield did not spend weeks watching the site before stumbling onto the problem. The warning appeared during the first checks, but the malware had already been there for months before the customer connected the site. Everything looked normal, so nobody knew there was anything to investigate.
Starting with a proper baseline matters. When monitoring begins, the first job is not simply to watch what changes tomorrow. It is to understand what is already there today. Otherwise, an old compromise can quietly become the starting point everyone assumes is safe.
Nobody wants to learn that their website has been infected. Finding out before the homepage breaks, visitors are redirected, or a search engine raises the alarm is still the better moment to discover it. A website does not need to look hacked to be hacked, but it also does not need to stay that way simply because the warning signs were quiet.
Quick answers about undetected WordPress malware
Can a WordPress site have malware and still work normally?
Yes. Some malware is designed to stay quiet, preserve hidden access, or affect only certain visitors. The homepage can keep loading while malicious code remains elsewhere in the files, database, user accounts, or scheduled tasks.
Why did the first alert say possible infection?
A scanner can identify an unusual file or pattern, but it cannot always understand the reason it is there. Calling the result possible gives a person time to review the file, its behaviour, and the surrounding site before confirming whether it is malware.
Can WordPress malware stay undetected for months?
It can. Malware that does not break the website or appear for every visitor may sit outside the owner's normal view for a long time. Regular checks create an opportunity to find it before a visible symptom brings the problem to everyone's attention.
Will deleting the flagged file remove the infection?
Not necessarily. The first file may be one part of a wider compromise, and another backdoor may recreate it. The investigation should cover the wider files, database, users, scheduled tasks, credentials, and the route the attacker may have used.
What should I do after a WordPress malware warning?
Keep a private copy for investigation and have the warning reviewed before deleting unfamiliar files. If malware is confirmed, clean the whole site, close the access route, rotate affected credentials, verify the result, and then create a fresh off-site backup.