The exact version of your CMS is published on every page
What this check looks for
Your site tells every visitor which version of ‹product› it runs. Anyone can compare that number against the list of known vulnerabilities for it without touching your site again.
Why it matters
Attackers scan for versions, not for sites. Publishing the exact version puts you on the list the moment a vulnerability is announced for it — before you have had a chance to update.
When the check passes, your report says: “The CMS keeps its exact version out of the page”.
What it costs your score
When this check fails it removes 5 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.
It shares the web-security.disclosure family ceiling of 10 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- high
- Status when triggered
- warn
- Deduction
- 5 points
- Family cap
- web-security.disclosure · 10
- Category
- Web security
- Module
- Web technology
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Update ‹product›, then stop publishing its version number.
A published version turns your site into a search result for anyone looking for hosts affected by a newly announced vulnerability.
Update to the current supported release first. Suppressing the banner on an out-of-date install hides the risk from you without reducing it.
Remove the
<meta name="generator">tag, or whatever else in the page publishes the number, in your theme or site configuration. A version in a response header is a separate change, reported separately.Check the same version is not still exposed by asset query strings (
?ver=), a readme file at the site root, or an API endpoint.Turn on automatic updates for security releases if the platform offers them, so the version stays current without you tracking it.
How to confirm it worked
curl -sS https://‹host›/ | grep -i 'name="generator"' — should return nothing
curl -sS https://‹host›/ | grep -oiE '‹product›[ /-]?[0-9]+(\.[0-9]+)+' — should return nothing
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Remediation by platform
// In your theme's functions.php or a small site plugin.
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');<!-- Remove the version, or the whole tag. Keeping the product name without the number is fine. -->
<meta name="generator" content="Example CMS">This removes the generator meta tag and the one in the RSS feeds. It does not change the version query string on enqueued assets; if that matters to you, version your own assets explicitly rather than stripping the parameter, since the parameter is what busts caches on update.
The product name alone tells an attacker nothing they could not learn from the page's behaviour. The number is what maps onto an advisory.
Technical detail
‹detail›
The version was read from ‹source› — part of the page itself, served to every visitor and to every crawler.
This rule covers the **document** only. A version carried in a *response header* — X-Powered-By, X-Generator, Server — is the same exposure through a different channel, and is reported once, by web.security-headers.technology-disclosed and web.security-headers.server-version-disclosed, which is where the fix for a header belongs. Where a platform publishes its version in both places you will see both findings: those are two separate things to remove.
Removing it is not a security control on its own — a determined attacker can often still infer the version from asset paths and behaviour — but it removes you from the *cheap* target list, which is the list that matters: mass exploitation works by matching a published version string against a published advisory.
The order to do this in matters more than the removal does. Update first, then remove the banner. A hidden version on an unpatched install is worse than a visible one, because it hides the problem from you as well.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.