What version of WordPress is behind that website?

Hi all, Dion here, Recently there’s been a few “security through obscurity” discussions going around, I’m sick of them, It doesn’t work, and this is my proof.

There are a few Plugins out there which hide the version number of WordPress, The first example i found was  Secure WordPress, It has over 170k downloads, But does it actually do what it claims?

Hiding the version number is Security through obscurity, You’re not making the install any safer, you’re merely not advertising the fact of which version you’re using.

But, do i hear you ask, “But if they dont know the version, doesnt that mean I’m safer?”
The answer to that is 3 fold:

  1. Just because they (the mystical hackers) cant see the version of WordPress you’re using, doesnt mean they’re not going to try the same attacks anyway, afterall, its only an extra 3 mouseclicks to run every exploit against every plugin known to man..
  2. Most  exploits in the WordPress world will be related to plugins, this is only due to the sheer number of them out there
  3. And finally, because hiding the version number doesnt hide the version of WordPress you’re using, which is the point of this tool/site

To use an example, It’s like walking through a battlefield with your gun hidden, just because they cant see your gun, doesn’t mean you’re going to be able to walk through the middle fo the battle, chances are, you’ll be shot anyway. Exploits are the same, they’ll attack anything that moves, the number of Joomla! or Drupal exploit attacks i see against my WordPress installs daily is enormous, & I’m sure Joomla! and Drupal installs see significant exploits thinking that the site is running WordPress. My point is, Exploits dont care, they’ll attack anyway.

Type the URL of a site below, be it advertising the fact its WordPress or not, and I’ll tell you instantly which version, or which version its most likely to be running:

Example sites:

PLEASE NOTE: This tool uses NOTHING PRIVATE, This is not connected to any WordPress.org infrastructure or otherwise secret data, All information that this tool uses is gleamed from your WordPress installation, just the same as anyone else can do.

