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 arbitraria de consultas 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 operadores de consulta específicos —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.
Debido a que estos caracteres se pasaban directamente a la construcción de la consulta del backend sin una lista blanca de aplicación ni una capa de abstracción de consultas, un atacante puede proporcionar sintaxis específica de campos para escapar de los límites de búsqueda previstos. Esto permite a usuarios no autenticados consultar campos internos de Solr directamente 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 utilizando inferencia booleana:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Devuelve resultados de búsqueda (El valor comienza por 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nothing found" (El valor no comienza por '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 (Comprueba 12+ caracteres)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Comprueba 13+ caracteres)
[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 --> Determina si el carácter está dentro de 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determina si el carácter está dentro de 'n'-'z'
Combinar la detección de longitud, las consultas de rango y los comodines de prefijo permite la extracción completa de campos con un número mínimo de solicitudes.
EXT:solr.El escape global de caracteres es insuficiente porque operadores como * y : cumplen funciones de búsqueda previstas. La remediación requiere una lista blanca en la capa de aplicación y un modelo de análisis sintáctico:
[email protected]).