SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Category Security Misconfiguration / Information Exposure
Typical Severity Medium
OWASP A05:2021 – Security Misconfiguration
CWE CWE-200 – Exposure of Sensitive Information to an Unauthorized Actor
Also known as Banner Grabbing, Version Disclosure, Fingerprinting, Software Enumeration
Affected systems Web servers (Apache, Nginx, IIS), application frameworks (PHP, ASP.NET, Express), reverse proxies, load balancers, CMS platforms
Common locations HTTP response headers (Server, X-Powered-By, X-AspNet-Version), HTML comments, error pages, generator meta tags

Overview

Server and software version information disclosure occurs when a web application or its hosting infrastructure reveals the names and exact version numbers of the underlying technologies — such as the web server, programming language runtime, application framework, or operating system — in HTTP response headers, error pages, HTML source, or other observable output. While this information is not itself a vulnerability that can be directly exploited, it significantly reduces the effort required for an attacker to identify applicable CVEs and craft a targeted attack. This issue is classified under CWE-200 and maps to OWASP A05:2021 – Security Misconfiguration.

How it works

Attackers routinely perform passive or active reconnaissance to collect technology fingerprints before attempting exploitation. Version information can be exposed through several channels:

  • HTTP Server header: Web servers such as Apache and Nginx emit a Server header by default (e.g., Server: Apache/2.4.54 (Ubuntu)), disclosing the server product, exact version, and sometimes the host OS.
  • HTTP X-Powered-By header: Application frameworks commonly add this header (e.g., X-Powered-By: PHP/8.1.12 or X-Powered-By: ASP.NET), revealing the runtime and its version.
  • HTTP X-AspNet-Version / X-AspNetMvc-Version headers: ASP.NET applications may emit these headers, disclosing the exact .NET and MVC framework versions.
  • Error and exception pages: Default or verbose error pages (stack traces, framework-branded 404/500 pages) frequently include technology names, library versions, and file paths.
  • HTML meta tags and comments: CMS platforms such as WordPress embed version information in <meta name="generator"> tags; developers sometimes leave version numbers in HTML comments.
  • Static asset paths: Versioned directories or filenames in JavaScript/CSS URLs (e.g., /wp-includes/js/jquery/jquery-3.6.0.min.js) can imply component versions.
  • Cookie attributes: Cookies such as PHPSESSID or ASP.NET_SessionId identify the underlying runtime, even without a version number.

Once an attacker knows the exact component versions, they can cross-reference public vulnerability databases (NVD, Exploit-DB) to identify known, often weaponised, CVEs with matching version ranges and proceed directly to exploitation without any further guesswork.

Business impact

On its own, version disclosure does not grant an attacker access to systems or data. However, it materially lowers the barrier to follow-on attacks:

  • Accelerated exploitation: Publicly known CVEs with readily available exploit code can be applied immediately once the version is confirmed, turning hours of reconnaissance into minutes.
  • Targeted vulnerability scanning: Attackers can narrow automated scans to only the exploits relevant to the disclosed stack, increasing signal-to-noise ratio and evading some detection systems.
  • Supply-chain and component risk: Disclosed library versions in JavaScript or CMS components allow attackers to identify third-party dependency vulnerabilities (e.g., an outdated jQuery version known to have XSS flaws).
  • Compliance implications: PCI DSS Requirement 6.3 and ISO/IEC 27001 controls around information classification may be breached when system internals are unnecessarily exposed to untrusted parties.
  • Reputational risk: Security auditors and pen-testers routinely flag version disclosure in reports; findings in public bug-bounty programmes can attract negative attention.

How to fix it

  1. Suppress the Server header (Apache): Set ServerTokens Prod and ServerSignature Off in httpd.conf or the relevant virtual host configuration. This reduces the header value to just Apache with no version or OS details.
  2. Suppress the Server header (Nginx): Add server_tokens off; in the http, server, or location block of nginx.conf.
  3. Remove X-Powered-By (PHP): Set expose_php = Off in php.ini. This prevents both the X-Powered-By: PHP/x.y.z header and PHP version strings in error output.
  4. Remove X-Powered-By (Node.js / Express): Call app.disable('x-powered-by') or use the helmet middleware, which removes this header automatically.
  5. Remove ASP.NET version headers (IIS): Set <httpRuntime enableVersionHeader="false" /> in Web.config and use URL Rewrite or custom HTTP modules to strip the Server header.
  6. Configure custom error pages: Replace default framework or server error pages with generic, application-branded pages that contain no technology stack details, stack traces, or file paths.
  7. Audit HTML output: Remove <meta name="generator"> tags from CMS themes (or use a plugin that does so), remove version numbers from static asset URLs using cache-busting hashes instead, and scrub version-revealing HTML comments from templates.
  8. Apply defence-in-depth: Regardless of header suppression, keep all server software and dependencies patched to current supported versions. Version hiding reduces reconnaissance value but does not eliminate vulnerability from unpatched software.
  9. Review CDN and reverse proxy layers: Ensure that load balancers, WAFs, and CDN edge nodes do not re-introduce version headers that the origin server has been configured to suppress.
  10. Incorporate into security testing: Add automated checks for version-disclosing headers and error pages to CI/CD pipelines and periodic security assessments. Sensagraph automatically detects version disclosure across HTTP headers, error pages, and HTML metadata.

References

Frequently asked questions

Version disclosure is classified as an information exposure weakness (CWE-200) rather than a directly exploitable vulnerability. It does not grant an attacker access on its own, but it significantly reduces the reconnaissance effort required to identify and exploit real vulnerabilities in the disclosed software versions.

The most common headers are Server (e.g., Apache/2.4.54), X-Powered-By (e.g., PHP/8.1.12 or ASP.NET), and X-AspNet-Version / X-AspNetMvc-Version. Each is emitted by default in many web server and framework configurations and must be explicitly suppressed.

No. Hiding version information is a reconnaissance-reduction measure, not a substitute for patching. Attackers can sometimes fingerprint software through behavioural differences even without explicit version strings. The primary defence is keeping software updated; header suppression is a complementary hardening step.

WordPress and similar CMS platforms often embed the generator version in an HTML meta tag (<meta name="generator" content="WordPress 6.4">) and expose version numbers in static asset URLs such as /wp-includes/js/jquery/jquery-3.6.0.min.js. These should be removed or obfuscated via theme settings, security plugins, or build-time transformations.

Sensagraph automatically analyses HTTP response headers, HTML source, and error page content to identify technology names and version strings across web servers, frameworks, CMS platforms, and JavaScript libraries, flagging any version information exposed to unauthenticated users.