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 Apache Solr per TYPO3 (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 specifici operatori di query—come wildcard (*), wildcard a carattere singolo (?), 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 i campi 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 --> 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')
?L'operatore wildcard a 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 (Checks for 12+ characters)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Checks for 13+ characters)
[a TO z])Le query di intervallo consentono l'estrazione tramite ricerca binaria sul carattere iniziale, riducendo il numero di richieste necessarie da 26 a ~5 per posizione del carattere:
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 combinazione di rilevamento della lunghezza, query di intervallo e wildcard di prefisso consente l'estrazione completa del campo con un'impronta di richiesta minima.
Viene fornito uno script di verifica automatizzato (poc.py) per dimostrare l'estrazione cieca utilizzando le tecniche descritte sopra.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: URL di destinazione che punta all'endpoint di ricerca TYPO3.
-f, --field: Nome del campo dello schema da enumerare/estrarre (ad es., appKey, siteHash).
-c, --cookies: (Opzionale) Cookie di sessione se è richiesta l'autenticazione o la verifica del bypass del WAF.
-o, --output: File di output in cui memorizzare i prefissi scoperti (predefinito: validated_fields.txt).
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]).