Malware Scanning: What the Tools Catch and What They Miss
“The scanner says the site is clean” is one of the least reliable statements in WordPress support. Scanners are useful, but each type sees only part of a site, and the gaps between them are exactly where persistent infections live.
The short version
- Signature scanners catch known code and miss novel obfuscation.
- Integrity checks catch modified core files and miss everything in your theme.
- Remote scanners see only what a visitor sees, which cloaked malware hides from.
- A diff against official files beats every signature database.
The three types, and their blind spots
| Type | Catches | Misses |
|---|---|---|
| Signature scanner | Known malware patterns in files | Novel obfuscation; anything in the database |
| Integrity check | Modified core and plugin files | Your own theme; uploads; database injections |
| Remote scanner | Visible injected content and redirects | Anything cloaked from normal visitors; server-side only code |
| Database scanner | Injected scripts and spam links in content | File-based backdoors |
Why cloaking defeats remote scans
Sophisticated infections decide what to serve based on who is asking. A normal visitor sees the real site. A search engine crawler sees spam. A visitor arriving from a search result gets redirected. A logged-in administrator sees nothing unusual at all.
A remote scanner requesting your home page as an ordinary browser is in the one category designed to see nothing. Test as a crawler instead:
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -L https://example.com | head -50
# and with a search referrer
curl -A "Mozilla/5.0" -e "https://www.google.com/" -L https://example.com | head -50
If those outputs differ meaningfully from what you see in a browser, you have found something.
The check that works best
Diffing against official files is more reliable than any signature database, because it does not depend on the malware being previously known. Core and plugin files should be byte-identical to their official releases.
# verify core against the official checksums
wp core verify-checksums
# and plugins from the repository
wp plugin verify-checksums --all
What this cannot check is your own theme and your uploads, which is precisely where injections tend to go. For the theme, version control is the equivalent — a diff against your repository shows anything added.
A layered routine
- Checksum verification for core and repository plugins, weekly and automated.
- File-integrity monitoring that alerts on any PHP file changing outside a deployment.
- One signature scanner, run monthly, treated as a second opinion rather than the answer.
- A crawler-perspective fetch, monthly, to catch cloaking.
- Search Console security notices, which sometimes find things first.
Watch out
Scanners that offer automatic removal can damage a site by deleting legitimate customisations they do not recognise. Review what a scanner proposes to remove before letting it act, especially in your own theme.
When a scan comes back clean but you are unconvinced
- Check
wp-content/mu-plugins, which loads silently and is frequently missed. - Check scheduled events for tasks you did not create.
- Check the user table for administrators you did not create.
- Check
wp_optionsfor unexpected autoloaded entries. - Compare file modification times against your last deployment.
Common questions
Which scanner is best?
None of them individually. Checksum verification plus integrity monitoring catches more than any single signature scanner, and costs nothing.
Is a paid scanner worth it?
Across many sites, the monitoring and alerting is worth paying for. For one site, the free combination above is close in effectiveness.
How often should I scan?
Automated integrity monitoring continuously; a manual review monthly; a full investigation any time behaviour changes unexpectedly.
Sumit
Writes everything on TechMozz.