Drupalgeddon 2.0 & Drupal Security
A little more than one month ago, the Drupal Security team alerted the Drupal community that a necessary security update was on its way to fix a major vulnerability that put more than one million Drupal-run websites at risk.
Dubbed Drupalgeddon 2.0 for its potential severity, the patch was designed for Drupal Core and developed to put a stop to the bug before it could inflict much damage.
Drupal has a ranking system to demonstrate the security risk of operating without these types of updates; Drupalgeddon 2.0’s ranking was a 24 out of 25 and deemed highly critical. That means if sites were not updated, hackers could relatively easily access private data housed within the site, or even take over the site, its content and its appearance altogether.
The only update more critical in the history of Drupal came in 2014 with the arrival of Drupalgeddon.
To the credit of the Drupal Security team, this problem was caught without too much damage, and an update was able to be created before most people even knew a problem existed. I’ve written about how security — and specifically the efforts of the Drupal Security team — is a huge benefit of Drupal, since they do an amazing job reviewing Drupal for security vulnerabilities and coordinating releases in such a way that we're able to keep all of our client sites protected.
The security team did a fantastic job alerting the Drupal community of the issue while being discreet about the details of the vulnerability until the patch's release. This is important because if the information had leaked, Drupal sites could have come under attack before the community was prepared for the patch. There’s a tricky balance of acknowledging the need for the update but not sharing much information about it, and the Drupal security team handled it very well.
Our team at Duo worked together to quickly apply the fix and then run each of our client’s sites through QA (quality assurance) to ensure that nothing broke with the update. One of our client sites did have some issues with the update, but we were able to quickly assess what the patch was doing and implement a fix for that site so there was little delay in getting the updated site deployed to production.
The process was extremely seamless for our clients. While we were transparent with our clients about the need to apply a fix to their sites, we smoothly handled the upgrade process so that clients did not have to spend any time thinking about the vulnerability. Their sites also had absolutely no downtime, which was obviously appreciated.
Overall, as I look back at how we reacted, I think our Duo team handled Drupalgeddon 2.0 amazingly well. The team was able to monitor and collaborate on the update progress of each site and help out as needed.
We pride ourselves on having a senior-level team here at Duo; as a result, all of us went through the first Drupalgeddon back in 2014, and we’ve have handled plenty of Drupal security updates since then. That experience definitely was a major contributing factor in how well and efficiently we were able to execute once the patch was released.