by David Snopek on November 13, 2019 - 8:44pm

You may have noticed that today the Drupal Security Team marked 16 modules as unsupported, due to the module maintainer not fixing a reported security vulnerability after a sufficiently long period of time.

Among those modules, there were a few very popular ones like Admininistration Views and Nodequeue, which have have reported ~118k and ~40k sites using them, respectively.

Everytime a popular module is unsupported, there's a certain amount of panic and uncertainty, so I wanted to address that in this article, both for the Drupal community at large, and for our customers in particular, because we promise to deploy security updates the same day they are released.

Read more to see our perspective!

Why does this happen? Why all at once?

For modules supported by the Drupal Security Team, security vulnerabilities are reported to a private issue tracker.

The Security Team's job is to make sure that the process is followed, security advisories (SA's) get written, and ultimately publishing the SA's, releases and the various notifications.

It's actually the module maintainer's job to fix the vulnerability, write the first draft of the SA, and create the release.

If a module maintainer is unresponsive, the security team will tell the module maintainer that they have 2 weeks to post an update. Since this is an Open Source project, and most maintainers are volunteers doing this in their free time, they frequently get much more than 2 weeks.

When there aren't any other big security releases, and the security team has time to do it (the security team is also volunteers!), they go through all the modules that got the 2 week warning and didn't respond, and mark all of them as unsupported. That's why they tend to come out in groups.

How should I react if I depend on one of these modules?

In an SA about a module becoming unsupported, there are two recommended actions:

  • Uninstall the module, or
  • Apply to become the maintainer of the module and fix the vulnerability

There's actually a 3rd possible action that can apply to very popular modules:

  • Wait for a new maintainer to be found and a fixed version to be released

When modules become unsupported, especially if it's a popular module, there can be some amount of panic. And in a way, that's good!

For popular modules, the security team will sometimes search for a new maintainer through private channels before marking a module as unsupported, but it's hard to do because the details need to remain confidential.

If that doesn't work out, marking a module as unsupported is a more public way to advertise for a new maintainer - and because of the added urgency/panic - it frequently works!

Now, if you depend on a module, and have the skill and time to become the maintainer, you should absolutely consider applying to maintain the module!

But if you don't, it can be reasonable to wait a few days to see if a new maintainer steps up, before taking the drastic step of uninstalling the module. Right when the SA is published, the details of the vulnerability are still private, and unless stated in the SA, there aren't any known instances of the the vulnerability being exploited in the wild.

However, after a period of time, the security team may publish the details of the vulnerability publicly, or attackers may figure it out on their own, so you can't wait forever! But waiting a few days is not an unreasonable calculated risk.

How we handle this with our customers?

It depends on the situation.

For a very popular module, where we're pretty certain a new maintainer will step up, we'll usually wait a few days. (We also have an idea of the security risk in the vulnerability, because we have a security team member on staff, so that's taken into account as well.)

In some cases, we may even offer to maintain the module ourselves.

And, in other cases, like for really unpopular modules, we'll tell our customers that they should uninstall it and replace it with an alternative module or custom code. That's something we can help our customers to do, however, it's only included in our support plans that have a bucket of developer hours - for other customers, we'll need to do a paid mini-project for a few hours.

For our Drupal 6 Long-Term Support (D6LTS) customers, we also have the option of waiting until the vulnerability is made public, and then we can make a D6LTS patch for it, even if the Drupal 7 or 8 module is still unsupported without an active maintainer.

But no matter the situation, we hope to help our customers be ready for whatever may happen. :-)

Want to read more articles like this?


Subscribe to the blog and recieve e-mail updates when new articles are published!


A good occasion to express appreciation for the Drupal security team. The impression is that in the last couple of years their role has become a more pro-active one. It makes Drupal much easier "to sell" as a corporate solution.

Thanks for sharing some insight into the aftermath of a module going unsupported due to a security issue.

Thanks, this was super helpful. I’m feeling calmer about Admininistration Views now ...

Is the public able to see the security team's issues once a module is marked as no longer supported so that we can be sure we aren't duplicating the security bug in a custom module?

If no new maintainer is found, the issue may be made public 30 days after the module was unsupported.

However, I'm not sure that's the best source for learning how to write secure Drupal code! There's some official docs:

Also, security concerns with the individual APIs are called out in the documentation for those methods.

And there's a ton of Google'able information out there too.

Add comment