You may have heard that a vulnerability in the OpenSSL cryptographic library called Heartbleed or formally called CVE-2014-0160 has been disclosed and that it represents a potential security threat to a large number of websites. Using this vulnerability, malicious individuals could access sensitive information submitted by people actively visiting a website including usernames, passwords and credit card numbers. Users across the Internet should be especially aware of suspicious activity on their accounts.

We want to communicate a couple pieces of information about this news with regard to

Members of the Drupal Association staff, Drupal Security Team and Drupal Infrastructure Team have reviewed's potential exposure to the vulnerability.

As of now, we have no indication that was attacked using this vulnerabililty. That said, the nature of the vulnerability makes an attack difficult to detect and we prefer to be cautious.

We have taken steps to protect users of, including a forced password reset for users with administrative access or access to code repositories for projects. While we have only forced the password reset for some users, we recommend that all of our users change their passwords.

We have taken the following steps to protect account holders:

  • Installed new SSL certificates based on a new private key
  • Revoked the old SSL certificates
  • Replaced the private strings (drupal_private_key and drupal_hash_salt) which are used for a variety of security related purposes in all Drupal sites
  • Replaced the private key used by the “bakery” single-sign-on system on
  • Removed all active sessions
  • Verified the email addresses in use today match those in use a week ago
  • Required that all users with administrative or project repository access to reset their passwords

Also, we simply want to help create awareness about the vulnerability and encourage people to review their sites for exposure. For more information, please see

Feel free to comment on the post with any questions. Thank you!


skulegirl’s picture

I searched around a bunch today to try and figure out the quickest, easiest way to remove all active sessions, but couldn't find anything. I want to do this for my site (I've replaced my SSL cert, etc.) How do I do that?

skulegirl’s picture

I should mention that my site is still running D6 - I know there's an "Active Sessions" module for D7 that I could install which would show me all active sessions and allow me to close them, but is there a simple solution for a D6 site?

basic’s picture

You can use Drush to run a query directly on your site:

drush -r /path/to/your/site sqlq "TRUNCATE TABLE sessions;"
Jaypan’s picture

Can you add a method to hide the banner? A close button of some sort?

drumm’s picture

We plan to remove it after 48 hours.

Currently, it is simple code in our theme, but I could imagine moving it to drupalorg_crosssite, with slightly more logic.

zhouhana’s picture

How about make a module out of it? I wanted to implement a really simple no-nonsense top bar text message just like that just a few days ago but had to resort to using the EU Cookie Compliance module with modified template and CSS. (TopBar Messages requires Features, which the site didn't have, and Hello Bar isn't free.)

blazindrop’s picture

I am an active contributor to the topbar_msg project for a HelloBar-like implementation on our site. The features requirement is a bit far fetched, but something we're talking about in the issue queue. I will have a patch soon so you can have custom messages for each site via the theme system. There's the elevator pitch :)

zhouhana’s picture

Awesome! Looking forward to that patch. :)

dbt102’s picture

The alert module may be relevant too

zhouhana’s picture

Thanks, I didn't know about that one, for some reason didn't think about searching for "alert". I'll check it out!

bhosmer’s picture

Would this suit your needs?

I need to get it updated for 7 though.

DrupalGideon’s picture

I created a while back for a simple message banner.

Suggestions welcome for version 2.

Formerly SkidNCrashwell. Changed my username to reflect my Twitter handle.

lhugg’s picture

Thanks for the very timely heads up on this.

The list above is a helpful starting point, but can we begin a thread on how some of these can be accomplished? For example, how to derive a new drupal_hash_salt or drupal_private_key. Or a discussion of the 'bakery' system and whether that is a component in Drupal sites other than D.O. This would be very helpful in moving this effort forward and helping us all preserve the good reputation Drupal has enjoyed so far.

drumm’s picture

Bakery is a contributed module, Since it is a single sign on system, a way to log into the site, it needed attention for invalidating sessions.

drupal_hash_salt is documented in settings.php files,

The best I can quickly find on drupal_private_key is

Resetting those to new random strings ensures form tokens and login links continue to be secure.

benjifisher’s picture

Looking at drupal_get_private_key() it seems that drupal_private_key is a Drupal variable. You can inspect it using drush:$ drush vget drupal_private_keyYou can then zero it out with$ drush vset drupal_private_key 0and it will be set to drupal_random_key() the next time drupal_get_private_key() is called.

mbawazir’s picture

Could you please provide me with some of infected sites as an example ?

stickywes’s picture

Perhaps you could be more precise as to what information you are looking for? It's probably not in anyone's interest to be pointing out websites we know to be currently vulnerable. The link provided in the blog is informative on what the vulnerability is (it is not a problem specific to Drupal), but you can also check out for what might be an easier read.

mbawazir’s picture

Thanks a lot for the clarification

christefano’s picture

