Exposed Software Versions: How to Hide Server and CMS Details

Short answer: Many websites announce their exact software versions – for example Server: Apache/2.4.41 (Ubuntu), X-Powered-By: PHP/7.4.3 or a WordPress generator tag. Automated scanners use these details to find sites running versions with known vulnerabilities. Hide them by setting ServerTokens Prod and ServerSignature Off in Apache, server_tokens off in Nginx, expose_php = Off in PHP, and by removing generator tags and readme files from your CMS. Then keep the software updated, because hiding a version does not fix it.

“Exposed software versions” is a typical finding in a website security audit. It sounds minor – who cares if someone knows your PHP version? – but it is exactly the kind of information automated attack tools collect first. Hiding it takes a few configuration lines, costs nothing in performance, and removes an easy shortcut for attackers. This guide shows where versions usually leak and how to stop each leak on common servers and content management systems.

Why version numbers matter

Most attacks on small and medium websites are not personal. They are automated: bots scan large parts of the internet, collect information about each server, and match it against lists of known vulnerabilities. When a bot finds a response header that names a server or plugin version with a published exploit, the site moves to the top of the list.

Hiding version numbers does not make vulnerable software safe. What it does:

• Removes an easy way to filter targets, so your site is less likely to be chosen by version-matching scans.
• Makes reconnaissance slower and noisier, because attackers have to probe instead of read.
• Reduces the information you give away about your infrastructure, which is good practice in general.
• Satisfies security questionnaires and audits that list version disclosure as a finding.

Security specialists call this “defence in depth”: each layer is not enough alone, but together they make an attack harder. The most important layer remains updating the software itself.

What attackers do with version information

It helps to picture the process from the other side. A typical automated campaign works in three stages. First, a scanner requests the home page of millions of addresses and stores the response headers and a few lines of page code. Second, the collected data is filtered: every site whose headers or generator tags match a version with a public exploit goes on a shortlist. Third, a separate tool runs the exploit against the shortlist, often within days or hours of a vulnerability being published.

Sites that reveal nothing are not immune – some tools simply try the exploit everywhere – but they drop out of the cheap, targeted part of the process. The same logic applies to plugins and themes: a readme file with a version number tells a scanner that your site runs, for example, a gallery plugin with a known upload flaw. Removing those details costs you nothing and costs the attacker time, which is exactly the trade you want.

Where software versions leak

How to check what your site reveals

Start with the response headers:

curl -sI https://example.com

Look for Server, X-Powered-By, X-Generator, X-AspNet-Version and similar lines. Then open the page source (Ctrl+U in most browsers) and search for “generator” and “ver=”. Finally, request a page that does not exist and look at the error page, and try a few common file paths such as /readme.html, /license.txt, /phpinfo.php and /server-status.

How to hide versions on common platforms

Apache

In the main configuration file (often apache2.conf, httpd.conf or a security.conf include), set:

ServerTokens Prod
ServerSignature Off

ServerTokens Prod reduces the header to Server: Apache without version or operating system. ServerSignature Off removes the version line from server-generated error pages. These directives work only in the main server configuration, not in .htaccess. On shared hosting where you cannot change them, ask your host. Also make sure mod_status and mod_info pages are disabled or restricted to administrators.

Nginx

In the http block of nginx.conf:

server_tokens off;

This removes the version from the Server header and default error pages, leaving just Server: nginx. Removing the header completely requires an extra module (such as headers-more) or a proxy in front; for most sites, hiding the version is enough. Restrict any stub_status location to internal addresses.

PHP and application frameworks

In php.ini set:

expose_php = Off

This stops PHP from adding the X-Powered-By header. On managed hosting, the setting is often available in the PHP options of the control panel. Also make sure display_errors is off in production, because error messages can reveal file paths, library versions and database details.

Other stacks have equivalents: ASP.NET can remove X-AspNet-Version and X-Powered-By through configuration, Express applications can disable x-powered-by, and many frameworks have a “production mode” that hides debugging details. Delete any phpinfo() test files left over from setup.

