Wikimedia’s response to the “Heartbleed” security vulnerability

Logo for the Heartbleed bug

On April 7th, a widespread issue in a central component of Internet security (OpenSSL) was disclosed. The vulnerability has now been fixed on all Wikimedia wikis. If you only read Wikipedia without creating an account, nothing is required from you. If you have a user account on any Wikimedia wiki, you will need to re-login the next time you use your account.

The issue, called Heartbleed, would allow attackers to gain access to privileged information on any site running a vulnerable version of that software. Wikis hosted by the Wikimedia Foundation were potentially affected by this vulnerability for several hours after it was disclosed. However, we have no evidence of any actual compromise to our systems or our users’ information, and because of the particular way our servers are configured, it would have been very difficult for an attacker to exploit the vulnerability in order to harvest users’ wiki passwords.

After we were made aware of the issue, we began upgrading all of our systems with patched versions of the software in question. We then began replacing critical user-facing SSL certificates and resetting all user session tokens. See the full timeline of our response below.

All logged-in users send a secret session token with each request to the site. If a nefarious person were able to intercept that token, they could impersonate other users. Resetting the tokens for all users has the benefit of making all users reconnect to our servers using the updated and fixed version of the OpenSSL software, thus removing this potential attack.

We recommend changing your password as a standard precautionary measure, but we do not currently intend to enforce a password change for all users. Again, there has been no evidence that Wikimedia Foundation users were targeted by this attack, but we want all of our users to be as safe as possible.

Thank you for your understanding and patience.

Greg Grossmeier, on behalf of the WMF Operations and Platform teams

Timeline of Wikimedia’s response

(Times are in UTC)

April 7th:

April 8th:

April 9th:

April 10th:

Frequently Asked Questions

(This section will be expanded as needed.)

  • Why hasn’t the “not valid before” date on your SSL certificate changed if you have already replaced it?
    Our SSL certificate provider keeps the original “not valid before” date (sometimes incorrectly referred to as an “issued on” date) in any replaced certificates. This is not an uncommon practice. Aside from looking at the change to the .pem files linked above in the Timeline, the other way of verifying that the replacement took place is to compare the fingerprint of our new certificate with our previous one.

You can translate this blog post.


4 Show

4 Comments on Wikimedia’s response to the “Heartbleed” security vulnerability

Tilman Bayer 2 years

BTW, the Foundation’s choice not to enforce a password reset for all users (but to revoke session cookies) is supported by this general risk assessment by password security researcher Joseph Bonneau:

For those who are interested in the subject, a while ago Bonneau co-authored a comparative study of password security on large websites, Wikipedia among them: (for that Signpost article, I also interviewed his coauthor who gave some specific recommendations to improve password security on Wikipedia, some of which have since been implemented or are being implemented)

Erik Moeller 2 years

FYI, there’s an attack strategy known as “reverse heartbleed”:

We’ve done an initial assessment and are not aware of any MediaWiki vulnerabilities to this attack strategy, but will continue to investigate.

Frank Schulenburg 2 years

A big thank you to the people on the Ops and Platform teams for their immediate response to this issue. You’re doing an amazing job!

PiRSquared17 2 years

There are numerous news reports and detailed analyses of this bug online, but I will not link them here. The links in this blog post are already great, but here are some more for people very interested in how this was handled and reported to the community (although not nearly as technical):
* (permalink )
* (permalink )
* (confirm fixed)
* Upgraded libssl on deployment-prep Labs (aka [])

Leave a Reply

Your email address will not be published. Required fields are marked *