CVE-2024-37052

O MLflow desserializa um arquivo de modelo quando um usuário o carrega ou interage com ele, e um modelo scikit-learn forjado maliciosamente pode contrabandear código para essa etapa, executando comandos arbitrários na máquina que o abre. Este é o clássico problema do modelo-como-payload: o artefato que todos tratam como dado passivo é na verdade executável no momento em que o framework o desempacota.

O que torna essa classe urgente é a confiança que as pessoas depositam em modelos compartilhados. Equipes de ML puxam modelos de registries, colegas e hubs públicos rotineiramente, e cada carregamento é uma oportunidade para isto disparar — nenhuma exposição de servidor necessária, apenas um cientista de dados abrindo o arquivo errado. Exige essa ação humana, então não é remoto-não-autenticado, mas num pipeline de ML movimentado essa ação acontece o tempo todo.

Nosso ângulo defensivo aqui é proveniência de cadeia de suprimentos, e não perímetro. Queremos saber onde o MLflow roda, quais versões e, crucialmente, de onde vêm seus modelos — tratando qualquer modelo de fonte não confiável ou compartilhada como código não confiável. Além de atualizar, o controle durável é só carregar modelos cuja origem possamos atestar, porque a vulnerabilidade transforma o registry de modelos num canal de distribuição de código.