The main issue is that we offer the ability for a user to change their email address. This is a very common feature, and thus something a lot of sites fall victim to. The basic nature of an XSS is that a malicious site can cause you to POST or GET arbitrary URLs. Since cookies are always sent along with the request, if you are authenticated, the attacking site can cause you to hit traditionally protected URLs. This is normally a non-issue, as only your browser reads the content -- the attacking site has no visibility into the data. However, it is an issue when there are side-effects, when the malicious site can change things to their advantage. In this case, they changed the email address to their own via a post. From there, all they had to do was hit the password reset function for their email address.
As soon as we found out about this, we immediately turned off email and password reset. This prevented the XSS from working, as the urls in the attack 404'd. This was a temporary solution.
Next, we now require you to enter your current password when you reset your email. This would also prevent the XSS, as the attacker would need to know the users password. It also prevents against other attacks, such as someone with physical access to your logged in session from resetting your email address with out you knowing.
We also implemented the Django CSRF middleware. This protects the rest of our forms on the site from similar problems.
As for impact, our audit logs show that only the attackers account was compromised for the sake of his demo. Fortunately, he did not randomize the email address used to change the password. If anyone did become a victim to his example, it would not have changed the email to his address (we only allow unique email addresses in the system). However, it is possible this XSS was in "the wild" with other addresses, but according to our logs and the nature of the vulnerability, it is highly unlikely that it impacted any users.
As others mentioned in the comments, it would have been great for the author to contact us before posting this. As motivation to future security researchers, we will happily offer a bounty if you report your bug to us before posting it publicly. In fact, if you're really good -- we'll happily make the bounty a full time job with benefits! :)
If you have any questions or concerns about this issue, please do not hesitate to contact me personally! polvi@cloudkick.com