Уязвимость SQL-инъекции варианта продукта Drupal Commerce

Сканирование PCI на моем сайте говорит, что существует уязвимость SQL Injection. Но там, где это, кажется, указывает на довольно базовую функциональность Commerce. При непосредственном посещении страницы вариантов продукта она добавляет v=nn на URL, чтобы показать выбранный вариант.

Это сканирование предполагает, что такие URL-адреса, как:

?v=54+или+5459%3D5459&page=1

?v=54+или+6721%3D8812&page=1

... вернуть TRUE и FALSE соответственно (вернуть куда, я не совсем уверен).

Это вполне нормальное поведение Drupal Commerce по умолчанию, если я не ошибаюсь. Возможно ли, что это ложное срабатывание этого сканирования PCI?

Я знаю, что не добавлял на этот сайт никаких пользовательских запросов.Помимо тем, это довольно нестандартное поведение. И я не думаю, что использую параметр v= напрямую ни в одной из своих тем.

Мне жаль, что это расплывчато и общее, но я ищу дополнительную информацию о том, как решить этот результат PCI.

Заранее спасибо!

?v=54+или+5459%3D5459&page=1 и ?v=54+или+6721%3D8812&page=1 разрешит SQL-инъекция если код, выполняющий запрос, будет использовать значения, переданные в URL-адресе, без их фильтрации, как, например, следующий код. (Это не тот код, который использует модуль. Это просто код, который позволяет выполнять SQL-инъекцию.)

$statement = "выберите * из product_variation pv WHERE pv.id = {$_GET['v']}"; 

Запросы SQL будут по существу эквивалентны, соответственно, следующим.

выберите * из product_variation pv, где pv.id = 54 или 5459 = 5459

выберите * из product_variation pv, где pv.id = 54 или 6721 = 8812

Первый SQL-запрос вернет все строки в product_variation базу данных, а второй запрос вернет только ту строку, для которой ID равен 54.

Ядро Drupal и вспомогательные модули не объединяют значения, переданные от пользователя (даже через URL-адрес), с литеральными строками для построения строки SQL, а используют правильную замену аргументов, что делает невозможным внедрение SQL.
Они также не позволяют пользователям указывать какой-либо оператор для условия запроса, но устанавливают список разрешенных операторов и разрешают пользователям использовать только их.

Сканирование PCI заметило, что оно дало два разных результата (ПРАВДА и ЛОЖНЫЙ) с использованием ?v=54+или+5459%3D5459&page=1 и ?v=54+или+6721%3D8812&page=1, интерпретируется ПРАВДА как есть строки, соответствующие запросу и ЛОЖНЫЙ как нет строк, соответствующих запросу, и подумал, что SQL-инъекция прошла успешно. (Как сканирование PCI может сказать, что доступ к URL-адресам, содержащим этот параметр запроса, вернет ПРАВДА и ЛОЖНЫЙ мне тоже непонятно))

Это не то, что произошло. То, что сообщает сканирование, является ложным срабатыванием.