How to Remove the WordPress Version Number

Posted by Jeff Starr • Updated on March 28th, 2018

In this DigWP tutorial, we take a look at a the potential security risk inherent in displaying your site’s WordPress version number to anyone or anything that happens to stop by for a visit. For anyone who has been working on securing their WP-powered website, one of the most commonly seen security tips around the WordPress-o-Sphere has got to be this:

Don’t display your WordPress version number publicly. Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular version.

This sort of thinking is referred to as “security through obscurity,” and may or may not be an effective way to increase the overall security of your site.

By default, WordPress executes the wp_generator() function whenever the wp_head() hook is called. Typically, this hook is located in your theme’s header.php file within the <head> section of the document markup:

The wp_head() hook as seen via the header.php file

Then, after WordPress processes your web page, the wp_generator() function outputs the following code (depending on page view) to your browser:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='https://digwp.com/' />
<meta name="generator" content="WordPress 2.8.1" />

Notice that last line there? There are many posts on WordPress security that point out how specifying your version number is a security risk. Whether or not this is the case is certainly debatable, but the thinking is that you should avoid revealing this sensitive information in order to prevent attacks targeting specific versions of WordPress.

Now for the fun part. Assuming that sharing your version information is bad, how to go about removing the information? Well, that depends on how savvy you are with WordPress. Here are several methods to prevent WordPress from displaying your version-specific number, ranked in order from the absolute worst way to the absolute right way. That is, until someone shows us how to do it in less than 41 characters ;)

The absolute worst way to remove the WP version number

I have seen recent posts where the author actually recommends deleting the wp_head() hook! Here is an example:

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change.

While there are indeed valid reasons for removing this important WordPress hook, removing the version number from your source code is not one of them.

A pretty good way to remove the WordPress version number

Much better than simply deleting the wp_head() hook, this method serves us well by placing the version-removal function in the theme’s functions.php file, where it belongs. By returning an empty string for the_generator, this function removes the version information by preventing output of its <meta> tag:

function remove_version_info() {
     return '';
}
add_filter('the_generator', 'remove_version_info');

This method has the added bonus of removing the version information from not only your blog pages, but from your feeds as well.

The right way to remove the WordPress version number

Going a step beyond the previous method, this technique gets the job done quite eloquently, with a mere 41 characters of code:

remove_action('wp_head', 'wp_generator');

Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)

Update: A New Way to Remove the WP Version Number

Since this article was written, a lot has changed with WordPress. Here is a new way to prevent WordPress from displaying its version number:

// remove version from head
remove_action('wp_head', 'wp_generator');

// remove version from rss
add_filter('the_generator', '__return_empty_string');

// remove version from scripts and styles
function shapeSpace_remove_version_scripts_styles($src) {
	if (strpos($src, 'ver=')) {
		$src = remove_query_arg('ver', $src);
	}
	return $src;
}
add_filter('style_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);
add_filter('script_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);

No editing required. Add to functions.php and done. Or add via simple custom plugin. The choice is yours! :)

31 responses ↓

About the author

Jeff Starr is a professional web developer and book author with over 15 years of experience. Jeff works with WordPress every day, designing themes, developing plugins, and securing sites. His books include Digging Into WordPress, WordPress Themes In Depth, and The Tao of WordPress.

View all from Jeff Starr

← Move Your WordPress Files Out of the Root Directory

Display a Random Post (with AJAX Refresh) →

31 responses

edogawaconan

July 15, 2009 @ 2:01 am

switch to branch tree and create crontab to do daily update would be much better than hiding version number.
- Jeff Starr Post Author
  
  July 15, 2009 @ 8:41 am
  
  Ideally, perhaps, but not practically. Updates can break things, especially as the site configuration grows more complex. Not sure how many users are going to “switch to branch tree and create crontab,” but it is an excellent idea for a tutorial.
  
  Thanks for the tip :)
  - edogawaconan
    
    July 15, 2009 @ 8:52 am
    
    Isn’t that only mostly true on major updates? (f.e. 2.7 -> 2.8)
    And according to this, branch tree only contains fixes on major bugs and security issues.
  - Jeff Starr Post Author
    
    July 15, 2009 @ 9:24 am
    
    Not sure what you mean by “only mostly true,” but any update involves conflict potential. Automating the process is not a one-size-fits-all solution, although doing so is better for security than simply hiding the version number.
  - edogawaconan
    
    July 15, 2009 @ 9:33 am
    
    I mean, on major updates the chance of something broken is pretty high while this is not usually the case on minor updates. I would say the chance of something broken in minor updates is low especially if all the plugins/theme used are actively developed and coded properly. There is always chance of something broke though.
  - Jeff Starr Post Author
    
    July 15, 2009 @ 10:01 am
    
    I do see your point, but keep in mind that a majority of users (and I would guess a vast majority) have no idea how to “branch and cron,” as it were. Conversely, adding a line to functions.php is something that most users can do, should they decide it’s worthwhile.
sunil

July 15, 2009 @ 3:29 am

Useful information. Thanks
Teddy

July 15, 2009 @ 4:58 am

Wow, loving the simpler method. I used the first code for my client’s project – not for security reasons though, but more of them afraid WP from tarnishing their branding (I have no idea why, but I guess they’re simply bigots). The second method you’ve proposed looks a lot simpler and shorter.

One question though: Is it valid in older versions of WP? (stupid question and I know the answer is probably yes)
- Jeff Starr Post Author
  
  July 15, 2009 @ 8:45 am
  
  Within reason, yes — but if you travel too far back in time, these methods may not work. I think the remove_version_info() function will work in more versions than the remove_action() method, but I may be mistaken.
