How to Scan WordPress for Malware (and Read the Results)

To scan WordPress for malware properly you need three checks, not one: verify core, plugin and theme files against their official copies, pattern-scan everything that cannot be verified, and inspect the database for injected content. Then you read the evidence for each finding and act in order: quarantine, repair, close the entry point. This guide covers the whole loop, including how to tell a real finding from a false alarm.

Check 1: verify files against WordPress.org

This is the strongest check and the one to run first. WordPress publishes checksums for every core release, and every plugin and theme in the WordPress.org directory has a known package for each version. A scanner downloads those checksums and compares them against your files.

The result is binary and trustworthy. A core file that matches is clean. A file that does not match has been changed, whether by an attacker, by a developer, or by a badly behaved plugin. Files that exist in your install but not in the official package are flagged too, which is how extra PHP files dropped into a plugin folder get caught.

Premium plugins and custom themes have no official copy. For those, a scanner can only record a baseline when you first scan and report what changed later. That tells you about changes; it does not prove the baseline was clean.

Check 2: pattern scan the rest

Verification cannot cover custom code, premium plugins or the uploads folder. Pattern scanning fills the gap. It looks for the shapes malware takes:

• Backdoors and webshells. Code that passes request input into execution, such as eval or system calls fed from a URL parameter.
• Obfuscation. Long base64 strings, character-code arrays and string reversal used to hide what a script does.
• Remote fetches written to disk. Code that downloads content and saves it as a file is how many infections refresh themselves.
• PHP in the uploads folder. The uploads directory should contain images and documents. A PHP file there, or a file named .jpg that starts with a PHP tag, is almost never legitimate.
• Rogue administrators. Admin users you did not create, often with no display name.

Pattern checks produce false positives by nature. A minifier uses base64; a page builder evaluates templates. That is why the next step matters.

Check 3: inspect the database

A clean file system with an infected database is common. Attackers inject into:

• Post and page content: hidden iframes, script tags, invisible spam links
• Widgets and options: a script in a text widget or in a theme option loads on every page
• User metadata and revisions: a quiet place to stash code
• wp-config.php, .htaccess and .user.ini: not database, but configuration that changes behaviour site-wide

A scanner should walk options, posts, revisions and metadata looking for script tags, iframes and encoded strings, and check those configuration files for suspicious directives.

DevDome Malware Scanner runs all three checks: checksum verification for core and WordPress.org packages, PHP behaviour and disguised-upload analysis, and database and configuration inspection. Scans run in batches of about eight seconds per request so the site stays responsive, and scheduled scans run daily or weekly through WordPress cron. Scanning, quarantine and eligible repairs need no account; a free account adds a larger signature set. We make it, so weigh that; the three-check structure is what to look for in any scanner.

How to read the results

Do not act on a count. Open each finding and ask three questions:

What exactly was flagged? A good scanner shows the file, the line or pattern, and the reason. “Modified core file wp-includes/class-wp.php, differs from 6.6 checksum” is actionable. “Suspicious” with nothing else is not.

Could this be legitimate? A premium plugin’s licence check, a caching plugin writing files, a developer’s custom snippet. If the flagged code is in a plugin you installed on purpose and the pattern is explainable, mark it reviewed and move on.

What is the blast radius? A modified core file affects every page. A PHP file in uploads is an entry point. A spam link in one old post is ugly but contained. Fix in that order.

Act: quarantine, repair, never delete blind

Quarantine moves a file where it cannot execute, keeping a copy. If the site breaks, restore it and look again. This is the safe default for anything you are not sure about.

Repair replaces modified core, plugin or theme files from WordPress.org with clean official copies. Only official packages can be repaired this way; for premium code, restore from a backup or the vendor’s download.

Delete only what you have identified with certainty: a rogue admin, a PHP file in uploads, a plugin you never installed.

After acting, clear every cache and rescan. Then find the entry point: an outdated plugin, a weak password, a compromised computer. A scan without that step is a temporary fix.

Scanning a large site without taking it down

A full scan of a big site walks tens of thousands of files and millions of database rows, and done naively it competes with visitors for the same CPU. The approach that works is batching: the scanner processes files for a few seconds per request, stops, and resumes on the next request, so no single run holds the server. The default of eight seconds per batch keeps the admin responsive and lets the scan finish over a few minutes rather than in one blocking pass. For the scheduled scans, pick a quiet hour in your site’s timezone, and if the host is very small, weekly rather than daily. A scan that completes slowly and reliably is better than one that times out halfway every night.

Make it routine

Schedule a weekly scan and read the summary when it arrives. Most weeks there is nothing. The week there is something, you will have caught it in days instead of discovering it from a Google warning months later. Pair it with an activity log so that when the scanner finds a change, the log can tell you who or what made it.