How a Forgotten Plugin Nearly Cost a Client Their Store — and What We Found When We Went Looking

"We changed the password. It got hacked again anyway."

That's how most of these conversations start.

A client running a WordPress store came to us after being hacked repeatedly. Each time, they did what most site owners are told to do: change the admin password, maybe change the hosting password too, and hope it sticks. Each time, within weeks, something was wrong again.

By the time they reached us, they weren't looking for another password reset. They wanted to know why it kept happening — and whether their previous developer had simply missed something, or whether the site itself was fundamentally compromised in a way a password change could never fix.

It was the second one.

What we found

The short version: the site had been compromised through a vulnerable plugin, and the attacker used that access to plant a backdoor — a hidden file that lets them back into the site whenever they want, completely independent of any WordPress login. Password resets don't touch a backdoor like this, because the attacker was never relying on the password in the first place.

Once we started digging, we found the plugin responsible for the original entry point had itself been removed — not by the client, and not by us. Attackers frequently do this once they've established a backdoor: remove the vulnerable plugin that let them in, so a site owner (or a less thorough investigator) looking at the installed plugin list sees nothing unusual, and the original point of entry disappears from view entirely.

We also found something the client hadn't noticed at all: a page on their live site promoting an online casino, styled to blend in perfectly with their actual theme and branding — same header, same footer, same fonts. It wasn't linked from anywhere in their navigation, so a normal visitor (or the client themselves) would never stumble across it. It existed purely to be indexed by search engines. Digging into the database turned up several more posts just like it, created and quietly deleted over the preceding weeks.

This is a far more common outcome than most business owners expect. A compromised WordPress site isn't just a security problem — it's a monetisable asset to whoever controls it. Injecting spam content that targets high-value search terms (gambling, pharmaceuticals, replica goods, and similar categories are the classic examples) lets an attacker piggyback on a legitimate site's existing search engine trust, and often builds backlinks that benefit other sites the same attacker controls. Your store's hard-earned domain reputation becomes someone else's SEO asset, quietly, in the background, while everything looks normal on the surface.

How we found it

None of this was visible from the WordPress admin dashboard. That's the point of a well-hidden backdoor — it's designed not to be visible from the places a normal site owner would look.

Our process combined a few layers, deliberately, because no single check catches everything:

Offline malware scanning. We pulled a full local copy of the site's files and ran it through signature-based scanning tools (ClamAV and Linux Malware Detect), looking for known-bad code patterns. This is a useful first pass, but it only catches malware that matches an existing signature — it won't catch something custom-written or well obfuscated.

Manual pattern review. We searched the codebase for common backdoor indicators — code that decodes and executes hidden payloads, unusual file-execution calls, and files sitting in locations that should never contain executable code (more on that below). A simplified, defanged example of the kind of pattern we look for:

// Illustrative only — payload removed
eval(base64_decode("<hidden_payload_removed>"));

This pattern — decoding a chunk of scrambled text and then executing it as code — is one of the most common ways attackers hide what a backdoor actually does from a casual glance at the file. On its own, spotting this pattern isn't proof of compromise (some legitimate plugins misuse base64 for harmless reasons), which is why automated pattern-matching always needs a human reviewing the context, not just a keyword search.

Checking where files shouldn't exist. WordPress's uploads folder is meant to hold images, PDFs, and similar media — never executable PHP. Finding a .php file sitting in that folder is one of the strongest single signals of compromise there is, because there's essentially no legitimate reason for it to be there.

Database investigation. The spam content wasn't sitting in an obvious "recent posts" list — it had already been partially cleaned up and trashed. We queried the database directly for post history, publication patterns, and associated media, which is how we uncovered the fuller scope of what had been published and quietly removed over time.

Checksum verification. WordPress core files should match, byte-for-byte, what's published on WordPress.org for that exact version. Comparing the client's live files against the official release is one of the most reliable ways to catch a modified core file that a signature scanner might miss entirely.