Barbara

July 15, 2009 @ 2:28 pm

Thanks for the info. I’ve seen other solutions that didn’t even work. This one does.
Anubis

July 16, 2009 @ 11:07 am

Thanks Jeff for your posts, I am learning a lot and am fairly new to WP here… when you say “Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)” where exactly do you place that code? At the beginning, the end? Thanks!
- John
  
  July 16, 2009 @ 11:23 am
  
  can go anywhere inside the function.php file in your themes folder.
  - Anubis
    
    July 16, 2009 @ 11:32 am
    
    Thanks John!
  - John
    
    July 16, 2009 @ 11:26 am
    
    if you do not have a functions.php file create on and put this line anywhere inside it <?php remove_action('wp_head', 'wp_generator'); ?>. I mistyped it above it needs to be functions.php not function.php it has to have the “s” on the end.
Smooth Crminal

July 16, 2009 @ 10:38 pm

Ok so why “security through obscurity” is better? I can’t see the point of removing version number because this doesen’t resolve anything.
- edogawaconan
  
  July 16, 2009 @ 11:09 pm
  
  I don’t think he said ‘”security through obscurity” is better’ anywhere in this post. He only explains the better way doing it. Not that doing this is better.
- Davezilla
  
  July 21, 2009 @ 7:21 pm
  
  Sp@mmers and Script Kiddies frequently target blogs and look for version numbers to determine which insidious script to run. Some don’t bother with version numbers, but if a sp@mmer or SK knows of a security exploit on a certain version number, then they will have their tool spider for blogs with a certain version number to hit.
Lalor McMahon

July 16, 2009 @ 11:29 pm

Great tip Jeff. Just wondering what would be needed in order to customise the meta information to insert design/author details of the theme etc?
- Jeff Starr Post Author
  
  July 19, 2009 @ 9:32 pm
  If you are referring to the <meta> tags in the document <head>, you could add something like this to your functions.php file:
```
function custom_meta() {
       echo "<meta name='author' content='Jeff Starr' />";
}
add_action('wp_head', 'custom_meta');
```
  I also have a simple plugin that does this very thing, enabling you to customize a variety of common meta tags.
  - Lalor McMahon
    
    July 21, 2009 @ 11:41 pm
    
    Thanks Jeff – just what I was after!
iceflatline

July 17, 2009 @ 12:29 pm

The way I did this was to edit a line in the /wp-includes/defaults-filter.php file. In that file you’ll find the following line:

add_action('wp_head', 'wp_generator');

Replace that line with:

remove_action('wp_head', 'wp_generator');
- Jeff Starr Post Author
  
  July 19, 2009 @ 9:34 pm
  
  Ah, another brave soul who prefers to hack the WP core ;)
  
  May I ask why you chose this method as opposed to going the functions.php route?
Vladimir

July 20, 2009 @ 2:01 pm

Jeff,

I must say there are many ways to find out the version of WordPress you are using.

Just view the source of your login page and you will see the things like:

.../wp-admin/css/login.css?ver=20090514
.../wp-admin/css/colors-fresh.css?ver=20090625

By examining the versions of the CSS files, TinyMCE and other JavaScripts it is possible to find out what version of WordPress is actually used.

An example: you have “/wp-includes/js/autosave.dev.js” in your server. Dev-versions (not minified) of JS appears as of WP 2.8.

Version of 20090625 of colors*.css is likely to indicate WP 2.8.1 (although I am too lazy to check which numbers WP 2.8 used).
- Jeff Starr Post Author
  
  July 20, 2009 @ 5:49 pm
  
  Insightful as always, Vladimir. I will be checking into these files and examining their default availability and accessibility. Hopefully preventing access is possible, as I am not seeing any way of renaming these files via functions.php. There are many scans for WordPress generator version, but I have never seen any for these specific files, not that it isn’t happening, but probably to a much lesser extent. Still a bit disconcerting though. Thanks for the heads up.
iceflatline

July 20, 2009 @ 1:13 pm

Jeff,

Personal preference I guess. It made sense to me to stamp out the function where it was being triggered. The other wp-head hooks are there as well. I’d welcome your thoughts on the pros and cons of each approach though.
- Jeff Starr Post Author
  
  July 20, 2009 @ 5:43 pm
  
  The main argument against hacking the WP core is of course that it complicates the upgrade process. For production sites, I might agree with this, but for learning and development purposes, there is no better way to learn WordPress than to “dig in” and start hacking around in the core. I owe most of what I know about WordPress to breaking (and fixing) things in the core. So the question goes back to you: how do you go about upgrading? Do you have multiple sites?
  - iceflatline
    
    July 22, 2009 @ 2:18 pm
    
    Jeff, thank you. I simply make a backups of the files I have made edits to in /wp-includes. So when I upgrade, which I typically do manually, I can reapply the necessary changes where necessary. Not the most elegant I’ll admit…
  - iceflatline
    
    July 23, 2009 @ 5:20 pm
    
    Jeff,
    
    Update. After giving this some more thought I think your approach is indeed more effective. As you suggest, it does make upgrades easier ;-)
    
    Thanks for the terrific article.
Jose

July 27, 2009 @ 4:49 am

When it comes to security, isn’t keeping wp up to date better than hidding the version number?

Nice and clean fix as always though.
- Jeff Starr Post Author
  
  July 27, 2009 @ 10:42 am
  
  I don’t think there’s any one thing that is going to keep your public site totally secure. It’s more like a culmination of various layers of protection. Hiding the version number is merely one of those (hopefully) many layers.
Ramyasadasivam

July 1, 2012 @ 1:13 am

Thq :-)