slo-cyber-sec/cve-2026-78850Proof-of-concept che dimostra una SSRF cieca autenticata nel SiteContentDetector di Matomo, consentendo la ricognizione della rete interna e l'invio di richieste a servizi interni tramite URL di siti appositamente costruiti.
Nome: CYBER-SEC
Contatto: [email protected]
Matomo consente a un amministratore del sito autenticato di configurare il main_url di un sito con un indirizzo interno. Qualsiasi utente autenticato con accesso in visualizzazione può successivamente attivare getTrackingMethodsForSite, causando l'esecuzione da parte del server di una richiesta HTTP cieca all'URL configurato.
La destinazione viene validata solo con protezioni basate sul nome host e non rifiuta correttamente indirizzi loopback, RFC1918 o link-local dopo la risoluzione. Di conseguenza, l'applicazione può essere abusata per eseguire richieste server-side cieche verso servizi interni.
Prodotto: Matomo
Versione interessata: 5.11.2 verificata
Componente: SiteContentDetector / SitesManager
Vettore: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Punteggio Base: 5.8 Medio
enable_internet_features deve essere abilitato.main_url del sito.Il problema coinvolge il seguente flusso:
Sorgente:
SitesManager.updateSite memorizza main_url dopo una validazione URL di base.
Attivazione:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>
Sink:
SiteContentDetector::requestSiteResponse()
-> Http::sendHttpRequestBy()
L'implementazione non rifiuta correttamente destinazioni interne come:
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
::1
fc00::/7
fe80::/10
Anche le destinazioni di reindirizzamento dovrebbero essere rivalidate, perché il filtraggio basato sul nome host può essere aggirato se il nome host iniziale consentito reindirizza a un indirizzo interno.
Utilizzare un listener che si controlla in un ambiente di laboratorio autorizzato:
python3 -m http.server 8088
Come amministratore del sito autenticato, configurare il main_url del sito per puntare al listener interno controllato:
http://<listener-interno-controllato>:8088/ssrf-test
Non testare contro sistemi di terze parti o endpoint di metadati cloud a meno che non si possieda e non si sia autorizzati a testare quell'ambiente.
Come utente autenticato con permesso di visualizzazione, attivare:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1
Il listener controllato riceve una richiesta HTTP server-side dal server Matomo.
Esempio di output del listener:
GET /ssrf-test HTTP/1.1
Host: <listener-interno-controllato>:8088
User-Agent: Matomo
Matomo esegue una richiesta GET server-side all'main_url configurato quando viene attivato getTrackingMethodsForSite.
Ciò è stato verificato utilizzando un listener HTTP interno loopback/interno non raggiungibile esternamente, confermando il comportamento di blind SSRF.
Un attaccante autenticato può abusare di questo comportamento per:
Poiché l'SSRF è cieco, l'attaccante non riceve direttamente il corpo della risposta HTTP tramite Matomo. Tuttavia, la sola consegna della richiesta può comunque essere rilevante per la sicurezza in reti interne e ambienti cloud.
Correzioni consigliate:
Risolvere il nome host in indirizzi IP prima di effettuare la richiesta.
Rifiutare intervalli IP privati, loopback, link-local, multicast e comunque non sicuri dopo la risoluzione DNS.
Rivalidare ogni destinazione di reindirizzamento prima di seguire i reindirizzamenti.
Preferire una allowlist rigorosa di domini in uscita consentiti invece di blocklist di nomi host.
Applicare le protezioni SSRF in modo coerente al sink finale della richiesta HTTP, non solo durante la configurazione dell'URL del sito.
Valutare la possibilità di limitare getTrackingMethodsForSite o l'attivazione di SiteContentDetector agli utenti con privilegi più elevati.
Aggiungere registrazione di audit per le richieste server-side in uscita attivate dalla configurazione del sito.
Verificato contro l'immagine Docker ufficiale di Matomo 5.11.2 senza modificare il codice sorgente.
Questo problema è stato segnalato da CYBER-SEC.