Version leaks: why telling the world what you run is a bad idea

The short version

What is being leaked and where

• Server header — the web server software and often its exact version and operating system. Sent on every response by default by Apache and some others.
• X-Powered-By header — PHP announces itself and its version here by default; frameworks such as ASP.NET and Express do too.
• Generator meta tags — WordPress adds <meta name="generator" content="WordPress 6.x"> to every page unless told not to; many themes and page builders add their own.
• Default error pages — the standard Apache or nginx 404 page includes a signature line with the version. Framework error pages can show far more, including file paths and stack traces (see our guide on exposed files and debug mode).
• Readme and changelog files — readme.html in a WordPress root, CHANGELOG.md in a plugin folder, each stating the exact version.
• Versioned asset URLs — style.css?ver=6.4.2 tells the reader the WordPress version; plugin asset paths reveal plugin names and versions.

Why it matters, and why it is only "low"

Attackers, and the bots they run, work from lists: "sites running PHP below 8.2.35", "sites on Apache 2.4.49". If your server announces its version, you are matched against those lists instantly and precisely. If it does not, the attacker has to probe and guess, which is slower, noisier and less reliable — and bots on a budget move on to easier targets.

That said, this is obscurity, not security. Hiding the version does not fix a vulnerable version; a determined attacker can often fingerprint software by its behaviour anyway. That is why we rate it low. The real fix for a vulnerable version is updating it. Hiding the banner is the cheap extra that makes you a less obvious target while you do.

The exception that raises the severity: when the leaked version is *known to be vulnerable*. Then the banner is not just a hint, it is a confirmation, and we report it as a version vulnerability instead.

How to turn it off

PHP's X-Powered-By: in php.ini (or a .user.ini in your web root on shared hosting) set expose_php = Off. On cPanel, the "MultiPHP INI Editor" exposes this as a toggle.

Apache Server header: full removal needs server-level config (ServerTokens Prod and ServerSignature Off in the main config), which shared hosting customers cannot change — but ServerTokens Prod reduces it to just Apache with no version, and many hosts already set this. On LiteSpeed shared hosting the header is typically just LiteSpeed with no version, which is fine.

nginx: server_tokens off; in the http block removes the version.

Behind Cloudflare: Cloudflare replaces the Server header with its own (cloudflare), which hides your origin server's banner for free. It does not remove X-Powered-By unless you add a Transform Rule to strip it.

WordPress generator tag: add remove_action('wp_head', 'wp_generator'); to your theme's functions.php or a small plugin; most security plugins have a tick-box for it. Delete readme.html and license.txt from the root after each update, or block them in .htaccess. Several security plugins also strip the ?ver= query strings from assets.

# .htaccess — remove PHP banner and block readme files
Header always unset X-Powered-By
<FilesMatch "^(readme\.html|license\.txt|CHANGELOG\.md)$">
  Require all denied
</FilesMatch>

What VigilScan checks

We read the Server and X-Powered-By headers from your homepage, look for generator tags in the page, and check for the usual readme files. We report exactly what we saw. Where a version is shown, we cross-reference it against known vulnerabilities and, if it matches, raise it as an out-of-date software finding instead of a leak.

Common questions