Why Free Scanners Miss Backdoors

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

You have run three different scanners and they all report the site is clean. The redirect is still happening. This is one of the most disorienting positions to be in, because the tools you were told to trust are telling you there is nothing wrong. They are not lying to you — they are answering a narrower question than the one you are asking.

How scanners actually work

Most website scanners do two things. They compare your files against known-malicious signatures, and they compare your core files against official copies to detect modification. Both are genuinely useful and both are fast, which is why every security plugin does them.

The limitation is in the question being asked. A signature scan asks whether this file matches something already catalogued as malicious. A file integrity check asks whether this file differs from the official version. Neither asks whether this file should exist or what it actually does, and the gap between those questions is where most persistent infections live.

The signature problem

Signatures only match known things. New malware has no signature until somebody finds it and writes one, and the campaigns that matter rotate their code specifically to stay ahead of that. Obfuscation makes it worse, since the same functional backdoor can be encoded a thousand different ways and each looks different to a matcher.

Small backdoors are harder still. A few dozen characters that take a parameter from a request and execute it is fully functional and too generic to signature reliably — write a rule broad enough to catch it and you flag legitimate code across millions of sites. My guide on obfuscated code covers what these look like in practice.

The database blind spot

This is the big one. Most file scanners do not scan the database at all, and a great deal of modern WordPress malware lives there — injected scripts in wp_options, malicious scheduled tasks stored as a serialized array, spam in post content, and payloads inside plugin settings as covered in my guide on Sign1.

A file scan on a site with a database-resident infection returns clean, accurately, and the site stays infected. That single gap explains most of the cases where people tell me their scanner disagrees with reality.

Everything outside the scan's scope

Scanners look at your WordPress install. Several important hiding places are not in it. Server configuration such as an auto_prepend_file directive loading code before WordPress starts. Payloads stored above the web root. Another site in the same hosting account, as covered in cross-site contamination. A compromised CDN or proxy account modifying responses after they leave your server.

And a stolen credential is not malware at all. Somebody logging in as an administrator with your password leaves nothing for any scanner to find, because nothing malicious is on the system — the abuse is entirely within normal functionality.

Malware that uses legitimate features

The hardest category to detect is code that does nothing forbidden. A must-use plugin is a supported WordPress feature. A scheduled event is a supported feature. A plugin setting containing custom HTML is a supported feature. Used maliciously, each provides persistence — and a scanner cannot flag them on principle without flagging every legitimate use across the web.

This is why mu-plugins backdoors survive cleanups that feel exhaustive. There is nothing anomalous to detect at the structural level; the anomaly is that you did not put it there, and only you know that.

Using scanners well

None of this makes them worthless — they are excellent at what they do and I use them. Run them as a first pass, treat every finding seriously, and treat a clean result as one piece of evidence rather than a verdict. A scan that finds something has told you something; a scan that finds nothing has not.

Cover the gap with the checks scanners cannot do: core checksum verification, a look at the database, a look at scheduled tasks and mu-plugins, a review of administrator accounts, and a fetch of your own pages with no login cookie to see what visitors actually get. And if the behaviour persists while everything reports clean, that is precisely the situation my malware removal service exists for.

Common questions

Why does my scanner say clean when the site is clearly infected?

Most likely the payload is in the database, which file scanners do not read. It could also be obfuscated beyond signature matching, stored outside the scanned directories, or implemented using legitimate WordPress features that cannot be flagged on sight. A clean file scan means your files are clean and nothing more.

Are paid scanners better than free ones?

Somewhat — usually larger signature databases, more frequent updates, and sometimes database scanning. But the structural limitations are the same for all of them: signatures only match known code, and a scanner cannot know which files you intended to have. Paying more narrows the gap without closing it.

Should I stop using security plugins then?

No. They catch a great deal, they provide file integrity monitoring that is genuinely valuable, and they alert you to changes you would otherwise miss. Use them as one input among several rather than as the definitive answer to whether your site is clean.

What can I check that a scanner cannot?

Whether files should exist at all — you know what you installed and it does not. Also the database, scheduled tasks, the mu-plugins folder, your administrator account list, PHP configuration files, and what your pages actually serve to a visitor with no login cookie.

How do I know when the site is genuinely clean?

By verifying behaviour rather than trusting a report. Fetch your pages as an outsider would, confirm what Google is being served through URL inspection, check the database and scheduled tasks, and then watch for a few weeks. Persistence reveals itself over time, which a point-in-time scan cannot capture.