This issue was discussed by the Drupal Security Team, and their decision was that this can be solved in a public issue.
This module has a XSS vulnerability in its AJAX handling, similar to this recent Drupal core SA: https://www.drupal.org/sa-core-2020-007 →
The views-autocomplete-filters-dependent.js uses jQuery's $.ajax and where the AJAX url could potentially be controlled by an attacker.
Original report from reporter @millionleaves:
--------------------------
I'm using VirusDie as a malware scanner on a D7 site running D7.73.
It's reporting a vulnerability in this plugin, in line 7 of
views-autocomplete-filters-dependent.js, which it says is related to this
security advisory (which the 7.73 core release addressed):
https://www.drupal.org/sa-core-2020-007 →
The function it has flagged starts with this line:
Drupal.ACDB.prototype.search = function (searchString) {
I don't know if this is a false positive or if this function is actually
vulnerable. Thought I'd raise it here before checking with VirusDie support.
Unable to determine how to exploit this.
@mr.baileys commented
> This seems like a false positive. The module correctly escapes the supplied input used as part of the autocomplete-URL. Since there is no way to add "=?" or "??" to the URL to force a callback function, I don't think there is a way to exploit this or promote the request to JSONP. Adding "jsonp: false" to the call still seems sensible, but does not seem necessary in this case and should be considered (public) security hardening.
$.ajax({ type: 'GET', url: db.uri + '/' + Drupal.encodePath(searchString), ...
>
> Example URL when attempting to pass a callback-function:
>
> http://d7.ddev.site/index.php?q=autocomplete_filter/title/content/page/0..."
@ram4nd added a patch.
Active
1.0
Code
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
As Drupal 7.x and also modules 7.x versions "ended their lives", closing the 7.x issues.
And thanks for participating and using the module.
p.s. if this still an issue on the latest 2.x version, please feel free to re-open and update the version accordingly.
p.s.2. I know it's a S issue ... but ...