Reliably Detecting The WordPress Version
Sometimes you might want to find out if a website is built with WordPress, and which specific version of WP it’s running. In this post I’ll discuss a number of detection techniques, including ways to deal with sites that hide the fact that they’re running WordPress or spoof the version info.
For non-programmers : If you want something simple and don’t really care about detecting sites that hide their version info, check out the Show WordPress Version Greasemonkey script. Whenever you visit a WordPress blog, this simple userscsript will pop up a small box showing the WP version.
So how does one go about detecting the WordPress version? Simple – every WordPress site contains certain WordPress-specific footprints. A “footprint” can be anything from a unique piece of HTML code present on the front page to a specific subdirectory or file that’s only found on WordPress-based sites. Some sites try to hide the WordPress footprints, but most still leave something visible. And more often than not, this something is enough to determine that the site is running WordPress, and even find out the version number.
Lets see what these footprints are, shall we?
The generator META Tag
This is probably the most well-known way to detect the WordPress version. By default, WP will add the following META tag to every page of the site :
<meta name="generator" content="WordPress 2.8.6" />
All you need to do is check for the presence of this tag and you’ll immediately know that the site is running WordPress. Even the version number is helpfully included. However, this is also the least reliable technique, as it’s very easy to replace the version number with a fake one or remove the tag altogether.
The RSS Feed generator Tag
Even if the meta tag is gone, there’s still another place where the version number might be on display – the RSS feed. The WordPress generated feed is usually available at
example.com/?feed=rss2 and contains a tag that looks like this :
As you can see, the version number is right there.
CSS version data
Another place where WP discloses version information is the
/wp-admin/upgrade.php page. This page uses an external CSS stylesheet, and the stylesheet URL includes a “ver”/”version” parameter. Here’s an example from WP 2.8.6 :
<link rel='stylesheet' id='install-css' href='http://example.com/wp-admin/css/install.css?ver=20090514' type='text/css' media='all' />
This footprint is a (little) bit trickier to parse that the first two. Up to WordPress 2.5.1, the stylesheet URL contained the actual WordPress version in the “version” parameter. In later releases, it was replaced with a “ver” parameter containing some kind of a date; probably indicating the last time that CSS file was modified. I’ve found that the different date corresponds to each major WP release :
- 20090514 – 2.8.*
- 20081210 – 2.7.*
- 20080708 – 2.6.*
In some ways, this is actually better for our purposes than having the full version number in clear view. As I mentioned before, the version number can be easily spoofed. The date, however, can’t. I haven’t seen any plugins that would let you change or remove this footprint.
/wp-admin/upgrade.php happens to be inaccessible on some sites, you can also find a similar footprint in
Finally, almost every single new release of WordPress includes one or more files that weren’t there in the previous version. Many of these files – like images and JS scripts – are accessible to normal visitors. This means you can determine the WP version simply by checking for the presence of specific files.
I’ve compiled a small list of the last 6 major WP releases + a new web-accessible file that was added in each release :
- 2.2 –
- 2.3 –
- 2.5 –
- 2.6 –
- 2.7 –
- 2.8 –
This list is by no means comprehensive, but you can easily make your own by downloading older versions of WP and comparing them.
Happy data mining 😉Related posts :
Just with regards to CSS version data checking, this is coincidentally removed when using WP-Minify or other script compressors, and I’ve also personally written a plugin to remove version strings in normal situations. Still not common though 🙂
Interesting to see about the version-specific files technique, I never really considered that one and it’s the only vulnerability I know my blog has now, which more annoyingly is extremely difficult to cover. Ah well…
touching all specific files will cause a longer time when version-specific files technique is used.