O seu servidor MLflow está exposto? A falha que já anda a roubar credenciais cloud

Uma vulnerabilidade crítica no MLflow, uma das plataformas open source mais usadas para gerir o ciclo de vida de modelos de machine learning e de aplicações de IA, está a ser explorada em ataques reais poucas horas depois de ter recebido identificador CVE. A agência norte-americana CISA adicionou a 19 de agosto de 2026 a CVE-2026-64849, descrita como uma vulnerabilidade de Server-Side Request Forgery no MLflow, ao seu catálogo de vulnerabilidades exploradas (KEV). O problema afeta todas as versões anteriores à 3.15.0 e permite que um atacante sem autenticação force o servidor a contactar serviços internos ou pontos de metadados de nuvem, devolvendo-lhe o estado e o corpo da resposta — o que, na prática, abre caminho ao roubo de credenciais temporárias de cloud.

O que falha exatamente no MLflow

O problema vive na funcionalidade de webhooks do registo de modelos. Num MLflow Tracking Server em configuração padrão, o endpoint POST /api/2.0/mlflow/webhooks/{id}/test fica acessível sem autenticação, permitindo a qualquer pessoa despoletar a entrega de um webhook e receber de volta o estado e o corpo da resposta do servidor contactado. Os webhooks exigem um backend SQL, condição satisfeita pelo arranque predefinido com SQLite, e não é necessária qualquer autenticação.

O projeto já tinha tentado fechar esta porta. O MLflow introduziu validação do destino de saída na versão 3.10.0, para impedir que os webhooks alcançassem endereços IP privados ou reservados, mas essa validação aplica-se apenas ao nome de anfitrião fornecido inicialmente. A função _validate_webhook_url(), em mlflow/utils/validation.py, valida somente o URL original, enquanto mlflow/webhooks/delivery.py segue redirecionamentos e volta a resolver o nome sem fixar o endereço já validado. É um caso clássico de time-of-check/time-of-use: basta registar um webhook para um servidor controlado pelo atacante, que passa a validação inicial e depois responde com um redirecionamento (por exemplo, 302) para um endereço interno, como o serviço de metadados da cloud em 169.254.169.254 ou o loopback 127.0.0.1. O mesmo desvio de validação pode ainda ser explorado através de DNS rebinding.

O aviso oficial do projeto é explícito quanto ao alcance: um atacante sem credenciais que consiga chegar ao tracking server obriga o servidor a emitir pedidos para endpoints internos, de loopback ou de metadados de nuvem — incluindo credenciais IAM do IMDS da AWS, serviços de administração acessíveis apenas na rede interna e varrimento de portas e anfitriões internos —, sendo que o caminho de entrega orientado a eventos dá o mesmo SSRF às cegas e o endpoint /test torna-o de leitura completa; trata-se de uma correção incompleta da salvaguarda introduzida no PR #20747, confirmada na versão 3.13.0 e no master.

Ficha técnica da vulnerabilidade

A base de dados de avisos da GitLab confirma que todas as versões anteriores à 3.15.0 estão afetadas, que a correção passa por atualizar para a 3.15.0 ou superior e regista o vetor CVSS 3.1 com pontuação crítica associado a CWE-918. Segundo a análise da IONIX, a versão 3.15.0 passa a fixar o endereço validado no momento da ligação.

Exploração em curso: o que foi observado

A watchTowr comunicou publicamente que a falha já estava a ser explorada no mundo real e que, poucas horas depois da atribuição do CVE, a sua rede global de honeypots Attacker Eye observou atacantes a visar sistemas MLflow alojados na nuvem para extrair credenciais e segredos, sublinhando que todas as versões anteriores à 3.15.0 estão afetadas e recomendando prioridade na aplicação de correções, monitorização de sinais de compromisso e revisão de credenciais sensíveis expostas. Yordan Ganchev, especialista principal de threat intelligence da watchTowr, descreveu o ataque como o abuso dos webhooks do registo de modelos para “proxy” de pedidos e interação com serviços internos, notando que a falha contorna correções anteriores pela forma como lida com redirecionamentos e que a telemetria de honeypots aponta para tentativas de extração de credenciais a partir de endereços e serviços internos conhecidos.

A entrada no KEV não é meramente simbólica. A ação exigida pela CISA passa por aplicar as mitigações indicadas pelo fabricante, em conformidade com a diretiva BOD 26-04 e com os requisitos de triagem forense, e embora a diretiva se aplique apenas às agências federais norte-americanas, a CISA encoraja todas as organizações a adotarem gestão de vulnerabilidades baseada em risco e a priorizarem a correção das falhas do catálogo.

O que procurar e como mitigar

