If you run a WordPress site, you’ve probably got a security plugin installed. Wordfence, Sucuri, something like it. It runs a scan on a schedule, sends you a green checkmark, and you move on with your day.
Here’s the part nobody mentions: a clean scan only means the scanner didn’t recognize what it saw. It doesn’t mean nothing’s there. I found that out the hard way a few weeks ago, working on a white-label agency’s client site.
The tip-off nobody thought was a big deal
We were onboarding two of a client’s sites onto a care plan. Small thing stood out. Plugins weren’t listing correctly in the WordPress admin. Someone had already looked at it once and figured it was a display glitch, not a security issue, and moved on.
I didn’t buy it, so I connected PressConduit and asked Claude to look into it directly, reading the site’s actual files instead of trusting the admin screen.
A plugin wearing a costume
Sitting in the plugins folder was one called “Image Optimizer.” Reasonable name. Nobody would blink at it.
Except it wasn’t an image optimizer. It was WordPress’s own built-in sample plugin, Hello Dolly, the one that ships with every fresh WordPress install and just prints a random song lyric. Same plugin header. Same author name. Same description, word for word. Somebody had gutted the actual code and replaced it with something else entirely.
Here’s what that “something else” did, every single time anyone loaded a page on the site: it decoded three hidden server addresses, packaged up a copy of the site’s own server information, sent it to whichever address answered first, and ran whatever code came back.
That’s not “possibly compromised.” That’s a live door, wide open, to anyone holding the key.
Why the security scanner missed it
The site had Wordfence running on a normal schedule the entire time this was active. It never flagged it.
Not because Wordfence is bad. Because the free version’s malware signature database runs about 30 days behind the real-time paid version. If the pattern used here is newer than that, or just wasn’t in the free set yet, a perfectly healthy-looking scan sails right past it.
Free security scanning isn’t nothing. It’s also not the same thing as current security scanning. Worth knowing the difference before you assume “clean scan” means “safe site.”
The part that actually worried me
Deleting the fake plugin should have ended it. It didn’t.
Buried in a folder called mu-plugins, one WordPress loads automatically and never shows in the Plugins list at all, sat a second file. Its only job: on every page load, check whether the backdoor still existed, and if it didn’t, quietly rebuild it from scratch and turn it back on. Delete the backdoor, and one page load later, it’s back.
And the same setup, byte for byte identical, showed up on a second site belonging to the same client. Not two separate break-ins. One shared source, almost certainly from a site migration or clone that copied an already-infected install onto a second one.
What actually fixing it looked like
- Deleted the fake plugin once its actual code was confirmed, not just its suspicious name.
- Found and shut down the hidden file quietly rebuilding it before it could reactivate.
- Checked for planted admin accounts (none, thankfully) since a backdoor this deliberate often leaves a second way in.
All of it done in one sitting, through conversation. Never opened FTP. Never opened a code editor by hand. Just asked, and got answers straight from the site’s own files and database.
Frequently asked questions
Does a clean security scan mean my WordPress site is safe?
Not necessarily. A scan can only flag what its signature database already recognizes. Free-tier plugins like Wordfence run their malware signatures about 30 days behind the real-time paid version, so a genuinely infected site can still show a green checkmark if the threat is new or uncommon.
How do hackers disguise a WordPress plugin?
A common trick is reusing a real plugin’s header, author name, and description word for word while replacing the actual code underneath, usually with a common, official-sounding name that a site owner wouldn’t think to question. Checking whether a plugin’s stated purpose actually matches its code is one of the more reliable ways to catch this.
Why did deleting the malicious plugin not fix the site?
Some backdoors plant a second file in WordPress’s mu-plugins folder, which loads automatically and never appears in the Plugins list. Its only job is to check whether the main backdoor still exists and silently rebuild it if it’s been removed. A full fix has to find and remove that persistence file too, not just the plugin itself.
Not sure if your site’s actually clean?
A clean scan from a free security plugin is a reasonable first layer. It is not proof. If something on your site looks slightly off, even something as small as a plugin list not rendering right, that’s worth a real look, not a shrug. This is exactly the kind of thing I check as part of ongoing WordPress maintenance and support, and it’s the same approach I bring to white-label work for agencies managing client sites.
First one’s on me if you want a second set of eyes on a site you’re not sure about. Reach out and let’s take a look.