27 thoughts on “What version of WordPress is behind that website?”

  1. Completely agree. I’d say claiming additional security by hiding the version number is worse that security through obscurity, it is a false sense of security. As you point out: the attacks happen any way and fingerprinting techniques allow for version detection even if the version number isn’t displayed.

    This false sense of security may lead to an unjustified sense of confidence.

    1. A False sense of security might be a better name for it really.

      I just wish that those who use WordPress would realise this, I have even seen WordPress consulting companies pushing the hide-the-version-number-to-save-yourself line, which is just plain sad.

  2. I doubt most hacker scripts even bother to check version number and just attempt to exploit the site anyway.

    The only real thing you can do to keep your site safe is use a good host and keep your WordPress version up to date.

    1. I doubt most hacker scripts even bother to check version number and just attempt to exploit the site anyway.

      Exactly, And people just don’t realise this. Such hacking scripts (And I can probably find a few examples if need be, It’ll only be a quick google away) will simply go through a list of exploits which have affected WordPress or WordPress plugins in the last 3 years, when one succeeds, Game over, They don’t bother checking the version number.

  3. There are some legitimate reasons why people want to remove the version / generator string to hide they are using WordPress but as you say none of them provide any security benefit.

    Looking at that plugin in particular I am glad to see that it uses the hooks we put in for removing the generator when they are available rather than just mangling the $wp_version global in an evil way.

    1. Luckily modifying the $wp_version global causes more problems than it solves now, so plugin authors/administrators are much less likely to follow that route anymore.

  4. Thanks Dion for writing this. The unfortunate thing about this type of security recommendation is that it gives the site owner a false sense of security and they will be more inclined to overlook real security measures which are less convenient (ex. strong password).

  5. Take a look at my site http://comiceasel.com/

    It’s effectively masked from your little script there.

    Probably don’t need half of these., but overkill right?

    remove_action('wp_head', 'meta_generator_tag');
    add_action('wp_head', 'frumph_mask_generator_tag');

    add_filter('get_the_generator_html', 'frumph_mask_generator_tag');
    add_filter('get_the_generator_atom', 'frumph_mask_generator_tag');
    add_filter('get_the_generator_rss2', 'frumph_mask_generator_tag');
    add_filter('get_the_generator_rdf', 'frumph_mask_generator_tag');
    add_filter('get_the_generator_comment', 'frumph_mask_generator_tag');
    add_filter('get_the_generator_export', 'frumph_mask_generator_tag');

    add_filter('the_generator', 'frumph_mask_generator_tag');

    function frumph_mask_generator_tag($filter) {
    return "\r\n";

    1. Whilst masked from it, that just means it’s an edge case I missed, I’m sure with a bit of tweaking and updating to the latest file signatures, there’s no reason it’d not catch it.

  6. I would rather have it hidden then shown. When it comes down to it, anything to differentiate yourself from the “average” WordPress blog might end up helping. So I would say yes, you might be a little bit safer and it certainly doesn’t hurt to throw those extra lines in your functions.php file.

    With that being said, I do agree it could create a false sense of security for some and shouldn’t be heralded to the masses as something that will “keep you safe”.

    1. I do agree it could create a false sense of security for some and shouldn’t be heralded to the masses as something that will “keep you safe”.

      Exactly, so the amount of time spent on concocting “enhancements” that have be proven to provide no benefit should be zero. Instead the focus should be on those items that do improve security. Doing anything else is at best a waste of time, and in the worst case complete snake oil.

    1. The simple reason was, Don’t trust what people have done to “hide” the version, Many people will change the version which WordPress reports, delete the readme and I’ve even seen one plugin which dynamically generates the readme with a random version.

      You dont have to have your WordPress version stated somewhere to detect which version of WordPress it is.

      I’d like to point out that the script is currently mis-reporting 3.1 as being 3.0 due to me not updating the file signatures recently (and even if I did, 3.1’s files are not significantly different yet)

        1. In your case, its a combination of the wp-admin folder being protected by other means (ie. Most of the files I used were in the admin folder) so it’s just getting 403 errors.. As a result, It was taking the forbidden notice to mean the files don’t exist, which was ruling out the latest versions of wordpress.

          Your server also returns 403’s for url’s containing // instead of /, It seems there was a bug in the generation of URL’s for the wp-includes directory..

          And finally, Your server is so slow, that the version on api2 is simply timing out, I had to increase the timeouts locally to 45 seconds in order to allow it to download the URL..

          I’m pushing a new copy onto the api server which increases the download timeouts, checks the readme.html version (and reports it as the claimed version if HTML/RSS fails) and ultimately reports your site as a 3.0 branch

          1. I used my .htaccess to protect the admin file, so there you are right.
            The .htaccess gives also an 403 on the //, so an intended bug here.
            You are right about the server speed. The server is in Holland, hosting plus domain costs me €20 a year for 3Gb. Not bad if the main visitors come from Holland, but for the States (or in my case, I’m in Indonesia at the moment) way too slow… Iwant to move and change this side anyway.

            Any suggestions for fast affordable hosts in the US?

            Thanks btw for checking my side.

          2. I feel your pain with server costs. My primary server is located in Australia, But certain domains of mine are hosted on Dreamhost in the US for the sheer lower cost of data.

            I try to keep my server running out of Australia on a VPS, so I cant really vouch for any American hosts other than Dreamhost (and thats only sheerly for their low cost, high quota offerings, make sure you check for Discount vouchers, I got my first year for $10 or so)

    1. Working now. Appears that nginx is configured to block HEAD requests. I was trying to save people some bandwidth.. switched to GET requests instead to simulate a browser.

      1. Since you are downloading JS files now, won’t it be easier to check the version of the JS files? E.g., (almost) every new WP release uses a different version of jQuery, TinyMCE, probably some other JS/CSS files.

        It is easy to block HEAD requests, deny access to /wp-admin/ directory etc, but it will be hard to spoof the versions of JS files (well, unless you edit them manually every time you upgrade WordPress).

        Just added a few lines to nginx config, now I get

        http://BLOG.SJINKS.pro/ is trying to hide its WordPress version, but is probably running version 1.5 OR 1.5.1 OR OR OR OR 1.5.2 OR 2.0 OR 2.0.1 OR 2.0.10 OR 2.0.11 OR 2.0.2 OR 2.0.3 OR 2.0.4 OR 2.0.5 OR 2.0.6 OR 2.0.7 OR 2.0.8 OR 2.0.9 OR 2.1 OR 2.1.1 OR 2.1.2 OR 2.1.3 OR 2.2 OR 2.2.1 OR 2.2.2 OR 2.2.3 OR 2.3 OR 2.3.1 OR 2.3.2 OR 2.3.3 OR 2.5 OR 2.5.1 OR 2.6 OR 2.6.1 OR 2.6.2 OR 2.6.3 OR 2.6.5 OR 2.7 OR 2.7.1 OR 2.8 OR 2.8.1 OR 2.8.2 OR 2.8.3 OR 2.8.4 OR 2.8.5 OR 2.8.6 OR 2.9 OR 2.9.1 OR 2.9.2

        The result is too vague now. And incorrect :-)

        I do understand that hiding WordPress version won’t stop the hackers as they are likely to use all exploits, just having fun :-)

        1. Doing the HEAD request was allowing me to get a unique ID for every file; doing a GET uses the exact same information, just downloads more.

          No sane server should be setup to discard HEAD requests.

          The result is vague, because all the unique files being accessed are now(were) blocked. the only file it could access was one which has stayed the same throughout the entire history of WordPress..

          You can probably tell from your access logs which files are being accessed; so you’ll see the set of files is random, but yet, selected because of the changes which have been made to them in the last few releases, or alternativly, removed/added in the last few releases.

          Like you’ve found, this was just a bit of fun to poke most people using basic “Hide your verison for huge security jumps!” plugins that it really does nothing, I can still guess the version of WordPress you’re using, and besides, it’ll take me exactly 5 seconds longer to try every WordPress exploit known to man against the server than targetting a single version.
          I mean look right now, People even use PHPBB exploits against WordPress (Well; Try to) they really don’t care (as it’s not their bandwidth they’re wasting)

          1. No sane server should be setup to discard HEAD requests.

            It isn’t; it just closes the connection when someone tries to access what they should not access.

            E.g., I don’t know any reason why someone would need to HEAD a javascript file or a stylesheet in /wp-includes/ or /wp-admin/ directory. Or why someone will need .mo/.po/.pot files. Personally I prefer to put all “internal” resources outside of the DocumentRoot; alas, it is not possible with WordPress.

            If error reporting is on and display_errors is on and you access almost any PHP file under /wp-includes/, the path of your WP installation will be disclosed. Same with WP plugins/themes.

            The result is vague, because all the unique files being accessed are now(were) blocked.

            You access a lot of files in /wp-admin/ folder. The server checks Referer: header which you don’t set. Besides, there are plugins that password-protect wp-admin directory (or you can do that with .htaccess) – the result for such sites will probably be vague too.

Comments are closed.