WordPress Version Exposure Scanner
Passively inspect what WordPress core, theme, and plugin version numbers are publicly exposed in your site's HTML, and flag an outdated WordPress core release.
WordPress Security Reconnaissance Explained
📌 On this page
1. Version reconnaissance vs. vulnerability scanning
These are two genuinely different activities that are easy to conflate. Version reconnaissance (what this tool does) answers "what software and version numbers are visible from the outside?" Vulnerability scanning answers "does any of that detected software have a known, documented security flaw?" — which requires cross-referencing detected versions against a maintained database of disclosed vulnerabilities (CVEs), something this tool deliberately does not attempt, since maintaining an accurate, current vulnerability database is a significant ongoing effort distinct from HTML parsing.
2. How version numbers leak through normal WordPress behavior
WordPress core, by default, adds a meta generator tag announcing its version to every page's HTML head — this is the single most reliable signal for detecting core version. Theme and plugin assets (CSS and JS files) are typically enqueued with a version query parameter (style.css?ver=1.4.2) used for cache-busting when the developer releases an update — this incidentally exposes the exact installed version to anyone who views the page source, since it's plain text in publicly served HTML.
3. How to hide version exposure
Remove the core generator tag with remove_action('wp_head', 'wp_generator') in functions.php. Removing plugin and theme version query strings is more involved since it requires filtering the style_loader_src and script_loader_src hooks to strip the ver= parameter — some security plugins offer this as a built-in option rather than requiring custom code. Note that stripping version parameters can occasionally interfere with browser cache invalidation when you update a plugin, so test carefully after making this change.
4. Getting real vulnerability scanning
WPScan maintains one of the most comprehensive WordPress-specific vulnerability databases and offers both a command-line tool and an API that cross-references detected plugin/theme versions against thousands of documented CVEs. Security plugins like Wordfence and Sucuri include their own maintained vulnerability feeds and will actively alert you when an installed plugin version has a disclosed security issue — these are the right tools to reach for when you need actual vulnerability matching rather than version reconnaissance.
5. Why updates still matter more than hiding
Hiding version numbers is a defense-in-depth measure against opportunistic, automated bulk scanning — it is not a substitute for actually keeping WordPress core, themes, and plugins updated. A targeted attacker who specifically wants into your site can often determine your software versions through other means (behavioral fingerprinting, specific file presence checks, error message differences) even with version strings hidden. The single highest-leverage security practice remains applying updates promptly, since that's what actually closes a disclosed vulnerability rather than merely obscuring which version you're running.
Frequently Asked Questions
How does this WordPress vulnerability scanner work?
This tool performs a 100% passive inspection of publicly visible HTML headers, meta generator tags, and script version parameters (e.g. style.css?ver=6.2). It does not execute active penetration probes, exploit payloads, or brute-force tests.
Why is exposing the WordPress version number in <meta name="generator"> a risk?
Automated internet-wide botnets search for known vulnerable version numbers (e.g. older unpatched WordPress 5.x releases) to target automated exploit scripts. Removing the version tag obscures this information from bulk scanners.
How can I remove the WordPress version generator tag?
Add the following line to your child theme's functions.php file or a code snippet plugin: remove_action('wp_head', 'wp_generator');
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
Does this tool check my plugins and themes against known vulnerabilities (CVEs)?
No. This scanner detects which theme and plugin version numbers are publicly exposed in your page's HTML, but it does not cross-reference those versions against the WPScan Vulnerability Database, the National Vulnerability Database, or any other CVE source. A "Version Detected" result means exactly that — a version number was found, not that it was checked for known security flaws. For genuine vulnerability matching, use a dedicated tool like WPScan or a security plugin with an integrated vulnerability database (Wordfence, Sucuri, and others maintain their own).
What does this tool actually check, then?
Three things: whether your WordPress core version is publicly exposed via the meta generator tag, whether your detected core version is a reasonably current release, and an inventory of which theme/plugin slugs and version numbers are visible in your page's public HTML. This is useful reconnaissance-surface reduction — hiding version numbers makes automated bulk-scanning botnets' job harder — but it is not a substitute for keeping software updated or for a real vulnerability audit.
If this doesn't check for real vulnerabilities, why does it matter that version numbers are exposed?
Automated attack botnets frequently scan the web in bulk for specific known-vulnerable version strings rather than targeting sites individually — a publicly exposed version number makes your site trivially matchable against these bulk scans. Hiding the version doesn't fix an underlying vulnerability, but it does remove your site from the pool of sites a bot can identify as a likely target without any real work, which meaningfully reduces opportunistic (as opposed to targeted) attack risk.