A prioridade é evidente: atualizar. As equipas de segurança devem identificar de imediato todas as instalações de MLflow, incluindo ambientes de desenvolvimento, de experimentação e MLOps não inventariado (shadow), e atualizar os servidores afetados. Enquanto a atualização não é concluída, valem as medidas de contenção recomendadas pelos investigadores:

• Restringir o acesso público às instâncias do Tracking Server, exigir autenticação e colocar o MLflow atrás de um proxy inverso ou de uma gateway de acesso com identidade.
• Ativar autenticação no MLflow Tracking Server, uma vez que as instalações predefinidas correm sem autenticação, e limitar o acesso de rede ao servidor e à gestão de webhooks.
• Rever as configurações de webhooks à procura de URL desconhecidos ou controlados por terceiros.
• Inspecionar registos de aplicação e de proxy à procura de pedidos aos endpoints de teste de webhooks, cadeias de redirecionamento, endereços IP de metadados, gamas de loopback e tráfego HTTP de saída invulgar.
• Priorizar a correção dos sistemas expostos, rever registos de auditoria à procura de sinais de compromisso e verificar se dados sensíveis foram acedidos.

Como sinais de alerta práticos, procure em logs pedidos para /api/2.0/mlflow/webhooks/ seguidos de tráfego de saída para 169.254.169.254, 127.0.0.1 ou gamas privadas, bem como respostas HTTP 302 vindas de domínios externos desconhecidos imediatamente antes desse tráfego. Se houver indícios de acesso ao serviço de metadados, o pressuposto de trabalho deve ser o de credenciais comprometidas: rodar chaves e tokens, revogar sessões e auditar a atividade na conta cloud.

Não é caso isolado: o FUXA também está sob varrimento

Relatos independentes da watchTowr e da VulnCheck apontam para atividade maliciosa de varrimento e exploração dirigida a duas falhas críticas: a CVE-2026-64849 no MLflow e a CVE-2026-25895 (CVSS 9.5) no FUXA, software SCADA/HMI de código aberto usado em automação industrial, que permite a um atacante remoto e não autenticado escrever ficheiros arbitrários no sistema e obter execução remota de código. A VulnCheck refere existirem cerca de 60 instalações de FUXA expostas na Internet e que os pedidos observados tentavam sobrescrever o ficheiro main.js com dados inúteis, sem que tenham sido largados, até ao momento, payloads de execução remota.

Porque é que isto importa em Portugal

Muitas equipas de dados em Portugal levantam servidores MLflow para experimentação e acabam por deixá-los acessíveis, sem autenticação, dentro de contas cloud com permissões generosas. É precisamente esse cenário que esta falha transforma num problema de segurança de primeira linha: o comprometimento não se limita à plataforma de MLOps, estende-se às credenciais que ela consegue alcançar. Uma exposição de credenciais desta natureza pode significar acesso indevido a repositórios de dados, incluindo dados pessoais, com as obrigações de notificação previstas no RGPD — comunicação à CNPD, em regra no prazo de 72 horas após conhecimento da violação, e informação aos titulares quando houver risco elevado.

Para as organizações abrangidas pelo Regime Jurídico da Cibersegurança, que transpõe a diretiva NIS2, o caso serve de teste prático a três exigências centrais: inventário e gestão de ativos (saber quantos servidores MLflow existem e onde estão), gestão de vulnerabilidades com base em risco e capacidade de notificação atempada de incidentes ao CNCS/CERT.PT. Servidores de experimentação que ninguém assume como “produção” continuam a ser ativos da organização — e são frequentemente o elo por onde entra o atacante. A recomendação é simples e urgente: inventariar, atualizar para a 3.15.0, tirar da Internet o que não precisa de lá estar e assumir que qualquer instância exposta antes da correção pode ter entregado segredos.

Perguntas frequentes

Que versões do MLflow estão afetadas pela CVE-2026-64849?

Todas as versões anteriores à 3.15.0 estão afetadas e a correção passa por atualizar para a versão 3.15.0 ou superior.

É necessário ter credenciais para explorar esta falha?

Não. Num MLflow Tracking Server em configuração predefinida, o endpoint de teste de webhooks está acessível sem autenticação, permitindo despoletar a entrega e receber o estado e o corpo da resposta do destino contactado.

O que podem os atacantes obter na prática?

O aviso do projeto indica que o atacante leva o servidor a contactar endpoints internos, de loopback ou de metadados de nuvem, incluindo credenciais IAM do IMDS da AWS, serviços internos de administração e varrimento de anfitriões e portas na rede interna.

O que fazer se não for possível atualizar de imediato?

Restringir o acesso público às instâncias, exigir autenticação, colocar o MLflow atrás de um proxy inverso ou gateway com identidade e rever as configurações de webhooks à procura de URL desconhecidos.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela CISA, pelo aviso de segurança do projeto MLflow, pela watchTowr e pela VulnCheck.