# Vulnerability Scanner — what each finding means

> GuardPress vulnerability scanner findings explained: CVE matches with CVSS scores, CISA KEV references, closed plugins, abandoned plugins and what to do.

- Canonical: <https://royalplugins.com/support/guardpress/outdated-software-check-explained/>
- HTML version: <https://royalplugins.com/support/guardpress/outdated-software-check-explained/>

---

The GuardPress Pro vulnerability scanner returns findings across several categories at four severity levels: CVE matches from Wordfence Intelligence Production tier, CISA Known Exploited Vulnerabilities cross-references, plugin-closed alerts from WordPress.org, pending updates, abandoned plugins, and hardening misconfigurations. This is the reference for what each finding actually means, the action to take, and when a finding is safe to ignore.

What’s new in 1.6.46

The scanner now enriches findings with real CVE IDs and CVSS scores sourced from Wordfence Intelligence Production tier, and cross-references every CVE against the CISA Known Exploited Vulnerabilities catalog. Actively-exploited vulnerabilities carry a red pill and jump the priority queue. A new plugin-closed watcher also alerts when WordPress.org closes a plugin you have installed.

Data flows through the Royal Plugins vulnerability intelligence proxy, so there are no API keys for you to manage. In your admin the module currently sits under **GuardPress → Outdated Software**; the admin label follows in a subsequent release.

## Severity Levels

Every finding GuardPress reports has one of four severity labels. Understanding what each means makes the rest of this reference much easier to navigate:

- Critical — act today. The finding represents a high-likelihood, high-impact security gap with a clear remediation path.
- High — act this week. Serious gap, but not actively under-attack-right-now urgent.
- Medium — act this month. Hardening recommendation or moderate-impact gap.
- Low — nice-to-have. Informational findings that surface for awareness but don’t demand action.

CVE findings use real CVSS scores

When a finding is CVE-tracked, severity comes from the actual CVSS score: **Critical ≥ 9.0**, **High 7.0–8.9**, **Medium 4.0–6.9**, **Low < 4.0**. Any CVE that also sits on the CISA KEV catalog is automatically promoted to Critical regardless of CVSS. Non-CVE findings (abandoned plugins, hardening misconfigurations, legacy artifacts) get a GuardPress heuristic ranking.

## The Finding Types

GuardPress runs several sub-checks per scan. Each finding in your results came from exactly one of these.

#### Critical / High / Medium / Low CVE match on an installed plugin, theme, or core

One of your installed plugins, themes, or the WordPress core version matches an entry in the Wordfence Intelligence Production tier CVE database. The finding carries the CVE ID, CVSS score, affected version range, and remediation guidance.

##### What it means

