The flaw probably won’t affect too many users. It requires a password-protected page within a self-hosted WordPress site; and almost by definition, bloggers and users of blogging software want to publicize rather than protect their pages. However, if such a page exists and an attacker can find it, he could manipulate the password process to effect denial of service. In announcing the flaw, Krzysztof Katowicz-Kowalewski included a temporary patch that can be used pending an official patch from WordPress.
Secunia, which has confirmed the vulnerability in 3.5.1 notes that other versions may also be affected. “The vulnerability is caused due to an error when calculating the hash cycle count within the "crypt_private()" method in /wp-includes/class-phpass.php,” it explains, “and can be exploited to exhaust CPU and memory resources by sending HTTP requests with a specially crafted password cookie.”
The affected code wasn’t written in-house by WordPress. It’s an implementation of phpass, a portable PHP password hashing framework, available from Openwall. But again, it doesn’t seem to be a flaw in the phpass code, but rather the way it has been implemented by WordPress. Responding to Katowicz-Kowalewski’s disclosure on BugTraq, ‘Alexander’ (probably Alexander Peslyak, the founder and CTO of Openwall Inc), commented, “Web apps (like WordPress) were indeed not supposed to expose the ability for untrusted users to specify arbitrary "setting" strings (which include the configurable cost). I am unfamiliar with WordPress, so I don't know why they do it here.”
However, this ‘who’s fault is it anyway?’ discussion is of little benefit to WordPress users. Many will have chosen WordPress simply because they have no personal coding skills, and some will have included password protection simply because they can. These users are vulnerable; but these same users will be uncomfortable with applying the code patch provided by Katowicz-Kowalewski. The best solution here will be to remove the password protection or the entire protected page until the flaw is fixed by WordPress.
Meanwhile WordPress engineers might consider a more proactive response to notifications they receive from this researcher – particularly since he closes his own blog on the issue with, “Btw. there will be more stuff for WordPress! ;)”