Should you hide your WordPress version? Will it enhance security of your site? Probably not! In this article you can read the reasons and learn a brand new method to determine WordPress version.
You’ve probably heard that hiding the WP version is a very important part of WordPress Security. At the beginning of February there was a serious vulnerability issue with WP REST API where the version shows if your site is vulnerable or not. So many users have been searching for ways to hide information about their WordPress version.
In my opinion, this is not an important part of the protection process. The makers of WordPress don’t see it as an issue and they’re not trying to hide it . I will present my arguments later in this article, but first let’s look at the methods used to determine the WordPress version and how to prevent them (if you want).
- The easiest way to determine the version is to visit the URL /readme.html and read the big heading.
- From 4.7 this method is less usable, because WordPress stopped showing the minor version (4.7.2.) and shows only the major (4.7).
- If you open the source code of your site, you can find the meta tag generator with the WP version in it:
<meta name="generator" content="WordPress 4.7.2" />
- You need to find the right line, but it’s still pretty easy.
- Another location to check the version is /feed/, where you can find the XML element generator:
These 3 methods are the most common ways to determine the WordPress version.
There are ways to prevent these methods. You can block access to readme.html e.g. In the .htaccess file:
The message “403 – access denied” will be returned. But it shows the attacker that the file exists. So, pretending the file doesn’t exist may be a better way. You can return the message “404 – not found” with the following rule:
RewriteRule ^readme.html - [L,R=404]
If you want to remove the version from the meta tags and the feed, you need to do it in WordPress. The version number has it’s origin in the wp-includes/version.php file. It is stored in the global variable called wp_version.
One approach is to remove the string with the version so that the site “pre-renders” (ob_start,..) and finds and replaces all occurrences of the version number. I find this to be useless and performance wasting, because it doesn’t work for /feed/. Of course, you can edit the feed, but there are more locations you must edit.
Did you know about the file /wp-links-opml.php? It also reveals the version number. It’s a lot of work to validate all these files.
A better approach is to use the WP hook the_generator:
It removes the version from meta tags and form the XML feeds.
Usually, there is another location with the version string – in paths to the css and js files. Many plugin/theme creators append the “ver” parameter to the path to prevent client side caching after the update.
Again, there is a hook to remove it:
This snippet removes the ver parameter from all js and css files. You can enhance it to remove only ver if it contains the $wp_version value.
The New Method
In versions 4.7.1 and 4.7.2 there wasn’t any static file changes, so I had to find a new method for my analysis on the impact of the WP REST API vulnerability. The readme.html doesn’t work and many modern sites use security plugins to hide the most common ways to determine WP version. So I had to check the site before these plugins were active, and then find some output with the ver parameter in the static files. Yes, this does happen in some cases 🙂
There are some files that need to run independently of WordPress, the installation files:
/wp-admin/upgrade.php. They provide the user interface with some css styles and these files reveal the version. You can visit
/wp-admin/install.php, which shows that WordPress is already installed. Then, if you check the source code you will see something like:
On some servers, access to install.php is blocked, but I have never seen upgrade.php blocked yet. Another file reveals WP version in the login screen at
Could hiding help? No. These mass attacks – I suppose that 99.9% of all attacks are this kind – don’t even try to do any exploration of your website, they simply try to exploit any vulnerable URL directly. They don’t even check if the website is powered by WordPress. Their goal is to attack as many targets as possible in the shortest time before the patch will be applied. Any other communication with the target results in unnecessary delay.
Hiding the WordPress version is one of the techniques called “security by obscurity”. In most cases, hiding the version won’t have a negative effect, but you cannot expect it to bring some serious protection. There are some premium plugins which try to hide information about WP, but in principle they cannot work 100% of the time, and I recommend to avoid them. If you update your WP regularly, you have no reason to hide the version number. This is the best defense against attack.
You may find this interesting: