Oh hey, Elijah! I found out about this HN post because my friend wrote to me about it, so I guess you're doing a good deed for the community.

I want to note that these vulnerabilities are in 3 Drupal 7 contributed modules:

RESTWS (we personally never used this, but it has 5k installs)

Coder (we use its scripts all the time, but install it only in Dev environment, not in Drupal codebase. However, we did have a client with 3 projects running it, and they're patching it now)

Webform Multiple File Upload (we never used this, but it has 3k installs)

So for context, this isn't exactly "Drupalgeddon 2.0", but if you know someone who uses Drupal 7, they should check if they're using these modules, and update them.

Small addition re: Coder: It's not necessary for the module to be enabled in order to be exploitable, it just has to be somewhere in your document root[1]. If you share the same code base between dev and production, you might be vulnerable even if it's disabled in production.

[1]: https://twitter.com/drupalsecurity/status/753263548458004480

Thanks for posting that very important point about the Coder module. We were mitigated by the fact we used Composer to install an internal distribution and Coder was in our /vendor/drupal/coder directory, not inside docroot.

Sup Alex! Small world. Thanks for posting details in here, I should have done that after posting but it was my first time posting and I didn't think to put it in a comment.

Question from a non-Drupal dev here: this notice deals with third-party modules that don't sound like they'd be ubiquitous for deployments. But it's in the PSA section in which has few posts overall, and seems to focus on Drupal core. Am I underestimating the install base, or overestimating the likelihood of 3rd-party modules having security holes?

(It doesn't seem that WordPress's security section concerns itself with plugin flaws...because if it did, that's be a pretty busy section...)

Edit: Ok this I was also wondering: are these flaws a result of something related to Drupal core?

https://news.ycombinator.com/item?id=12088471

Is it standard for Drupal to not disable web access to disabled plugins? Or is this notice for the rare edge custom deployments in which default safeguards are disabled? How can a non-admin reach a disabled plugin (nevermind execute it)?

New(ish) projects using popular PHP frameworks typically have all their code stored somewhere outside of the web server's document root - there's usually just a single PHP file in the document root that's responsible for instantiating a front controller or bootstrapping the app in some other way, with a .htaccess (or similar) file telling the web server to redirect all requests to that file.

Drupal (and WordPress, etc.) come from a time where your entire code base would live in the document root, so knowing the path to a .php file is often enough to execute the script. While it would be possible to limit this with something like .htaccess, it's error-prone, web server-specific, and can break existing code in your ecosystem, so that's probably why it's not being done consistently. Changing the code structure of Drupal in a way that would put most of the code outside of the document root would similarly cause a lot of work for the ecosystem and might make installation in typical shared web hosting environments impossible in some scenarios - I've seen hosters who only allow you to upload files straight to the document root, so there'd be no way to use such a project with those plans. This is in essence just another case of things going wrong because compatibility was prioritized over possible security concerns, and I don't even want to blame them too much for that, given the usual outcry when backwards-incompatible changes cause work for (plugin) developers in general.

I think the confusion here is that there are three types of advisories: Core issues, contrib issues, and PSAs. You're probably looking at yesterday's PSA saying "watch out for an important advisory tomorrow" and wondering why there aren't more advisories. It's because they're in the other two sections.

It is certainly standard for code in disabled plugins not to be accessible via Drupal. The problem in this case is that the plugin's authors wrote a separate script having nothing to do with Drupal itself, and made it web-accessible. That's pretty unusual for contributed code.

Looks like a very small number of sites are affected (1,000 - 10,1000 out of 1.2 million total[1]). Nonetheless, it's a serious bug and to be safe it's probably advisable to assume that your site is vulnerable if it is running Drupal.

1: https://www.drupal.org/project/usage/drupal

If you found software to switch to that is free of security issues, I imagine we would all be interested to know what it is.

While you can't make software perfectly secure you can make security updates as easy as possible. Drupal is exceptionally bad at this. IMHO Wordpress does the right thing with its auto updates. That still doesn't solve the problem for plugins, but it's probably prevented a lot of hacked sites. I think a CMS without an autoupdate functionality cannot be recommended for general use these days.

Drupal has a built-in update mechanism and it's been around for years. Administrators receive update notifications via email, they're surfaced in the status page, and there's a site-wide admin notification on every page when there's a security release available.

You can update both core and modules (similar to plugins for WordPress) using the web interface, which is included with core, or use a command-line utilities like Drush for Drupal 7, or Composer in Drupal 8.

There's lots of very valid reasons to be critical of Drupal, but:

> Drupal is exceptionally bad at this.

I don't think that's accurate.

The audacity of having a system for secure reporting of security issues, with the follow-through on fix development and mitigation, release coordination and announcements, and transparency? That's an asinine reason to "ban" it.