Yesterday Drupal.org got hacked, and potentially all the password hashes on the site fell into malicious hands. According to the security team's announcement, the attack was not a result of a Drupal vulnerability, but of other, as yet undisclosed, software on the server.
Drupal has long had one of the best security track records among open source CMSs. The security team does a great job of tracking down even the smallest exploits, often removing modules that maintainers choose not to fix. The vast majority of fixes and security updates we see are protecting against "privilege escalation" -- vulnerabilities that can only be exploited by users who already have some level of administrative access.
For example, there was a webform update yesterday to close a hole that allowed somebody who already had permission to create or edit a webform, to gain full administrative access. We use webforms on a huge number of sites, but we have never set up a configuration where we give an untrusted user the power to create or edit webforms. And yet on a large, community driven site, you might want to give some people the ability to create a survey without further access. This kind of strict, detailed review leads to a project that has a high level of security baked in. It's very rare that we see the more dangerous kinds of exploits -- SQL Injection, Cross-site scripting (XSS), or Remote Code Execution.
This incident highlights that there is more to security than just the software. In this case, something else in the hosting environment provided a weakness that allowed an attacker to break in. What was it? They haven't said, so far, but we can speculate on some possibilities: