Back in January, a Drupal module called User Queue that I wrote and contributed to drupal.org got flagged as having a security vulnerability. To be clear, although User Queue is sort of useful (it's in production on both Observer.com and The Big Money), it's not exactly a huge or mission critical component for any site that I'm aware of. In fact, it only really exists because the much more feature-rich Nodequeue doesn't handle users due to their being a different type of first-class object in Drupal.
<!–break–>
So, it was sort of surreal to be told that I had to keep this security vulnerability secret while I fixed it and submitted a patch directly to the Drupal Security Team. And that furthermore, if I didn't fix it in a certain amount of time, the module would be unpublished and marked as abandoned. I certainly appreciate the necessity of doing this for really dangerous security problems, but mine was pretty trivial. Since the security advisory about this has now been posted, I can now talk openly about it (whew!)
The “vulnerability” involved the fact that in the User Queue admin page for a queue, you have a “remove” link for each user which has a URL like http://example.com/admin/user/userqueue/[queue_id]/delete/[uid]. Visiting this URL immediately removed the user from the queue. So, all you had to do was trick someone who was logged in as a user with 'administer user queues' permission into visiting such a URL to involuntarily remove the user from the queue. Pwned!
Thankfully, the new version of User Queue adds a unique token as a query string on these URLs which consists of an MD5 hash of your session ID and the user ID you're trying to delete. Of course, to exploit this in the first place you'd need to be able to find out the queue and user IDs, and one would imagine someone with the ability to do that could just make the changes themselves instead of duping another admin into it.
In general, this was about as benign of a security hole as you're likely to find. Nonetheless, this whole process was actually fairly enlightening to me. I've never had a Drupal site I've worked on be hacked or compromised, but I have both seen and (unfortunately) perpetuated the practice of ignoring security updates because it's inconvenient or not a high priority. Given that every Drupal security vulnerability is quite public, I'm kind of surprised there aren't a lot more hacked Drupal sites out there. While many security patches are pretty minor issues like mine, some of them are pretty bad (SQL injection or XSS).