Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   WordPress Vendors:
WordPress Cookie Authentication Flaw Lets Remote Users Access Accounts in Certain Cases
SecurityTracker Alert ID:  1018980
SecurityTracker URL:
CVE Reference:   CVE-2007-6013   (Links to External Site)
Updated:  Feb 17 2008
Original Entry Date:  Nov 19 2007
Impact:   User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 2.3.1 and prior versions
Description:   A vulnerability was reported in WordPress. A remote user can access arbitrary user accounts in certain cases.

A remote user with read-only access to the Wordpress database wp_user table can generate a valid authentication cookie for arbitrary users on the target application.

This vulnerability is being actively exploited.

The vendor was notified on October 29, 2007, without response.

The original advisory is available at:

Steven J. Murdoch reported this vulnerability.

Impact:   A remote user with read-only access to the Wordpress database can generate a valid authentication cookie for arbitrary users on the target application.
Solution:   The vendor has issued a source code fix.
Vendor URL: (Links to External Site)
Cause:   Authentication error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  Wordpress Cookie Authentication Vulnerability

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Wordpress Cookie Authentication Vulnerability

Original release date: 2007-11-19
Last revised: 2007-11-19
Latest version:
CVE ID: <pending>
Source: Steven J. Murdoch <>

Systems Affected:

 Wordpress 1.5 -- 2.3.1 (including current version, as of 2007-11-19)


 With read-only access to the Wordpress database, it is possible to
 generate a valid login cookie for any account, without resorting to a
 brute force attack. This allows a limited SQL injection vulnerability
 to be escalated into administrator access.

 This vulnerability is known to be actively exploited, hence the
 expedited public release.

I. Description

 For authentication, the Wordpress user database stores the MD5 hash
 of login passwords. A client is permitted access if they can present a
 password whose hash matches the stored one.

 $ mysql -u wordpress -p wordpress
   Enter password: ********

   mysql> SELECT ID, user_login, user_pass FROM wp_users;
   | ID | user_login  | user_pass                        |
   |  1 | admin       | 4cee2c84f6de6d89a4db4f2894d14e38 |

 Of course, entering your password after each action that requires
 authorization would be exceptionally tedious. So, after logging in,
 Wordpress presents the client with two cookies:


 The cookie names contains the MD5 hash (6092...1a5f) of the blog URL.
 The value of wordpressuser_... is the login name, and the value of
 wordpresspass is the double-MD5 hash of the user password.

 Wordpress will permit access to a given user account if the
 wordpressuserpass_... cookie matches the hash of the specified user's
 wp_users.user_pass database entry.

 In other words, the database contains MD5(password) and the cookie
 contains MD5(MD5(password)). It is thus trivial to convert a database
 entry into an authentication cookie.

 At this point the vulnerability should be clear. If an attacker can
 gain read access to the wp_user table, for example due to a publicly
 visible backup or SQL injection vulnerability, a valid cookie can be
 generated for any account.=20

 This applies even if the user's password is sufficiently complex to
 resist brute force and rainbow table attacks. While it should be
 computationally infeasible to go backwards from MD5(password) to
 password, the attacker needs only to go forwards.

 The exploitation steps are therefore:
  1) Find the hash of the blog URL: Either just look at the URL, or
     create an account to get a user cookie
  2) Read the user_pass entry from wp_users table: Look for
     backups, perform SQL injection, etc...
  3) Set the following cookies:
  4) You have admin access to the blog

II. Impact

 A remote attacker, with read access to the password database can gain
 administrator rights. This may be used in conjunction with an SQL
 injection attack, or after locating a database backup.

 An attacker who has alternatively compromised the database of one
 Wordpress blog can also gain access to any other whose users have the
 same password on both.

III. Solution

 No vendor patch is available.
 No timeline for a vendor patch has been announced.


 - Protect the Wordpress database, and do not allow backups to be
 - Keep your Wordpress installation up to date. This should reduce the
   risk that your database will be compromised.
 - Do not share passwords across different sites.
 - If you suspect a database to be compromised, change all passwords
   to different ones. It is not adequate to change the passwords to
   the same ones, since Wordpress does not "salt" [1] the password
 - Remove write permissions on the Wordpress files for the system
   account that the webserver runs as. This will disable the theme
   editor, but make it more difficult to escalate Wordpress
   administrator access into the capability to execute arbitrary code
 - Configure the webserver to not execute files in any directory
   writable by the webserver system account (e.g. the upload

 Potential fixes:

  The problem occurs because it is easy to go from the password hash
  in the database to a cookie (i.e the application of MD5 is the wrong
  way around). The simplest fix is to store MD5(MD5(password)) in the
  database, and make the cookie MD5(password). This still makes it
  infeasible to retrieve the password from a cookie, but means that it
  is also infeasible to generate a valid cookie from the database

  However, there are other vulnerabilities in the Wordpress cookie and
  password handling, which should be resolved too:

  - Passwords are unsalted [2], leaving them open to brute force, rainbow
    table and other attacks [3].
  - It is impossible to revoke a cookie without changing the user's
  - Cookies do not contain an expiry time, so are always valid (until
    the user's password changes)
  - There ought to be an option to limit cookies to a particular
    IP address or range.




 2007-10-29: notified; no response
 2007-11-02: notified;
             Confirmation of active exploitation requested by Wordpress
 2007-11-02: Confirmation sent; no response
 2007-11-19: Advisory released to full-disclosure and BugTraq


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.5 (GNU/Linux)




Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC