Security vulnerability in #Drupal contrib module puts 120000 sites at risk
drupal.sh
drupal.sh
They do offer an alternative (Entity Reference) and asked if anyone would patch or maintain the module. They also added a warning on the module's page.
Maybe that's what should happen, but it's not what will happen.
The module is unmaintained. Who do you suggest should do it? Will you? If not then you're just demanding that work should be done somewhere, by someone else, without providing any path or resources for it. That's just not how freely contributed and shared labour works.
It's a risk you take on when you use that free resource, and why it matters to contribute back to the ecosystem that you're using free of charge. Frankly, if you've been using the freely available module for this long then you're already ahead of where you were before.
"This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution to the problem, and nobody owes you anything more.
Yes. I am contacting the security team and working on a patch already. The page mentions someone is currently working on the issue already however.
> "This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution.
I don't completely agree. If it's unmaintained, new installations shouldn't use it, totally agree. That doesn't help the 120K installations which are using the plugin though. It may take more time to impedance match apis, rather then fixing the security issue.
The joke around the ops/security team was Drupal is a remote shell with a bonus CMS attached to it.
You sure you saw it correctly? Concatenation of hardcoded variants (poor-mans query builder) doesn't make an injection.
The problem is in that function though. It is missing a condition for publication status. Titles of unpublished nodes should render for some users, but not all.
No, it's known for its ridiculous number of security issues and sloppy code :/
That of course does not include Drupal modules - there is, similar to the Wordpress ecosystem, the really bad stuff.
I can see the advantage of it, you just focus on the core and let the world take care of its own problems but you end up with nearly every site being critically dependent on a couple of obscure modules that will not get the attention they need until it is much too late. This coupled with Drupals nasty habit of obsoleting everything every couple of year (I hear they are changing now) and you're set up for disaster.
So even if Drupal Core is not all that bad it is never just Drupal Core.
If you don't do that it becomes a 'find the last hole in the cheese' exercise and very likely there will be many holes that you don't find that way that would not have been there in the first place had the whole thing been designed from day one with that in mind.
On the whole I think 'let amateurs build it and experts vet it' is better than just 'let amateurs build it' but it doesn't come close to 'let experts build it and experts vet it'.
Wait, are you talking about npm or Drupal? (only kind of kidding)
Seriously. A standard ES6 JS project will run you to actual hundreds of packages. Thats a huge attack surface.
Also: https://www.lullabot.com/articles/why-paid-drupal-modules-fa...
The correct answer here is that if you don't like Drupal's free & community-focused development model, you're likely better off switching to some off-the-shelf software. Alternatively, you can pay a consulting company to maintain the module, which is how many of them get written anyway (and then given away for free). So if you focus on modules with commercial backing, you've got a pretty close approximation without giving up GPL freedoms.
With Drupal, on the other hand, I've always had to install a whole bunch of contrib modules just to get the basic functionality I needed. Has that changed significantly since Drupal 6 and 7?
Am I underestimating how insecure Wordpress core is, even considering that the get the equivalent you'd need Drupal plus a whole bunch of modules?
(Emphasis mine)