CVE-2024-37052

MLflow deserializa un archivo de modelo cuando un usuario lo carga o interactúa con él, y un modelo de scikit-learn manipulado maliciosamente puede colar código en ese paso, ejecutando comandos arbitrarios en la máquina que lo abre. Este es el clásico problema del modelo-como-payload: el artefacto que todos tratan como dato pasivo es en realidad ejecutable en el momento en que el framework lo desempaqueta.

Lo que hace urgente a esta clase es la confianza que la gente deposita en los modelos compartidos. Los equipos de ML jalan modelos de registros, colegas y hubs públicos rutinariamente, y cada carga es una oportunidad para que esto se dispare: no se necesita exposición de servidor, solo un científico de datos abriendo el archivo equivocado. Requiere esa acción humana, así que no es remota-no-autenticada, pero en un pipeline de ML ocupado esa acción ocurre constantemente.

Nuestro ángulo defensivo aquí es la procedencia de la cadena de suministro más que el perímetro. Queremos saber dónde corre MLflow, qué versiones y, crucialmente, de dónde vienen sus modelos, tratando cualquier modelo de una fuente no confiable o compartida como código no confiable. Junto con la actualización, el control duradero es cargar solo modelos cuyo origen podamos avalar, porque la vulnerabilidad convierte el registro de modelos en un canal de distribución de código.