The GuardPress Malware Scanner Explained

The malware scanner walks every PHP file inside WordPress core, active themes, and active plugins, then applies a signature list and a set of behavior heuristics to flag anything that looks like injected code, an obfuscated payload, or a backdoor. This article covers exactly what the scanner is looking for, what actions you can take on each finding, and the expected self-detection behavior that trips up new users.

What gets scanned

The scanner walks every PHP file within these locations:

WordPress core (wp-admin/, wp-includes/, and the top-level PHP files)
All active themes under wp-content/themes/, including the parent theme of a child-theme setup
All active plugins under wp-content/plugins/
The uploads directory for PHP files, since wp-content/uploads/ should never contain executable PHP on a healthy site

Non-PHP files (images, CSS, JS) are excluded from the malware scan because injected malicious behavior in those file types is caught by the firewall on request rather than by scanning. Inactive themes and inactive plugins are also excluded — if they’re not loading, they can’t execute, and if they’re abandoned deadweight, delete them rather than let them sit on disk (see the Pre-Launch Security Checklist).

How detection works

Every file is checked against two detection layers:

Signature matching

A curated list of known-bad code fragments: specific function-call patterns from published webshells, credential-harvest scripts, spam-injection loaders, and cryptomining stubs. Signature matching is fast and precise. When it fires, the finding is almost always a real threat.

Behavior heuristics

Pattern matching for shapes that legitimate WordPress code almost never uses:

Base64-encoded PHP payloads longer than a small threshold. Legitimate code sometimes base64-encodes small pieces of data (a public key, a cached template); a large base64 string followed by eval() is a webshell.
Obfuscation combinations: eval(gzinflate(base64_decode(...))), hex-encoded function names, character-by-character string reassembly. Real code has no reason to make itself unreadable.
Hidden backdoors: conditional access based on a specific header, cookie, or query-string trigger. Legitimate authentication doesn’t use these shapes.
Suspicious PHP function calls in unexpected files: shell_exec, system, passthru, proc_open outside of a scoped admin tool.

Heuristics have more false positives than signatures. Some legitimate plugins (license validators, minifiers, some page-builder cache loaders) use one or two of these shapes for good reasons. The Ignore action exists for exactly this case.

The three post-scan actions

Every finding gets three action buttons on the Malware Scanner page:

Action	What it does	When to use
Quarantine	Moves the file to a locked-down quarantine directory outside the web root. The file is preserved (you can inspect or restore later) but can no longer be executed.	Confirmed malware where you want a forensic copy for review or reporting.
Delete	Removes the file permanently. Irreversible.	Confirmed malware you’ve already investigated and don’t need to keep.
Ignore	Marks the finding as reviewed and known-good. It moves to a collapsible “Ignored findings” section and stops appearing in future scan results. Restore any time with one click.	False positive on a file you’ve verified is legitimate (a vendored library, a known plugin’s obfuscated loader, your own custom code).

Before deleting anything, review the file. False positives on well-known plugins can be resolved by clicking Ignore; deleting a file the plugin depends on breaks the plugin.

Self-detection (expected behavior)

The malware scanner detects its own signatures.

This is not a bug. The scanner ships a signature list, that signature list lives in a PHP file, and the scanner then walks all PHP files, including its own. The self-match is proof that pattern matching is working correctly on your site.

Self-detections are grouped into a separate “Self-detection” section on the Malware Scanner page with a green indicator to distinguish them from real threats. You don’t need to take action on them; they’re expected. If they were missing from the results, that would be the concerning outcome (it would mean the scanner isn’t walking its own files, which would indicate a broken scan configuration).

File Integrity Monitor Explained: the sister module that catches unauthorized changes to files that shouldn’t change, complementing the signature-based scan
Malware Removal Guide: the full incident-response playbook when the scanner confirms real malware
Understanding the Security Dashboard: active threats contribute to the security score