Auditing a WordPress Site from the Outside: Detecting Outdated Plugins and Themes

Most WordPress compromises do not start with core. They start with one outdated plugin whose vulnerability is public, whose exploit is automated, and whose presence on your site is advertised by the site itself. An external plugin audit answers the question an owner often cannot: what is this site actually running, and is any of it stale?

Where versions leak

Despite years of advice, WordPress installations still expose their inventory in predictable places:

• Stylesheet and script URLs: /wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.9.3 — the plugin slug and version sit in the query string, viewable in any page source.
• Generator meta tag: <meta name="generator" content="WordPress 6.4.2"> reveals core version unless the theme strips it.
• RSS and Atom feeds: <generator> elements carry a core version.
• REST API: /wp-json/ returns routes that name active plugins, and /wp-json/wp/v2/users may enumerate usernames unless disabled.
• Readme and changelog files: /wp-content/plugins/PLUGIN-SLUG/readme.txt frequently remains readable and states the version outright.

Why an old plugin is a live risk, not a hygiene note

WordPress vulnerabilities are disclosed with the affected version range attached. Attack tooling does not check “is this site vulnerable?” subtly — it requests the exact paths and parameters involved. An outdated slider plugin with a known unauthenticated file-upload flaw gets exploited within days of disclosure, at fleet scale. The gap between “version 4.1 is current” and “version 2.8 is installed” is the entire attack window.

Remediation

1. Update the flagged plugins and themes, ideally on staging first, and re-audit to confirm versions moved.
2. Remove plugins that are inactive or unmaintained — “inactive” plugins still execute their loadable files if referenced, and still expose versions.
3. Replace abandoned plugins with maintained equivalents; check the plugin directory entry for last-updated date before installing anything.
4. Reduce leakage: remove the generator tag, disable XML-RPC if unused, restrict REST user enumeration, and block direct access to readme files.
5. Keep automatic minor updates on for core, and schedule a monthly external audit so drift is caught at one month, not one year.

Audit frequency is the real differentiator between sites that survive an ecosystem where dozens of plugin vulnerabilities are disclosed weekly and sites that do not. The WordPress plugin audit tool performs this external fingerprinting automatically — it fetches the site, extracts plugin and theme slugs with their versions from markup and feeds, and compares each against the wordpress.org directory to flag what is outdated or unknown, producing the checklist an owner can hand to whoever maintains the site.

Limits of external auditing

Be honest about what outside detection cannot see. Plugins that load assets only for logged-in users are invisible from outside; versions can be deliberately obscured (some security plugins strip query-string versions); and premium plugins that are not listed on wordpress.org cannot be checked for staleness automatically — those need a manual review against the vendor’s changelog. An external audit is therefore a screening pass that tells you where to look, not a substitute for an authenticated inventory from inside wp-admin, which takes five minutes and lists everything, visible or not. Run both: the external pass monthly, the internal inventory whenever someone changes the site.