Scan Results

Every scan ends in a list of findings. Some findings are urgent (a malware signature match in a core file) and some are routine (a plugin has an update available). Reading the results well means triaging quickly: deciding what is real, what to act on, and what to dismiss. This article explains the structure of the results page and how to handle each kind of finding.

In This Article

• Severity levels
• Finding types
• Actions you can take
• Handling false positives
• After a confirmed compromise

Severity levels

Every finding has one of four severities. Use the severity to decide how quickly to investigate, not whether to investigate.

• Critical. Strong indicators of compromise: known malware signatures, unauthorized core-file modifications, suspicious files where they should not exist. Investigate immediately.
• High. Issues that should be examined as soon as possible. They may not be active threats yet but they create real exposure (vulnerable component versions, weak admin passwords, public configuration leaks).
• Medium. Worth knowing about. Acting on these is good hygiene; not acting is unlikely to be immediately dangerous (suspicious-looking content, outdated components without a known exploit).
• Low. Informational. Often safe to ignore but worth a glance.

The default sort puts critical findings at the top. Resist the temptation to filter only on critical — high- and medium-severity issues are where most real compromises hide, because malware authors specifically design their payloads to look like ordinary suspicious content rather than a clear-cut signature match.

Finding types

The plugin groups findings by type so you can see related issues together.

• File integrity. A core, theme, or plugin file does not match what the official repository says it should contain. Read carefully — a single modified core file is one of the strongest compromise indicators on a WordPress site.
• Malware signatures. Pattern-matched malware. The finding tells you the file path and the signature name. Treat as critical.
• Vulnerable component. The installed version of WordPress core, a theme, or a plugin has a known vulnerability. The finding links to the vulnerability detail and the version that fixes it. The fix is usually to update.
• Outdated component. No known vulnerability, but a newer version is available. Useful for staying current; not by itself a sign of compromise.
• Suspicious content. A post, page, or comment contains a payload that looks like spam, a hidden iframe, or obfuscated code. Often a sign that an account or the database has been compromised.
• Configuration issue. Something about the WordPress, server, or plugin configuration that weakens security: directory listing enabled, debug mode on in production, file permissions too loose.
• Public file leak. A file that should not be reachable from the public web is reachable: a backup archive, a database dump, a .env file, a .git directory.
• Weak admin password. An administrator account has a password that matched the dictionary check.

Actions you can take

Each finding has a row of actions. The available actions depend on the finding type.

• View file. Shows the contents of the affected file in a read-only viewer. Safe to use on suspected malware: the file is rendered as text, not executed.
• View differences. For modified-file findings, shows a side-by-side diff between the version you have and the official version.
• Repair file. For files belonging to WordPress core or to a plugin/theme from wordpress.org, replaces your version with the official one. The plugin offers to download a copy of the existing file before repair so you can restore it if the change turns out to be wrong.
• Delete file. Removes the file after a confirmation prompt. The wp-config.php file is exempted because deleting it always breaks the site. Be careful with the bulk “Delete all deletable files” action — on a non-compromised site it can remove legitimate custom code without recovery.
• Ignore. Marks the finding as a known false positive so future scans do not surface it. Use only when you have positively determined the finding is benign.
• Mark as fixed. Hides the finding from the current view. The next scan will re-evaluate; if the underlying issue is gone, the finding stays gone, otherwise it returns. Useful for working through a long results list.

Handling false positives

Sometimes a finding is real but expected — a custom-modified file, a plugin you have decided not to update yet, a deliberate .env.example file that legitimately exists in the public path. Use the Ignore action on such findings to suppress them on future scans.

Do not ignore a finding because investigating it is inconvenient. The ignore list grows over time, and a forgotten entry can hide a real compromise that happens later in a directory you stopped looking at.

After a confirmed compromise

If a critical finding turns out to be a real compromise, do not just delete the affected file and move on. Compromises are rarely a single file; an attacker typically leaves backdoors in multiple locations so they can return after you clean up.

The right next steps are out of scope for this article, but in general:

• Take the site offline (or put it behind maintenance mode) before cleaning, so an attacker who is currently active cannot interfere.
• Force-rotate every administrator password and any active session.
• Run a High Sensitivity scan with all advanced options enabled.
• Compare every modified file against a known-good backup, not just the official repository.
• Audit recent changes: post revisions, user accounts created, options modified.
• Once cleaned, restore from the most recent confirmed-clean backup if you have one. Cleaning in place is harder than restoring.