yairhinkis/cve-2026-56096Prova de conceito e análise técnica para CVE-2026-56096, uma injeção cega de consulta Solr no TYPO3 EXT:solr que permite enumeração de campos e extração de dados sem autenticação.
Uma vulnerabilidade de segurança arquitetural foi descoberta na extensão oficial do TYPO3 Apache Solr (EXT:solr / apache-solr-for-typo3/solr). O problema permite que atacantes remotos não autenticados injetem sintaxe de consulta Solr/Lucene arbitrária através do parâmetro de busca tx_solr[q], possibilitando enumeração cega não autorizada de campos e extração completa de metadados do índice de busca.
EXT:solr (Parâmetro de busca: 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:NA extensão EXT:solr aceita termos de busca fornecidos pelo usuário através do parâmetro tx_solr[q] e os encaminha para o motor Apache Solr. Por design, a extensão permite operadores de consulta específicos—como curingas (*), curingas de caractere único (?), seletores de campo (:) e consultas de intervalo ([a TO z])—para suportar funcionalidades legítimas como filtragem facetada.
Como esses caracteres eram passados diretamente para a construção da consulta de backend sem uma lista de permissões restritiva ou camada de abstração de consulta, um atacante pode fornecer sintaxe específica de campo para escapar dos limites de busca pretendidos. Isso permite que usuários não autenticados consultem campos internos do Solr diretamente e extraiam dados do índice usando técnicas cegas baseadas em booleanos.
field:*Ao anexar um curinga a um nome de campo arbitrário ou adivinhado, um atacante pode verificar se o campo existe dentro do esquema:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Se o campo existir, o Solr processa a consulta em todos os registros correspondentes (frequentemente acionando códigos de resposta distintos ou comportamentos relacionados ao volume), permitindo enumeração automatizada de campos baseada em wordlist.
Atacantes podem extrair valores de campos sensíveis caractere por caractere usando inferência booleana:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Retorna resultados de busca (Valor começa com 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nada encontrado" (Valor não começa com 'b')
?O operador curinga de caractere único (?) pode determinar o comprimento exato de uma string armazenada antes de iniciar a iteração de caracteres:
GET /search?tx_solr[q]=siteHash:????????????* HTTP/1.1 (Verifica 12+ caracteres)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Verifica 13+ caracteres)
[a TO z])Consultas de intervalo permitem extração por busca binária no caractere inicial, reduzindo as requisições necessárias de 26 para ~5 por posição de caractere:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Determina se o caractere está entre 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determina se o caractere está entre 'n'-'z'
Combinar detecção de comprimento, consultas de intervalo e curingas de prefixo permite extração completa de campos com um footprint mínimo de requisições.
EXT:solr.O escape global de caracteres é insuficiente porque operadores como * e : servem a funcionalidades de busca pretendidas. A remediação requer uma lista de permissões na camada de aplicação e um modelo de parsing:
[email protected]).