I was one of the users who had to reset their password. After thinking about this, I believe step #7 above (require admins and project maintainers to reset their passwords) is not sufficient.

Either all accounts should have their passwords be reset or a new step needs to be added to this list that requires all new admins and new project maintainers to reset their passwords before they are given a role promotion.

As it is now, if a user is later promoted to one or both of those roles, their old password is still being allowed to be used. This means their account would theoretically continue to be vulnerable.

Haarek’s picture

Second this.
Also, why do the server only support older protocols and not TLS 1.2 and why no forward secrecy wich could be very helpful against a potential future bug like this?

basic’s picture

The load balancers currently run an older CentOS 5 release, and are limited by the older OpenSSL library included with the distribution. We have plans to upgrade these machines this year, as well as plans to front all of with a CDN which provides TLS 1.2, forward secrecy and many other features. The infrastructure team is aware of the needs and working to fix them as quickly as possible.

The CDN which was vulnerable to heartbleed and fronting does have TLS 1.2 and forward secrecy, so fortunately those were in place until we switched back to the load balancers which were not affected by heartbleed. Ignore the certificate mismatch to view the CDN SSL capabilities.

greggles’s picture

I think the scenario your propose makes some sense. We changed passwords for current admins/git users but it's possible someone got promoted just *after* we did that and now that account represents a weak point.

In theory it's possible someone harvested a lot of usernames/passwords using this vulnerability. In reality it's pretty difficult to do that, and especially difficult to do that en masse.

Resetting *all* passwords on the site has a very big and real cost to it. Many (maybe even most) people who have accounts on find that process confusing. That results in a large number of confused emails to the webmasters and the DA.

Hopefully, people are updating their passwords both in general and specifically because of this issue.

So, we made the decision that given that the risk of passwords getting leaked en masse was low enough and given the high cost of a 100% password reset was high enough and given the risk is mitigated by the fact that people are changing their passwords it simply wasn't worth a 100% reset.

Rather than spending time on something of unknown benefit with a high cost, I would rather we focus that time on things that are guaranteed high benefit:
* Rolling out two factor authentication and then requiring that for anyone who has admin or git-user access.
* Adding out-of-band notifications and logging for git ssh key changes

-- :)

NikLP’s picture

Worth reminding people that after a password reset on d.o, if you use your password to connect to your drupalcode git repos instead of a key, you will have to wait for the password to be synchronised with drupalcode. This may take some hours. Caught me out yesterday.

HongPong’s picture

It has surfaced that these kinds of flaws are not getting picked up adequately at all across the software community, sadly the open source world has not prevented stuff like heartbleed & goto fail, both of which happened in executing mission critical openly available code for many many months. While we have well known multi level PHP security strategies I know many take seriously I suggest maybe making modules for:
- encrypting sensitive things in RAM might be good
- test suites / fuzzing for handshakes, certs issues on any connections *between* drupal sites or anywhere SSL or TLS tunnelling gets used. could implement other people's crypto test libraries??

When an SSL session or some secured crypto handshake is connecting somehow, contrib modules to nitpick the holy hell out of these things is probably the best possible move to improve. Imagine intercepting some really subtle spoofed key attack between Drupal sites etc. Forgive me if some of this stuff already exists but I haven't really seen much sign of it as a *major goal* for the Drupal community, even though I respect the attention paid to security generally, which I think has paid off in an admirable recent track record. ... we have to cover detecting the problems in other libraries via Drupal contrib modules I believe.

Jaypan’s picture

That sounds like a great idea for a module/modules. Since you seem to have the drive to get this done, you should start developing them, it would make a great community contribution.

dustinmoris’s picture

Isn't this the most irresponsible thing to say about the Heartbleed vulnerability? Making a statement like this promotes users a false feeling of security, when in fact, there is no way whatsoever for you to know if someone sniffed SSL traffic on a public network and is harvesting Drupal user account credentials or not.

Please be honest about the security implications and do not make false statements!

Heine’s picture

As of now, we have no indication that was attacked using this vulnerabililty. That said, the nature of the vulnerability makes an attack difficult to detect and we prefer to be cautious.

Emphasis added.

This is why the steps listed were taken and users are either forced or encouraged to change their passwords.

greggles’s picture

For anyone interested in improving the security of, there's now an issue about Adding two-factor authentication to The proposed modules need some help and additional review before that can happen, though. As always, issues, patches, reviews, and feedback are highly welcome ;)

-- :)

sdo2399’s picture

Dear greggles,

are the modules ready for use?

greggles’s picture

I'm using them and Acquia is using them (though Acquia uses some plugins that are not on

Ben has recently committed a bunch of patches to the module that he and I had created in my testing of the module. Like all new modules it likely needs some additional work, but I would say that yes, they are generally ready to use.

-- :)

raquelle’s picture

Actually, I'm looking for this security update.