On October 29, the Drupal Security Team issued a Public Service Announcement (PSA) as a follow-up to Security Advisory SA-CORE-2014-005, which disclosed a serious SQL Injection vulnerability in Drupal 7. Our goals with the PSA were to:

  1. Provide an update on the time window between disclosure and first-known exploits
  2. Provide guidance for users who patched or upgraded outside that window
  3. Reiterate the severity of the vulnerability and the importance of upgrading or patching

(Speaking of which, if you have not remediated yet, please stop reading and do so.)

While we feel those goals were accomplished, the PSA also resulted in a large volume of press coverage – in fact much more coverage than the original disclosure of the vulnerability on October 15th. Not surprisingly, the general tone of the press coverage was quite negative. Unfortunately, some of the coverage was also inaccurate which we’d like to address here as well as provide additional context regarding our security processes.

While we don’t know the total number of Drupal sites affected, the number is not near 12 million as stated in several publications. Unless disabled, individual Drupal sites report their existence back to Drupal.org and this system reports around 1 million total Drupal sites. While this is not an exact measure of live Drupal sites we can infer that the affected number of specifically vulnerable Drupal 7 sites is more likely to be under 1 million.

SA-CORE-2014-005 was certainly a severe issue, if not the most severe issue in Drupal’s history; but it’s important to recognize all software has bugs and security issues that require a remediation process. Finding, fixing and announcing security patches is evidence of a healthy security process and Drupal is one of the few content management systems with a dedicated security team that covers both Drupal core and contributed code.

The above said, there are lessons from both the original disclosure and the follow-up PSA that might result in some changes to the Drupal Security Team policy and process, however we want to reinforce that we are deeply committed to keeping Drupal secure. We encourage you to read this whitepaper that explains our processes, policies and contains a good overview of Drupal security.

If you ever have questions, please use the public discussion area for general topics at https://groups.drupal.org/security or contact us (security@drupal.org). Or better yet, get involved. You can find more information on the Drupal Security Team page.

-Drupal Security Team

Comments

greggles’s picture

Thanks for writing this up, Michael and Joe and others!

Charles Belov’s picture

As of 10:37 am PST December 5, 2014, the link "whitepaper" goes to the Drupal Security front page, not to a white paper.

Charles Belov
SFMTA Webmaster
http://www.sfmta.com/

sayantanlaha’s picture

Thanks Team for this update.....

chrisck’s picture

Thanks for the message. We appreciate the work of the Drupal community and I still stand firmly behind it.

tauseef.gill’s picture

thank you for writing this follow up.
you mention about some changes to the Drupal Security Team's policy and process, do you know when these changes can happen?

Anybody’s picture

Thanks a lot for your great work. You're doing a very good job!

http://www.DROWL.de || Professionelle Drupal Lösungen aus Ostwestfalen-Lippe (OWL)
http://www.webks.de || webks: websolutions kept simple - Webbasierte Lösungen die einfach überzeugen!
http://www.drupal-theming.com || Individuelle Responsive Themes

caseypaul’s picture

very good

Satraa’s picture

The extensive attention which this issue received was enough to worry lot of Drupal site owners. However, the timely communications from d.o helped vendors tackle their concerns in a great way. Thanks.

kbrackson’s picture

Thanks for keeping us safe :)

cmak’s picture

Thanks for letting us know the exact facts and patch release :)

Senior Drupal Developer
Skype me on : mak_chavan
Email : Makarand Chavan