Someone catalogued a vulnerability in this specific version of the software you have installed. The CVE ID lets you look up the technical details at the [CVE Program](https://www.cve.org/) or in the [Wordfence Threat Intelligence catalog](https://www.wordfence.com/threat-intel/). The CVSS score is the standard industry-severity rating for the vulnerability; anything ≥ 7.0 is worth acting on within a week.

##### Action

Update to the patched version. The finding shows the affected version range and the version that patched the vulnerability. If the plugin has no patched version yet (rare but happens), the finding notes that too, along with any recommended mitigations. For High and Critical CVEs on plugins you can’t update immediately, consider deactivating temporarily until you can.

#### Critical CVE cross-referenced against CISA KEV

A CVE match on your site also sits on the CISA Known Exploited Vulnerabilities catalog. The finding carries a red KEV pill.

##### What it means

CISA maintains the [Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) as an authoritative list of CVEs with credible evidence of active exploitation in the wild. A KEV match is not theoretical, since someone is actively running scans and exploits against this vulnerability right now. Under CISA’s BOD 22-01, federal agencies are required to patch KEV vulnerabilities within specific timelines; while that’s not binding for private sites, it’s a strong signal that this is the highest-priority finding on your list.

##### Action

Patch today. If a patched version exists, update immediately. If not, deactivate the affected plugin or theme until the vendor ships a fix. Alert emails for KEV matches carry a `[CRITICAL - CISA KEV]` subject prefix so they don’t get lost in the normal alert stream.

#### High Plugin closed on WordPress.org

A plugin you have installed was closed on the WordPress.org repository. The finding includes the plugin name, installed version, and closure reason if WP.org disclosed one.

##### What it means

WordPress.org closes plugins when there is a security concern, a maintenance failure, or a policy violation. Closure reasons are often *not disclosed publicly*, so a closed status is a strong signal that a security team decided this plugin should not be running on your site until the issue is resolved. The plugin still works on your site (WP.org closure doesn’t auto-deactivate installed plugins), but it will no longer receive updates and cannot be reinstalled from the repository.

##### Action

Review the plugin’s WordPress.org page (linked in the finding) and its support forum for context. Search for a maintained alternative and migrate. If the plugin is critical and no alternative exists, contact the plugin author directly to see what the closure was about and whether a fix is coming. Do not simply ignore — a closed status is one of the strongest security signals WordPress.org publishes.

#### Critical WordPress core update available

A new minor or major version of WordPress is available and not installed.

##### What it means

WordPress security releases (minor versions like 6.4.1 → 6.4.2) contain patches for vulnerabilities disclosed since the last release. Major versions (6.4 → 6.5) bundle security fixes alongside feature changes. Running outdated core is the single highest-impact security gap on most sites.

##### Action

Update WordPress from **WP Admin → Dashboard → Updates**. Take a backup first ([SiteVault Pro](https://royalplugins.com/sitevault/) has one-click), then run the update. Test the site afterwards — core updates rarely break things, but theme or plugin compatibility issues are possible on major version jumps.

#### High / Medium / Low Plugin update available

An active plugin has an update available on WordPress.org or via its own update channel.

##### What it means

The plugin’s author has released a newer version. Severity is assigned by version distance:

- High a major version behind (e.g. `1.x` → `2.x`) or two-plus minor versions behind (e.g. `1.2.x` → `1.4.x`)
- Medium one minor version behind (e.g. `1.2.x` → `1.3.x`)
- Low patch-only difference (e.g. `1.2.3` → `1.2.4`)

The finding doesn’t mean the installed version is known-vulnerable — only that it’s older than the current release.

##### Action

Update the plugin from **WP Admin → Plugins**. For HIGH severity, treat as urgent (the longer you sit behind, the higher the chance one of the missed releases contained a security fix). For LOW, batch with your normal update cadence.

#### High / Medium Theme update available

Same as plugin updates but for the active theme.

##### What it means and action

Same logic as plugin updates. Update via **WP Admin → Appearance → Themes**. Themes update less frequently than plugins, so an available theme update is more likely to contain meaningful fixes.

#### Low / Medium Plugin abandoned (2+ years no update)

An active plugin’s WP.org listing shows no update in over 2 years.

##### What it means

The plugin author appears to have stopped maintaining the plugin. New WordPress versions, new PHP versions, and newly-disclosed vulnerabilities in shared libraries won’t get patched. The plugin still works today but is decaying.

##### Action

Find an alternative and migrate. Search the WP.org Plugin Directory for similar plugins, or check the Royal Plugins directory for actively-maintained equivalents. Don’t panic-remove the plugin today — abandoned doesn’t mean compromised. But plan to switch within the next few months. If the plugin is critical to your business and there’s no alternative, contact the author through their WP.org page to see if they’ll resume maintenance.

##### Important: only flagged for ACTIVE plugins on WP.org

Pre-1.6.16, the abandoned-plugin check had several false-positive sources: it flagged inactive plugins (admins keep deactivated plugins around for testing — not a security risk), it flagged plugins not on WP.org (premium plugins, custom plugins — can’t check abandoned status without a WP.org listing), and it flagged plugins with an `Update URI` header pointing elsewhere (WP 5.8+ standard for plugins that update from their own server). 1.6.16 fixed all three: the abandoned check now only runs against plugins that are (a) active, (b) hosted on WP.org, (c) without an `Update URI` header. If you saw alarming abandoned-plugin findings before 1.6.16 that you couldn’t resolve, update GuardPress and re-scan — many of them will disappear.

#### High Debug log exposed

The file `wp-content/debug.log` exists, is non-empty, and may be publicly accessible.

##### What it means

WordPress writes PHP errors and notices to `debug.log` when `WP_DEBUG_LOG` is enabled. The file isn’t protected by default on most hosting setups, so anyone who knows or guesses the path can read it from a browser. Debug logs frequently contain database queries, file paths, plugin internals, and occasionally secrets — useful reconnaissance for an attacker.

##### Action

1. Delete the existing `debug.log` — it’s a snapshot of past errors and isn’t needed for production
2. If you don’t need debug logging at all (production sites typically don’t), set `WP_DEBUG_LOG` to `false` in `wp-config.php`
3. If you need debug logging (active troubleshooting), redirect the log outside the web root: `define( 'WP_DEBUG_LOG', '/path/outside/webroot/wp-debug.log' );`
4. Alternatively, add a `.htaccess` rule in `wp-content/` to deny access to `.log` files: `<FilesMatch "\.log$"> Require all denied </FilesMatch>`

#### High / Medium / Low Security misconfiguration

A bucket of related checks on WordPress configuration choices that affect attack surface.

##### What each looks for

- **Admin username is “admin” or “administrator”** — HIGH. Default usernames give attackers half the credential pair for free. Create a new admin account with a non-default username, then delete or demote the old one.
- **WP\_DEBUG is enabled in production** — MEDIUM. `WP_DEBUG` set to true causes PHP notices and warnings to print to the page, leaking file paths and database queries to visitors. Set to `false` in `wp-config.php` for production.
- **DISALLOW\_FILE\_EDIT is not set** — MEDIUM. WordPress’s built-in plugin / theme file editor lets any admin (or anyone who compromises an admin account) write arbitrary PHP to the server. Add `define( 'DISALLOW_FILE_EDIT', true );` to `wp-config.php`.
- **Site not served over HTTPS** — HIGH. Plaintext HTTP exposes everything — admin sessions, comments, login forms. Install a free Let’s Encrypt certificate via your host’s control panel and force HTTPS site-wide.
- **User enumeration is possible** — LOW. Visiting `?author=1`, `?author=2`, etc. on a fresh WordPress install leaks the corresponding username via the redirect to the author archive. GuardPress’s hardening module can block this; turn it on under **GuardPress → Settings → Hardening**.

##### Action

Address each finding using the steps above. Most are one-line changes to `wp-config.php` or a toggle in WordPress / GuardPress settings.

#### High / Medium PHP version is outdated

The server is running PHP 7.4 or earlier.

##### What it means

PHP 7.4 and earlier no longer receive security updates from the PHP project — `php.net` stopped releasing 7.x patches in November 2022. Sites running 7.x are accumulating unpatched vulnerabilities at the language level. Modern WordPress (6.0+) recommends PHP 8.0+; many newer plugins refuse to run on 7.x.

##### Action

Upgrade PHP through your hosting control panel. Most managed hosts (SiteGround, Kinsta, WP Engine, Cloudways, etc.) have a one-click PHP version switcher. Shared hosts (Bluehost, HostGator, etc.) usually offer PHP version selection in cPanel under “Select PHP Version.” **Take a backup first**; while modern WordPress core is PHP 8 compatible, some older plugins and themes may have surprises. Test on a staging site first if you have one.

## Findings That Used to Be Wrong (Pre-1.6.16)

If you’re looking at a finding that doesn’t make sense — especially around the “abandoned plugin” or “not listed on WordPress.org” messages — check your GuardPress version. Multiple false-positive sources were fixed in 1.6.16:

- **Folder-name slug guessing** — Pre-1.6.16, the scanner used `dirname($plugin_file)` as the WP.org slug to look up. For plugins whose folder name doesn’t match the canonical .org slug (e.g. RoyalComply ships as `royal-comply/royalcomply.php` but its .org slug is `royal-comply`), the scanner would query api.wordpress.org for the wrong slug, get “not found”, and flag a current properly-listed plugin as “may have been removed for security issues.” 1.6.16 now reads WP’s `update_plugins` site transient as the source of truth.
- **Premium / custom plugins flagged alarmingly** — Pre-1.6.16 description copy implied these were dangerous (“may have been removed for security issues”). 1.6.16 changed the copy to be accurate: “no known update source — not on WordPress.org and no managed update channel detected. Normal for custom, internal, or premium plugins; review if unfamiliar.”
- **Update URI header ignored** — Pre-1.6.16, plugins that declared an alternate update source via the WordPress 5.8+ `Update URI` header were still flagged as abandoned / not-on-org. 1.6.16 skips those plugins entirely.
- **Inactive plugins surfaced** — Pre-1.6.16 inactive plugins appeared in the report. 1.6.16 skips them — an inactive plugin isn’t actively running and doesn’t need urgency.

If your old scan results contained findings that match these patterns, update GuardPress to the latest version and re-scan from **GuardPress → Outdated Software → Run Scan**. Many of the noisy findings will disappear.

## When Findings Keep Coming Back After You Acted

### You updated the plugin but it still shows as outdated

WordPress caches its “available updates” data in a 12-hour transient. The GuardPress 1.6.20 fix made *that* transient invalidate correctly on force-refresh, but the underlying scan still runs against whatever WP’s transient currently says. Force a refresh: **WP Admin → Dashboard → Updates → Check Again**, wait 30 seconds, then re-run the scan.

### You set DISALLOW\_FILE\_EDIT but it’s still flagged

Make sure the constant is defined as `true` (not a string, not a 1). The exact line: `define( 'DISALLOW_FILE_EDIT', true );`. Place it ABOVE the `/* That’s all, stop editing! */` comment in `wp-config.php`. If you added the line correctly and it’s still flagged, check there’s no second `wp-config.php` (some hosts symlink one to another) and that the constant isn’t being overridden later in the file.

### You deleted debug.log but it keeps regenerating

That means `WP_DEBUG_LOG` is still enabled and active errors are being written to the log. Either disable `WP_DEBUG_LOG` in `wp-config.php`, or fix the underlying PHP errors (open the log, identify what’s being logged, fix the source). Deleting the file alone doesn’t solve the leak — the new file will appear within minutes.

## Still Stuck? Email Priority Support

If a finding doesn’t match anything in this reference, or you’re not sure whether to act on a specific finding for your situation:

Email **[support@royalplugins.com](mailto:support@royalplugins.com)** with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours.

#### Information to include in your email

- **GuardPress version** from **WP Admin → Plugins** (1.6.16+ ideally for clean abandoned-plugin detection)
- **WordPress version** from **WP Admin → Updates**
- **The exact finding name and severity** from **GuardPress → Outdated Software**
- **The finding description text** as it appears in the report (so we can tell which sub-check it came from)
- **What you’ve already tried** — if you took an action and the finding persists
- **Your hosting setup** — managed (SiteGround, Kinsta, WP Engine) vs shared (Bluehost, HostGator) vs VPS — matters for some hardening recommendations

Related GuardPress topics

If a vulnerability scanner finding led you to a bigger issue:

- [**Quieting Security Alert Email Flood**](https://royalplugins.com/support/guardpress/quieting-security-alert-emails/) — if the vulnerability scanner is emailing you the same finding every day
- [**File Integrity Alert Investigation**](https://royalplugins.com/support/guardpress/file-integrity-alert-investigation/) — if updating a plugin triggered file-monitor alerts
- [**Vulnerability Scanner overview**](https://royalplugins.com/support/guardpress/#outdated-software-check) — the short feature description on the main GuardPress support page
- [**Vulnerability Scanner feature page**](https://royalplugins.com/guardpress/features/vulnerability-scanner/) — the plugin marketing page with CVE + KEV details and FAQ
- [**SiteVault Pro**](https://royalplugins.com/sitevault/) — for backups before running updates surfaced by the scanner

[Back to GuardPress Support](https://royalplugins.com/support/guardpress/)
[GuardPress Plugin Page](https://royalplugins.com/guardpress/)