WordPress 2.5.1 security update (and mod_security rule)

If you use the WordPress 2.5 blog software on your site, be sure to upgrade to WordPress 2.5.1 as soon as possible. The upgrade contains an important security fix. (We’ve updated our own blog, and it was painless.)

Although all WordPress users should upgrade right away, we’ve also added a security rule to our servers to try and protect our customers who haven’t yet upgraded. Other people may also find the security rule useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.

So what’s the security problem with WordPress 2.5? Well, if your blog allows strangers to register, the vulnerability allows evildoers to create a new unprivileged username like “admin0”, then use the cookie from that username to login as the privileged username “admin”.

This works because WordPress creates a login cookie with a value like this for “admin0”:


The first part is the username, the second part is the cookie’s expiration time, and the third part is an MD5 hash of the concatenated username, expiration, and some secret text.

The trouble is that this cookie is also valid:


We simply moved the “0” from the end of “admin” to the beginning of the expiration. Although this changes the username, it doesn’t change the MD5 hash! That’s because the text that the hash is based on doesn’t contain a separator such as a pipe character, as it should. In either case, it’s just hashing “admin01209331453” (plus the same secret text), and the identical hash is valid for both the privileged and unprivileged users. A nasty bug indeed.

You don’t necessarily need to use “0” on the end of the username, either; other digits can be made to work. They increase the expiration time of the cookie, but that doesn’t make it invalid.

So this vulnerability allows people to create a WordPress username ending in one or more digits, then use the cookie from that username to login as another username without the digits on the end.

Here’s where mod_security can be useful. It’s a great defensive tool that we’ve been using more and more to protect our customers from this kind of attack. If it’s possible to identify something that’s different about an “evil” page request (compared to a “good” page request), you can probably block the evil request using mod_security.

In this case, one thing immediately stands out: a “good” request always has a 10 digit expiration time in the cookie, but a “bad” request always has 11 or more digits. If we can block WordPress cookies that contain 11 or more digit expirations, that should block the evil request.

This rule for mod_security 1.x does the trick:

SecFilterSelective HTTP_Cookie "wordpress_[a-f0-9]{32}=[^\|]+\|[0-9]{11,}\|[a-f0-9]{32}"

And here’s the same rule for mod_security 2.x:

SecRule REQUEST_HEADERS:Cookie "wordpress_[a-f0-9]{32}=[^\|]+\|[0-9]{11,}\|[a-f0-9]{32}"

This looks for a cookie value containing 11 or more digits between the pipe symbols. This rule successfully blocks a test attack we created, and does not appear to give false positives (we’ve had it in place on servers that have served several million pages over the last few hours, with no matches beyond our tests).

Just so it’s clear, our customers don’t need to use these rules, because they’re already on all our servers — but we hope they’re useful to someone else.

Of course, if you know of any other attack vectors, please post a comment so we can improve the rules.


  1. I upgraded to 2.5.1 yesterday hoping that the fix would resolve the photo uploading issue in 2.5. Unfortunately, it was worse and now I could not even get it to work in Firefox, where it had before.

    I looked at the Changeset files and saw that the problem reported before had been corrected with this version. The only way I could get it to finally work was by disabling mod-security.

    This process is critical for me as I do a lot of blogging and CMS sites with photos. The new 2.5 format is, believe it or not, much less intuitive when it comes to uploading photos than the 2.3.X version I had before.

    I sure hope the get this fixed soon. It is killing me.

  2. Thanks for the comment. But just to be clear, it seems that you are referring to a different web hosting company. (You are not one of our customers.) Our mod_security rules couldn’t possibly affect your photo gallery setup, even if it was hosted on our servers.

    You should get in touch with your web hosting company to see if they can fix their mod_security rules, because it might be affecting other customers of theirs, too. It might also be useful to get in touch with the WordPress folks and explain how 2.5.1 doesn’t work well for you. Perhaps you can suggest some way for them to improve it.

    In any case, good luck! We hope you get things working better — and soon!