WordPress displays its version number in several places by default. On its own, this is not a critical vulnerability. But it gives attackers a head start. If someone knows you are running WordPress 6.2.1, they can look up every known exploit for that exact release and try them against your site. Removing version information is a simple first step that makes automated scanning tools less effective.
Where WordPress Exposes the Version Number
WordPress is surprisingly generous about revealing which version it runs. Here are the most common places where attackers (and anyone viewing your source code) can find it:
- Generator meta tag: WordPress adds a
<meta name="generator" content="WordPress 6.x.x">tag to the<head>section of every page. This is the most obvious place, and it shows up on every single page load. - RSS and Atom feeds: Your site's RSS feed (typically at
/feed/) includes a<generator>element with the full WordPress version string. Many site owners forget about feeds entirely, leaving this vector open. - Script and stylesheet query strings: WordPress appends
?ver=6.x.xto CSS and JavaScript file URLs when it enqueues them. Even if you remove the meta tag, this parameter still broadcasts your version in every asset request. - The readme.html file: WordPress ships with a
readme.htmlfile in the root directory. This file contains the version number in plain text and is accessible to anyone who knows the URL. - The license.txt file: Similar to
readme.html, thelicense.txtfile sits in the WordPress root and can confirm that the site runs WordPress. - The login page source: The WordPress login page at
/wp-login.phploads stylesheets and scripts with version query strings, making it another source of version information. - REST API responses: The WordPress REST API root at
/wp-json/can also reveal version details in its response headers or body.
Why Hiding the Version Matters
Every major WordPress release has a public changelog. When a security patch lands, the vulnerability it fixes becomes public knowledge. Automated bots constantly crawl the web looking for sites that still run the old, vulnerable version. If your site advertises "WordPress 6.2.1" and a critical SQL injection was patched in 6.2.2, your site becomes a target within hours of the patch release.
Hiding the version number does not fix the vulnerability itself. It simply removes one data point that attackers use to prioritize targets. Think of it like removing your house number from a list of homes with unlocked doors. The door might still be unlocked, but at least you are not on the shortlist.
Remove the Version from HTML and Feeds
Add the following code to your theme's functions.php file or, better yet, to a site-specific plugin so it survives theme changes:
// Remove the generator meta tag from HTML head
remove_action('wp_head', 'wp_generator');
// Remove version from RSS feeds
add_filter('the_generator', '__return_empty_string');
// Remove version query string from scripts and styles
function remove_wp_version_from_assets($src) {
if (strpos($src, 'ver=' . get_bloginfo('version'))) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'remove_wp_version_from_assets', 9999);
add_filter('script_loader_src', 'remove_wp_version_from_assets', 9999);The remove_action call strips the meta tag. The the_generator filter handles RSS and Atom feeds. The two loader filters remove the ?ver= parameter from all enqueued assets. Using priority 9999 ensures this runs after plugins and themes have added their own scripts.
Delete readme.html and license.txt
These static files sit in your WordPress root directory and contain version information. Delete them:
rm /path/to/wordpress/readme.html
rm /path/to/wordpress/license.txtThere is a catch: WordPress recreates these files during core updates. You have two options for handling this. You can delete them manually after each update. Or you can add a small script to your deployment process that removes them automatically. If you use WP-CLI, a post-update hook works well for this.
Plugin-Based Approaches
If you prefer not to edit code files, several plugins handle version removal for you. Security plugins like Wordfence, iThemes Security, and All In One WP Security all include options to hide the WordPress version. Lightweight options like Meta Generator and Version Info Remover focus specifically on this task without adding extra overhead.
When choosing a plugin, make sure it covers all the locations listed above, not just the meta tag. Some plugins only remove the generator tag and leave script query strings untouched.
Security by Obscurity Is Not Enough
Hiding your WordPress version is a good practice, but it is not a security strategy on its own. A determined attacker can still fingerprint your WordPress version through other methods, such as comparing the content of core JavaScript files or checking for the presence of specific features introduced in certain releases.
For real security, you need to combine version hiding with the fundamentals:
- Keep WordPress, themes, and plugins updated: This is the single most important thing you can do. Most WordPress hacks exploit known vulnerabilities in outdated software.
- Use strong passwords and two-factor authentication: Brute force attacks against
wp-login.phpremain one of the most common attack vectors. - Install a web application firewall (WAF): Services like Cloudflare, Sucuri, or a plugin-based WAF can block malicious requests before they reach WordPress.
- Limit login attempts: Plugins like Limit Login Attempts Reloaded prevent attackers from running automated password guessing attacks.
- Disable XML-RPC if you do not need it: XML-RPC is another common attack vector for brute force and DDoS amplification.
Verify the Changes with InspectWP
After implementing these changes, run a new InspectWP scan on your site. Check the WordPress section of the report. The version number should no longer appear in the HTML source code, and the meta generator tag should be gone. If InspectWP still detects a version, double-check that the code snippet is loaded correctly and that caching plugins are not serving a stale version of your pages.