Um Engenheiro Monta um Painel, Só Para a Equipa

Um engenheiro de uma empresa de média dimensão monta um servidor de tracking do MLflow numa VM interna para que a equipa de data science possa registar experiências e comparar execuções de modelos. O MLflow não pede um nome de utilizador nem uma palavra-passe durante a instalação, por isso não fica nenhuma configurada, e o servidor entra em funcionamento atrás daquilo que todos assumem ser uma rede privada. Numa fábrica a algumas centenas de quilómetros de distância, um engenheiro de operações faz algo semelhante: monta o FUXA, uma plataforma open source SCADA e HMI, para dar à equipa uma vista via navegador sobre as tags da linha de produção. Nenhum dos dois sistemas foi construído para ser alcançável a partir da internet aberta, e nenhuma equipa o verificou.

Na semana de 18 de agosto de 2026, ambas as suposições revelaram-se erradas ao mesmo tempo. O MLflow, uma plataforma de tracking de experiências alojada sob a LF Projects na Linux Foundation, e o FUXA, uma ferramenta de sistemas de controlo industrial totalmente sem relação, divulgaram cada um uma vulnerabilidade crítica, não autenticada por defeito - e em ambos os casos os atacantes tinham exploits a funcionar horas após a divulgação pública, não semanas. Duas bases de código diferentes, dois setores diferentes, duas equipas que nunca se coordenaram entre si. O que partilham é uma única decisão de conceção, tomada de forma independente, com anos de intervalo, pela mesma razão: é mais rápido lançar uma ferramenta com a autenticação desligada do que ligada.

A Falha do MLflow Transforma um Redirecionamento em Roubo de Credenciais

A vulnerabilidade do MLflow, registada como CVE-2026-64849, tem uma pontuação CVSS de 9,3. É um contorno da validação do URL do webhook: o MLflow permite registar webhooks que disparam perante eventos como uma execução de treino concluída, e verifica o endereço de destino antes de o permitir, para impedir que o servidor aponte para endereços internos. Os atacantes descobriram que conseguiam contornar essa verificação combinando um redirecionamento HTTP com DNS rebinding - registam um webhook para um endereço que passa a validação e depois deixam-no resolver, no momento do pedido, para um IP interno que o validador nunca viu. A GitLab publicou um aviso de segurança sobre a falha, e o exploit foi corroborado de forma independente por meios de cibersegurança como a cybersecuritynews, a cyberpress e a GBHackers.

O ganho para um atacante é a falsificação de pedidos do lado do servidor: o próprio servidor MLflow passa a ser quem faz o pedido, de dentro da rede em que se encontra. Isso permite a um atacante alcançar serviços internos que nunca deveriam estar virados para fora e, de forma crítica, os endpoints de metadados de instância na nuvem da AWS, Azure e GCP - os endereços internos que entregam credenciais temporárias à máquina que as pede. Como os servidores de tracking do MLflow frequentemente funcionam sem autenticação em implementações reais, nada impede um atacante externo de fazer esse primeiro pedido. A The Hacker News noticiou, a 18 de agosto de 2026, que a exploração ativa começou horas após a divulgação.

A Falha do FUXA Permite a Terceiros Escrever Ficheiros em Sistemas de Fábrica

O FUXA é uma plataforma open source SCADA e HMI - o tipo de software que dá aos operadores de fábrica uma janela via navegador sobre o equipamento que efetivamente controla uma linha de produção. A sua vulnerabilidade, CVE-2026-25895, tem uma pontuação ainda mais alta do que a do MLflow, 9,5, e o mecanismo é mais direto: autenticação em falta combinada com uma falha de path traversal. Um atacante não autenticado pode enviar um pedido que escapa à pasta onde o FUXA espera escrever e colocar um ficheiro em qualquer ponto do sistema de ficheiros subjacente à sua escolha.

A escrita arbitrária de ficheiros não é um simples erro de exposição de dados, é um ponto de apoio. Um atacante que consiga escrever ficheiros onde quiser num sistema que comunica com equipamento industrial pode colocar código executável e obter execução remota de código, o que significa controlo total sobre o servidor que executa a HMI - e, consoante a forma como esse servidor está ligado ao chão de fábrica, um caminho até aos próprios sistemas de controlo. Tal como com o MLflow, a The Hacker News e os mesmos meios corroborantes noticiaram que a exploração ativa começou horas após a divulgação pública, na mesma semana do aviso do MLflow.

O Fio Condutor Não É o Código, É a Predefinição

O MLflow e o FUXA não partilham código, nem responsáveis pela manutenção, nem mercado. Um faz o tracking de experiências de machine learning, o outro visualiza sistemas de controlo industrial, e foram divulgados de forma independente na mesma semana por pura coincidência de calendário. O que partilham é uma predefinição: lançar sem autenticação, porque é a forma mais rápida de pôr uma ferramenta a funcionar para uma pequena equipa interna, e porque a equipa assume que a rede à sua volta é privada. Essa suposição é toda a superfície de ataque.

Essa mesma predefinição está por detrás de uma grande parte das ferramentas internas que os donos de empresas nunca inspecionam pessoalmente: painéis de MLOps, stacks de monitorização, painéis de administração internos e sistemas SCADA/HMI em toda a indústria transformadora. Cada um foi provavelmente montado depressa, por alguém competente, a resolver um problema real, que nunca voltou atrás para ativar a autenticação porque nada o obrigou a isso. A distância entre o que se assume ser privado e o que é realmente alcançável - seja por exposição direta à internet, seja, como no caso do MLflow, através de um pivot SSRF a partir de um sistema alcançável - é exatamente onde ambos os exploits aterraram, e é onde o próximo também vai aterrar.

Horas Até à Exploração É Agora a Verdadeira Janela de Correção

Para qualquer empresa na UE ou no Reino Unido que opere pipelines de MLOps - cada vez mais comum à medida que as empresas implementam a sua própria infraestrutura de ML e IA - ou qualquer empresa industrial ou de fabrico que opere sistemas SCADA ou HMI, a resposta prática é uma auditoria, não uma nota de política. Cada ferramenta interna precisa de uma resposta direta a uma pergunta: a autenticação está mesmo ativada, e não apenas assumida, e a ferramenta está mesmo inalcançável a partir de fora da rede em que se supõe que vive. O MLflow e o FUXA mostram, ambos, que a resposta honesta é muitas vezes não, e que ninguém descobre isso até ser explorado.

O outro ajuste tem a ver com o relógio. Ambas as falhas passaram da divulgação pública para a exploração ativa em horas, não nas semanas que os ciclos de correção tradicionalmente assumiam. Para os operadores industriais sediados na UE em particular, isto não é apenas um problema técnico: as obrigações do NIS2 aplicam-se aos fornecedores de infraestrutura digital e, de forma notável, aos operadores de fabrico e industriais que operam sistemas OT e SCADA, o que torna uma HMI não corrigida e não autenticada numa falha de conformidade tanto quanto numa falha de segurança. A solução não é exótica - ativar a autenticação, corrigir no dia da divulgação, assumir que nada atrás da firewall é realmente privado - mas tem de acontecer antes de o exploit acontecer, e esta semana essa distância foi medida em horas.

Leia a seguir: Uma falha que o registo do DORA não explica  |  A Shell e a Philips perderam plantas, não palavras-passe