WordPress and other CMS platforms

WordPress exposes its version in several places by default: the generator meta tag, RSS feeds, ?ver= parameters on scripts and styles, and the readme.html file. Plugins and themes can reveal their versions in their own readme files. Practical steps:

• Remove the generator tag – many security plugins and SEO plugins offer a setting, or a developer can remove it in the theme’s functions file.
• Delete readme.html and license.txt from the web root after updates, or block access to them at the server level, since updates may restore them.
• Block direct access to readme.txt files inside plugin and theme folders.
• Consider removing version query strings from asset URLs, but keep cache busting in mind: they exist so browsers load new files after an update.

Be realistic about the limits. A determined scanner can often fingerprint a CMS and even its approximate version from file contents and behaviour. That is exactly why updates matter more than hiding.

If you cannot change the settings yourself

On shared or managed hosting, server-level settings such as ServerTokens, server_tokens and sometimes expose_php are controlled by the host. A short support request usually solves it. Include the exact header lines you see, the hostname, and what you would like changed – for example: “Our site returns Server: Apache/2.4.41 (Ubuntu) and X-Powered-By: PHP/7.4.3. Please hide the version numbers and tell us whether a newer supported PHP version is available for our account.” The second question matters: a host that still runs an outdated PHP branch for your account is a bigger issue than the header itself.

Hiding is not patching

A version number is only dangerous when the version is vulnerable. The most effective security measure is keeping the web server, PHP, the CMS, plugins and themes on supported, updated versions. Use the exposure finding as a trigger to check:

1. Is the version still supported by its developers? Unsupported branches no longer receive security fixes.
2. Are automatic security updates enabled where possible – operating system packages, minor CMS releases?
3. Is there a schedule for major upgrades, such as moving to a newer PHP branch before the current one reaches end of life?
4. Are unused plugins, themes and test tools removed rather than only deactivated?

Checklist for closing version leaks

• Server header shows no version number.
• No X-Powered-By or framework version headers.
• Error pages are custom or show no software details.
• No generator meta tag with a version.
• No readme, changelog, license or phpinfo files accessible from the web.
• Status and info pages restricted to administrators.
• All software on supported versions, with an update routine.

How Site AI Audit helps

The security part of a Site AI Audit report includes a check for exposed software versions, next to the SSL certificate, the HTTPS redirect and security headers. The report explains each finding in plain words and shows how to fix it, ranked by impact, so you can hand it to your host or developer directly. Run a free check to see what your server reveals.

Related reading

• HTTP Security Headers Explained: What Each One Does
• TLS 1.0 and 1.1 Are Obsolete: How to Disable Them Safely
• Content Security Policy for Beginners: A Practical Setup Guide

The bottom line

Exposed version numbers give automated scanners a shortcut to vulnerable sites. Hiding them takes a few lines in Apache, Nginx, PHP and your CMS, and removing leftover readme and test files closes the rest. But hiding is only a thin layer: the real protection comes from keeping every part of the stack on supported, updated versions.

FAQ

Is showing my server version a real security risk?

On its own it is a low risk, but it makes it easy for automated tools to match your site against known vulnerabilities. If the version is outdated, the combination becomes a real risk, which is why audits flag it.

Can I remove the Server header completely?

Most servers let you hide the version but not remove the header entirely without extra modules or a proxy in front. Showing only “nginx” or “Apache” without a version is generally considered sufficient.

Why does my WordPress readme.html file come back after I delete it?

WordPress core updates restore the file. Blocking access to it in the server configuration or .htaccess is more durable than deleting it after each update.

Does hiding version numbers affect performance or SEO?

No. The changes remove a few bytes from headers and page code, and search engines do not use this information for rankings.

Is hiding the version enough if I cannot update right away?

It reduces exposure to version-based scanning, but attackers can still probe for vulnerabilities directly. Treat it as a temporary measure and plan the update as soon as possible.