Outdated Software Check — What Each Finding Means

The GuardPress Outdated Software Check returns findings across six categories at four severity levels. This is the reference for what each finding actually means, the action to take, and when a finding is safe to ignore. If you’re trying to figure out whether to drop everything and fix a HIGH alert or whether your LOW abandoned-plugin finding actually matters, start here.

Note on the name

This feature was renamed from “Vulnerability Scanner” to “Outdated Software Check” in GuardPress 1.6.6 because update-and-config check is a more honest description of what it does — it surfaces missing updates, abandoned plugins, and security misconfigurations. It does not query a CVE database to look up known vulnerabilities by plugin version. Internally the class name, page slug, and option names still reference “vulnerability” for backward compatibility.

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.

Severity is GuardPress’s opinion, not a CVE rating

These severities reflect GuardPress’s heuristic ranking for a typical WordPress site. A finding marked LOW on your site may actually be HIGH-impact in your specific context (e.g. an abandoned plugin that’s critical to your business). Use the labels as a starting point, not the final word.

The Six Finding Types

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

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 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

Delete the existing debug.log — it’s a snapshot of past errors and isn’t needed for production
If you don’t need debug logging at all (production sites typically don’t), set WP_DEBUG_LOG to false in wp-config.php
If you need debug logging (active troubleshooting), redirect the log outside the web root: define( 'WP_DEBUG_LOG', '/path/outside/webroot/wp-debug.log' );
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 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