slo-cyber-sec/cve-2026-78850Prova de conceito demonstrando um SSRF cego autenticado no SiteContentDetector do Matomo, permitindo reconhecimento de rede interna e requisições a serviços internos por meio de URLs de site manipuladas.
Nome: CYBER-SEC
Contato: [email protected]
O Matomo permite que um administrador de site autenticado configure o main_url de um site com um endereço interno. Qualquer usuário autenticado com acesso de visualização pode posteriormente acionar getTrackingMethodsForSite, fazendo com que o servidor execute uma solicitação HTTP cega para a URL configurada.
O destino é validado apenas com proteções baseadas em nome de host e não rejeita adequadamente endereços loopback, RFC1918 ou link-local após a resolução. Como resultado, o aplicativo pode ser abusado para realizar solicitações cegas do lado do servidor para serviços internos.
Produto: Matomo
Versão afetada: 5.11.2 verificada
Componente: SiteContentDetector / SitesManager
Vetor: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Pontuação Base: 5.8 Média
enable_internet_features deve estar habilitado.main_url do site.O problema envolve o seguinte fluxo:
Origem:
SitesManager.updateSite armazena main_url após validação básica de URL.
Gatilho:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>
Sumidouro:
SiteContentDetector::requestSiteResponse()
-> Http::sendHttpRequestBy()
A implementação não rejeita adequadamente destinos internos, como:
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
Os destinos de redirecionamento também devem ser revalidados, pois a filtragem baseada em nome de host pode ser contornada se o nome de host permitido inicialmente redirecionar para um endereço interno.
Use um listener que você controla em um ambiente de laboratório autorizado:
python3 -m http.server 8088
Como administrador de site autenticado, configure o main_url do site para apontar para o listener interno controlado:
http://<listener-interno-controlado>:8088/ssrf-test
Não teste contra sistemas de terceiros ou endpoints de metadados de nuvem, a menos que você seja o proprietário e esteja autorizado a testar esse ambiente.
Como usuário autenticado com permissão de visualização, acione:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1
O listener controlado recebe uma solicitação HTTP do lado do servidor proveniente do servidor Matomo.
Exemplo de saída do listener:
GET /ssrf-test HTTP/1.1
Host: <listener-interno-controlado>:8088
User-Agent: Matomo
O Matomo executa uma solicitação GET do lado do servidor para o main_url configurado quando getTrackingMethodsForSite é acionado.
Isso foi verificado usando um listener HTTP interno de loopback que não era acessível externamente, confirmando o comportamento de SSRF cego.
Um atacante autenticado pode abusar desse comportamento para:
Como o SSRF é cego, o atacante não recebe diretamente o corpo da resposta HTTP por meio do Matomo. No entanto, apenas a entrega da solicitação já pode ser relevante para a segurança em redes internas e ambientes de nuvem.
Correções recomendadas:
Resolva o nome de host para endereços IP antes de fazer a solicitação.
Rejeite faixas de IP privadas, loopback, link-local, multicast e outras faixas inseguras após a resolução de DNS.
Revalide cada destino de redirecionamento antes de seguir os redirecionamentos.
Prefira uma allowlist estrita de domínios de saída permitidos em vez de blocklists de nomes de host.
Aplique proteções de SSRF de forma consistente no sumidouro final da solicitação HTTP, não apenas durante a configuração da URL do site.
Considere restringir getTrackingMethodsForSite ou o gatilho do SiteContentDetector a usuários com privilégios mais elevados.
Adicione registro de auditoria para solicitações de saída do lado do servidor acionadas pela configuração do site.
Verificado contra a imagem Docker oficial do Matomo 5.11.2 sem modificar o código-fonte.
Este problema foi relatado pela CYBER-SEC.