Resumo

O UnPoller suporta carregar credenciais de um arquivo quando o valor de configuração começa com file://. Esse comportamento é documentado para implantações Docker onde operadores desejam senhas fora de arquivos de configuração em texto simples. A implementação não restringe qual caminho pode ser lido — qualquer arquivo que o processo possa acessar é uma entrada válida. Esse conteúdo é então enviado pela rede em um POST JSON para /api/login no controlador cujo url está definido no mesmo arquivo de configuração.

Essa combinação transforma uma primitiva de leitura local de arquivo em um canal de exfiltração de rede: um invasor com acesso de escrita ao up.conf pode apontar url para um servidor que ele controla e vazar repetidamente arquivos sensíveis sem permissão de leitura direta nesses arquivos.

Contexto

Eu executo o UnPoller no meu homelab — Docker em um Proxmox LXC — para exportar métricas do UniFi para o Grafana junto com o restante da minha stack. Eu estava revisando projetos open-source em busca de vulnerabilidades web comuns. O UnPoller tem uma superfície webvoltada ao usuário mínima, então XSS era um beco sem saída. A configuração de exemplo é onde a descoberta começou:

A intenção é razoável: referenciar um arquivo de segredos em vez de incorporar a senha no up.conf. A questão que eu tinha era se o UnPoller valida esse caminho — ou trata qualquer valor file:// como um ponteiro literal do sistema de arquivos.

Rastreando a fonte em pkg/inputunifi/input.go (e manipulação semelhante em influxunifi, lokiunifi) mostra que não há lista de permissões. Quando pass ou api_key começa com file://, o prefixo é removido e os.ReadFile() carrega o conteúdo completo do arquivo no campo de credencial usado para autenticação no UniFi.

Impacto

Confidencialidade: Arquivos legíveis arbitrários no host do UnPoller podem ser exfiltrados — por exemplo, /etc/passwd, /proc/version, /etc/hosts, configurações de aplicação e potencialmente material de chave dependendo das permissões do processo.

Pré-requisitos do ataque: Acesso de escrita à configuração do UnPoller (tipicamente up.conf). Nenhuma credencial UniFi é necessária para acionar a leitura após a modificação da configuração.

Por que isso importa além do acesso de administrador local: Em hospedagem compartilhada, Kubernetes mal configurado ou cenários de sidecar comprometido, um ator com privilégios baixos pode ser capaz de modificar a configuração do serviço sem conseguir ler arquivos sensíveis diretamente. Esse comportamento preenche essa lacuna fazendo o UnPoller ler o arquivo e transmiti-lo para fora.

Fora do escopo: Execução remota de código, integridade ou disponibilidade — isso é um problema de divulgação de informações com um caminho claro de exfiltração.

Prova de Conceito

Testado contra ghcr.io/unpoller/unpoller:latest (v2.33.0) em um Proxmox LXC baseado em Debian com Docker Compose.

O que não funcionou

Definir UP_UNIFI_DEFAULT_PASS="file:///etc/passwd" via variável de ambiente não acionou o comportamento na minha implantação. O arquivo de configuração montado era a fonte de verdade efetiva.

O que funcionou

Editei o up.conf para apontar o UnPoller para um servidor de captura que eu controlava em vez do meu controlador UniFi de produção:

Após docker restart unpoller, o container começou a se conectar ao meu listener na porta 8443 a cada ~30 segundos.

Capturando a exfiltração

Meu primeiro servidor de captura registrava cabeçalhos HTTP e procurava por credenciais Authorization: Basic .... O UnPoller enviou requisições POST /api/login sem cabeçalho Authorization — a API do UniFi espera JSON no corpo:

Atualizei o listener para ler Content-Length, analisar o corpo do POST e registrar o JSON. Em menos de um minuto, /etc/passwd apareceu no campo de senha:

Trecho do log:

O mesmo padrão de configuração funcionou para /proc/version (fingerprinting do kernel/build):

Exemplo de configuração maliciosa: poc/up.conf.example

Linha do Tempo da Divulgação

O mantenedor do UnPoller reconheceu o comportamento file:// como uma conveniência intencional para usuários Docker e questionou a explorabilidade sem separação de privilégios entre o editor de configuração e o usuário do processo. O MITRE atribuiu um identificador CVE independentemente.

Remediação

Para operadores

• Trate up.conf e montagens de configuração como sensíveis; restrinja o acesso de escrita.
• Garanta que o UnPoller só possa alcançar endpoints de controladores UniFi confiáveis.
• Prefira segredos Docker, segredos Kubernetes ou injeção de credenciais baseada em ambiente em vez de caminhos file:// arbitrários até que uma correção esteja disponível.

Para desenvolvedores

• Remova a manipulação irrestrita de file:// dos campos de credenciais, ou aplique uma lista de permissões de caminho estrita (por exemplo, apenas em /etc/unpoller/secrets/).
• Falhe de forma segura quando um arquivo de segredos configurado não puder ser lido — não substitua silenciosamente por uma senha vazia.
• Documente o modelo de ameaça se as credenciais baseadas em arquivo permanecerem suportadas.

Referências

• CVE-2026-36851
• UnPoller
• CWE-22 · CWE-20

Licença

MIT — veja LICENSE. Os materiais de prova de conceito neste repositório são fornecidos apenas para pesquisa de segurança autorizada e educação. Não use contra sistemas que você não possui ou para os quais não possui permissão explícita para testar.

Hector Diaz · LinkedIn · hectordiaz.net