The WordPress Hack That Two Security Plugins Could Not See

At a glance

The website looked perfectly fine. That was the problem.

The client came to us because they suspected something was wrong with their website. Nothing obvious. No defaced homepage, no scary browser warning, no locked-out admin account. The site loaded normally. Every page worked. Their team used it every day and saw nothing unusual.

They had two respected security plugins installed. Both had scanned the site. Both said it was clean.

They were right to be suspicious. Their website had been compromised for around nine months.

What the attacker was actually doing

This was not vandalism. The attacker had no interest in damaging the site or bothering its visitors. They wanted something more valuable: the website’s reputation with Google.

A hidden program had been placed inside the WordPress installation. On every single page request, it checked who was asking:

• A real person? Show the real website. Everything normal. Nobody suspects a thing.
• Google’s search crawler? Show completely different pages, full of spam links, pulled live from the attacker’s own server.

This technique is called cloaking — showing one thing to search engines and another to people. It is one of the most serious violations in Google’s guidelines, because the attacker is effectively renting out the trust that the real business spent years building.

The hidden program could also redirect visitors to any address the attacker chose, serve a fake sitemap, and overwrite the site’s robots.txt file to point Google towards the spam. We found evidence it had done exactly that, as recently as two days before we took our copy of the site.

Why two security plugins found nothing

This is the part worth understanding, because it applies to every WordPress site.

The malicious code was saved in files ending in .txt — the same extension as an ordinary notepad file. They sat in the site’s uploads folder, among the images.

Most malware scanners concentrate on the file types that can actually execute: .php and similar. A text file in an images folder is not usually treated as a threat, so it is not read as code. The attacker knew this, and used it.

Two things made it work:

1. The disguise. Program code hidden behind a harmless file extension.
2. A missing protection. The uploads folder had no rule preventing programs from running inside it. On this site, that protection file existed but was completely empty — one byte. Uploads folders should never be able to execute code. This one could.

The scanners were not broken. They were looking exactly where they were designed to look. The attacker simply stood somewhere else.

How we found it

We treated it as a forensic job rather than a scan, and worked on a full copy of the site so that nothing on the live server was disturbed while we investigated.

We read the evidence, not just the files. The single most useful discovery was not malware at all — it was the site’s own PHP error log. It contained the same error repeating for months: a file that should be a harmless 28-byte placeholder was instead reading visitor browser information and loading the rest of WordPress. A legitimate version of that file does none of those things. That one repeating error gave us the attacker’s method and a timeline going back to October 2025.

We checked everything, not just the likely places. Every one of the 8,732 program files was examined for known malicious patterns and code obfuscation. WordPress’s own core files were verified against what they should contain. Every .htaccess rules file was read in full. Every uploaded image was checked for code hidden inside it.

We audited the database, not just the files. Malware frequently hides in the database rather than in files — in scheduled tasks, in stored settings, or as a secret administrator account. We checked all of it.

We proved the fix, rather than assuming it. After cleaning, we requested the homepage twice: once identifying as a normal browser, once identifying as Google’s crawler. Before the clean-up those two requests could return different pages. Afterwards they were byte-for-byte identical. That is what “the cloaking is gone” actually looks like as evidence.

What we found, beyond the malware

Two things stood out, and both are common on older WordPress sites.

The likely way in. A file manager plugin had been installed on the site at some point. This type of plugin lets someone browse and upload website files straight from a web browser, and this particular one has a long public history of vulnerabilities that allow uploads without logging in. Its leftovers were still present, including a folder it had created at the very top of the website with fully open write permissions.

The infection had survived a hosting migration. The error log showed the same problem on two different servers with two different hosting companies. The site had been moved, and the malware was carried across inside a restored backup. This is the single most important lesson from the whole job: if a hack is old enough, your backups are infected too. Restoring one just reinstalls the problem.

What we did

• Removed the malicious files, keeping verified copies as evidence
• Removed the file manager plugin’s leftovers and the open folder it had created
• Blocked code execution in the uploads folder — the protection that had been missing
• Disabled WordPress’s built-in file editor, so site files cannot be edited from the admin screen
• Found and removed a saved website export that still contained the attacker’s robots.txt. Had it been published, the problem would have come straight back
• Repaired the site’s sitemap, which we discovered was returning an error — meaning Google could not read the page list properly
• Preserved a complete evidence record, with checksums and the log extract, for the client’s insurer or hosting provider

Nothing was permanently deleted. Everything removed was moved to a sealed folder, together with a copy of the database taken before we started.

We also made the site considerably lighter

Years of plugins had been installed and removed without their data ever being cleaned up. That build-up slows a site down and gives future problems more places to hide.

Fifty database tables belonged to nine plugins that were no longer installed at all. One page alone had accumulated 203 saved revisions. We also removed a 54 MB video file that was not used anywhere on the site.

Every page was tested after each stage. All of them still work, the enquiry forms still work, and the site’s search-engine tags are intact.

What the client got

• A verified clean copy of their website, tested page by page
• Written evidence of what happened, when, and how — in plain language, with a technical appendix
• A faster, lighter site with far less to maintain
• A clear plan for making this class of attack impossible in future

Five lessons for any WordPress site owner

1. A clean scan is not proof of a clean site. Scanners check what they are designed to check. This malware survived two of them by using a file extension they had no reason to inspect.

2. Your uploads folder must never be able to run code. It exists to hold images and documents. If a file lands there, it should be impossible to execute. This is a one-line rule, and on this site it was missing entirely.

3. Never install a plugin that manages files through the browser. It is convenient, and it is one of the most reliable ways a WordPress site gets compromised. Use secure file transfer instead.

4. Read your error logs. The most valuable evidence in this entire investigation was sitting in a log file that nobody had opened. It had been recording the attack, in detail, for nine months.

5. Assume old backups are infected. If a hack has been present for months, it is inside your backups too. On this site the infection survived a complete change of hosting company by travelling inside a backup. Clean forward — do not roll back.

The bigger point

A hacked website does not always look hacked. In this case the business had no broken pages and no customer complaints — but for nine months, the version of their website that Google saw was not their website at all. The damage was to their search visibility and their reputation, which are slower to notice and slower to repair than a defaced homepage.

If your WordPress site feels fine but your search traffic has drifted for reasons nobody can explain, that is worth investigating properly.

Growww Tech does forensic WordPress investigations, malware removal, and hardening — and we tell you plainly what we found, including the parts that are inconvenient. If the investigation ends with you deciding WordPress is more upkeep than it is worth, our honest Shopify vs WooCommerce comparison is the next thing to read.