Falha crítica no MLflow é explorada e entra no KEV da CISA

A CISA, agência de segurança cibernética do governo dos Estados Unidos, incluiu em 19 de agosto de 2026 a vulnerabilidade CVE-2026-64849 em seu catálogo de falhas exploradas ativamente (KEV). O alvo é o MLflow, plataforma de código aberto mantida sob a Linux Foundation e usada para depurar, avaliar, otimizar e monitorar aplicações de aprendizado de máquina, modelos de linguagem e agentes.

A falha recebeu nota 9,3 na escala CVSS 3.1, atribuída pela equipe de segurança do GitHub, e está classificada como CWE-918 — falsificação de requisição do lado do servidor, mais conhecida pela sigla SSRF. O vetor registrado é CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N: exploração pela rede, complexidade baixa, sem privilégios e sem interação do usuário.

Segundo o aviso oficial do projeto, versões até a 3.13.0 são afetadas; a correção foi publicada na versão 3.15.0. O MLflow registra mais de 30 milhões de downloads mensais, o que dá dimensão à superfície potencialmente exposta.

Como a falha no MLflow funciona

O problema está na entrega de webhooks do registro de modelos. Em uma instalação padrão do servidor de rastreamento (mlflow server, sem autenticação e com banco SQLite), a API de webhooks fica acessível sem autenticação — a autorização correspondente vive apenas em um plugin opcional que não é carregado por padrão.

Entre esses endpoints está um de teste síncrono que dispara a requisição e devolve ao chamador o status e o corpo da resposta recebida do destino. Essa devolução é o que transforma um SSRF “cego” em um SSRF de leitura completa.

O projeto já havia adicionado uma proteção contra SSRF na versão 3.10.0. Ela resolve o nome do host informado no webhook e rejeita endereços IP não públicos, bloqueando faixas internas, loopback e endereços de metadados. O problema, como descreve o aviso, é que a validação não fixa o endereço aprovado: o cliente HTTP segue redirecionamentos e volta a resolver o nome sem repetir a checagem.

Daí decorrem duas formas de contornar a proteção, ambas descritas pelo próprio projeto:

• Redirecionamento não revalidado. Um host público que passa na verificação inicial responde com um redirecionamento apontando para um endereço interno ou para o serviço de metadados da nuvem. O servidor segue o redirecionamento e nunca revalida o destino.
• DNS rebinding. A resolução feita pela validação e a resolução feita no momento da conexão acontecem de forma independente, criando uma janela clássica entre verificação e uso.

O aviso detalha ainda que o código de redirecionamento usado muda a natureza do ataque. Redirecionamentos que convertem a requisição em leitura permitem obter respostas de serviços internos; redirecionamentos que preservam o método e o corpo da requisição original permitem enviar dados a endpoints internos de gerenciamento que agem sobre requisições POST. Nenhum dos dois exige autenticação em um servidor de código aberto com a configuração padrão.

Por decisão editorial, o Plugged Ninja não reproduz as requisições de prova de conceito publicadas no aviso. Elas estão disponíveis na íntegra na página oficial, linkada ao final desta matéria.

Qual é o impacto real

De acordo com o aviso, um atacante sem autenticação que consiga alcançar o servidor de rastreamento pode fazer com que ele emita requisições para endpoints internos, de loopback ou de metadados de nuvem — e leia as respostas. Na prática, isso abre três possibilidades concretas:

• Obtenção de credenciais de instância na nuvem, como credenciais IAM expostas pelo serviço de metadados da AWS.
• Acesso a serviços administrativos que só deveriam ser alcançáveis de dentro do perímetro de rede.
• Varredura de hosts e portas internas a partir do próprio servidor comprometido.

O projeto registra que a falha é uma correção incompleta de uma proteção anterior, e que ela foi confirmada na versão mais recente à época da publicação. O aviso também esclarece que não se trata de duplicata da CVE-2025-14279, que descreve um problema de natureza diferente, no lado do navegador.

Prazos, obrigações e o que a CISA determinou

A obrigação de correção em duas semanas decorre da Binding Operational Directive 26-04, emitida em junho de 2026, que orienta a priorização de atualizações com base em risco. A diretiva vale apenas para órgãos do Poder Executivo civil federal norte-americano, mas a CISA recomendou que todos os defensores de rede priorizem a correção. Não há, no Brasil, equivalente com força vinculante para o setor privado — o que reforça que a decisão de prazo cabe a cada organização.

Como a correção resolve o problema

A correção introduz um adaptador HTTP que valida o endereço IP do par imediatamente após o estabelecimento da conexão, antes de qualquer troca TLS ou HTTP. Como cada redirecionamento abre uma nova conexão pelo mesmo pool protegido, o destino de cada salto passa a ser verificado — o que fecha tanto a variante de leitura quanto a de escrita, além da janela de DNS rebinding.

Vale notar o histórico de divulgação registrado no aviso: o problema foi reportado em caráter privado em 12 de junho de 2026 e descoberto de forma independente, por revisão de código, em 26 de junho de 2026, quando foi relatado publicamente em uma issue do repositório. A prioridade de descoberta é atribuída ao primeiro relator.

Recomendações

• Atualize para o MLflow 3.15.0 ou superior. Essa é a única medida que corrige a causa raiz.
• Verifique a exposição. Servidores de rastreamento do MLflow não deveriam estar acessíveis pela internet. Levante os ativos publicados e restrinja o acesso a redes internas ou a uma VPN.
• Habilite autenticação. Se o plugin de autenticação do projeto não estiver ativo, os endpoints de webhook ficam abertos por padrão.
• Imponha IMDSv2 nas instâncias em nuvem. Em ambientes AWS, exigir o serviço de metadados em sua versão com sessão dificulta a obtenção de credenciais por SSRF.
• Reduza privilégios do papel associado à instância que executa o MLflow, limitando o alcance de credenciais eventualmente vazadas.
• Revise registros. Procure por criação de webhooks e chamadas ao endpoint de teste em servidores expostos, e por requisições de saída do servidor para endereços internos ou de metadados.
• Rotacione credenciais se houver indício de acesso ao serviço de metadados ou a serviços internos a partir do servidor.

O que observar a seguir

A CISA declara que a falha está sendo explorada, mas não divulgou detalhes sobre os atores envolvidos, o volume de tentativas ou os objetivos observados; o campo de uso por ransomware está registrado como desconhecido. Também não há, até o momento, atribuição pública a um grupo específico.

O caso ilustra um ponto que tende a se repetir: a infraestrutura de suporte a projetos de aprendizado de máquina — servidores de rastreamento, registros de modelos, painéis de experimentos — costuma ser implantada com configuração padrão, dentro do perímetro e com credenciais de nuvem associadas. É exatamente o perfil de ativo em que um SSRF de leitura completa causa mais estrago. Vale acompanhar se o mesmo padrão aparece em outras plataformas do ecossistema.

Fontes e referências

• CISA — Known Exploited Vulnerabilities Catalog (entrada de 19 de agosto de 2026)
• CISA — BOD 26-04: Prioritizing Security Updates Based on Risk
• MLflow — Aviso de segurança GHSA-7gwp-5pfp-969j
• NVD — CVE-2026-64849
• MLflow — Notas da versão 3.15.0
• BleepingComputer, Sergiu Gatlan — CISA warns of hackers exploiting critical MLflow vulnerability (20 de agosto de 2026)