The fix, in one snippet
remove_action('wp_head', 'wp_generator');Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now looks for four disclosure points on the homepage: a <meta name="generator"> tag (for example WordPress 6.6.2, Drupal 10 (https://www.drupal.org), Joomla! - Open Source Content Management, Hugo 0.125.4, Ghost 5.x), an X-Generator response header (Drupal sets one), a <generator> element in an RSS or Atom feed linked from the page, and well-known HTML comment banners left by plugins (Yoast SEO's "This site is optimized with..." block, for instance). The check fails at low severity when a version number is present; a product name on its own is recorded as informational. WordPress has additional version leaks that get their own check, wordpress-version-disclosure, and platform headers are covered by x-powered-by-disclosure.
Why it matters
The generator tag is one of the first things automated attack tools read. Botnets that exploit CMS vulnerabilities do not scan every site with every exploit; they check the generator string and fire only the ones that match. A site that says WordPress 6.2 is telling them which core CVEs apply and roughly which era of plugins to expect. Removing the string is not a substitute for patching, because fingerprinting by file paths and behaviour still works for anyone who cares to look, so this is rated low. But the disclosure has no benefit to you, it raises your profile in mass scans, and it is a two-line fix. The OWASP Web Security Testing Guide treats framework fingerprinting as a standard reconnaissance step for exactly this reason. Our WordPress scanning guide shows what else an external scan reveals about a CMS.
How to fix it
WordPress, in the theme's functions.php or a small plugin:
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');
add_filter('wpseo_debug_markers', '__return_false'); // Yoast comment bannerHugo, in hugo.toml:
disableHugoGeneratorInject = trueDrupal sends both the meta tag and the X-Generator header; strip the header at the web server. nginx:
proxy_hide_header X-Generator;
fastcgi_hide_header X-Generator;Apache: Header unset X-Generator. Joomla: System > Global Configuration > Site > Site Meta Tags lets you clear the generator, or use the same Header unset approach. Ghost and Gatsby both emit the tag from their default templates; override the head template to drop it. Cloudflare cannot edit the HTML body for you (short of an HTMLRewriter Worker), so fix the source. Then keep the software updated, which is the control that actually matters.
Where this fits
CMS / generator version disclosure is check 5 of 10 that the website vulnerability scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Advertising and tracking endpoints (low), where which of the page's third-party hosts exist to advertise to the visitor or to follow them, matched against the EasyList and EasyPrivacy blocklists that also power our <a href="/ad-blocker">ad blocker</a>. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
CMS / generator version disclosure closes one route in. Immediately below it: Sensitive information in HTML comments, where hTML comments in the page source contain material that looks internal: Credentials, TODO notes, internal hostnames or IP addresses, file paths, or links to unpublished areas of the site; Third-party scripts without Subresource Integrity, where scripts or stylesheets are loaded from third-party hosts without an integrity attribute; Inline event handlers and scripts, where the page relies on inline scripts, on* event-handler attributes or javascript: URLs.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: CMS / generator version disclosure (low severity)
Scanner check id: generator-disclosureThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
