Falha crítica no MLflow expõe credenciais de nuvem via SSRF
A CISA confirmou exploração ativa da CVE-2026-64849, falha crítica (CVSS 9.3) de Server-Side Request Forgery (SSRF) não autenticado no MLflow, plataforma open source de gestão de ciclo de vida de modelos de IA. Atacantes já usam a brecha para alcançar serviços de metadados de nuvem e roubar credenciais de servidores expostos na internet.
O que aconteceu
A vulnerabilidade foi divulgada em 17 de agosto de 2026. Segundo a empresa de threat intelligence watchTowr, horas depois da atribuição do CVE, sua rede global de honeypots já registrava varreduras indiscriminadas em busca de instâncias MLflow expostas na internet. A CISA incluiu a falha em seu catálogo de vulnerabilidades exploradas (KEV) em 19 de agosto, com base em evidências de exploração em ambiente real.
Como funciona o ataque
O problema está no tratamento de webhooks do MLflow. O endpoint não autenticado POST /api/2.0/mlflow/webhooks/{id}/test valida a URL original por meio da função _validate_webhook_url(), mas o módulo responsável pela entrega (delivery.py) segue redirecionamentos HTTP e resolve o novo hostname sem fixar o endereço já validado.
Na prática, um atacante registra um webhook apontando para um endereço aparentemente legítimo, que redireciona a requisição para endpoints internos ou para o serviço de metadados da nuvem (AWS, Azure ou GCP). O MLflow repassa a resposta — incluindo response_status e response_body — de volta ao atacante, vazando tokens e segredos que normalmente ficam isolados da rede externa.
“A falha contorna correções anteriores por causa de como trata redirecionamentos web. Nossa telemetria de honeypots indica que atacantes estão abusando dessa vulnerabilidade para atingir sistemas MLflow hospedados em nuvem, tentando extrair credenciais e segredos de endereços IP internos conhecidos”, afirmou Yordan Ganchev, especialista principal de threat intelligence da watchTowr.
Quem está exposto
Todas as versões do MLflow anteriores à 3.15.0 são vulneráveis. O risco é maior para instâncias do Tracking Server acessíveis publicamente ou alcançáveis a partir de redes internas sem segmentação — cenário comum em times de dados e MLOps que sobem o MLflow rapidamente sem revisão de exposição de rede.
Como se proteger
- Atualize o MLflow para a versão 3.15.0 ou superior, que corrige a validação de redirecionamento nos webhooks.
- Se a atualização não for imediata, restrinja o acesso ao Tracking Server por firewall ou security group, permitindo apenas origens confiáveis.
- Bloqueie, na camada de rede, o acesso de cargas de trabalho do MLflow aos endereços de metadados de nuvem (por exemplo, 169.254.169.254) quando o serviço não precisar dessa rota.
- Revise logs de auditoria em busca de chamadas de webhook incomuns e teste de redirecionamento para endereços internos.
- Rotacione credenciais de nuvem e segredos acessíveis pelo servidor MLflow caso encontre indícios de exploração.
Perguntas frequentes
O que é a CVE-2026-64849?
É uma falha de SSRF não autenticado no MLflow que permite a um atacante forçar o servidor a fazer requisições HTTP para endereços internos ou serviços de metadados de nuvem, com CVSS 9.3.
Desde quando a falha está sendo explorada?
A CISA registra evidências de exploração ativa a partir de 17 de agosto de 2026, mesma data de divulgação pública do CVE.
Qual versão do MLflow corrige o problema?
A versão 3.15.0 corrige a validação de redirecionamento que originava a falha.
O que um atacante consegue roubar?
Principalmente credenciais e segredos de nuvem acessíveis via serviços de metadados internos, como chaves temporárias de instâncias na AWS, Azure ou GCP.
Preciso me preocupar se meu MLflow não está exposto à internet?
Sim, se atacantes já tiverem posição em outra parte da rede interna, o SSRF ainda pode ser usado como ponte para alcançar serviços de metadados que o próprio servidor MLflow enxerga.
Conclusão
A janela entre divulgação e exploração em massa voltou a ser de horas, não de dias. Quem roda MLflow em produção deve tratar a atualização para 3.15.0 como prioridade imediata e, enquanto isso, isolar o Tracking Server de qualquer rota para serviços de metadados de nuvem.
