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.
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.
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.