El riesgo de la falsificación de solicitudes en plataformas de IA
La adopción masiva de herramientas de Machine Learning ha metido en producción sistemas complejos que a menudo no reciben la misma auditoría de seguridad que el desarrollo de software tradicional. MLflow, una de las plataformas de gestión de ciclo de vida de IA más populares, sufre una vulnerabilidad crítica de falsificación de solicitudes del lado del servidor (SSRF) no autenticada en su registro de modelos en versiones anteriores a la 3.15.0 (identificada bajo INCIBE-2026-561).
El fallo radica en la API de webhooks. Al permitir que usuarios sin credenciales fuercen al servidor de MLflow a realizar peticiones HTTP salientes hacia cualquier dirección IP interna o externa, los atacantes obtienen un puente directo hacia tu red privada.
Por qué esta vulnerabilidad es crítica en entornos Cloud e infraestructuras Kubernetes
En despliegues de nube pública como AWS, GCP o Azure, el servidor que ejecuta MLflow suele tener asignado un rol de IAM (mediante IRSA en Kubernetes, perfiles de instancia en EC2 o identidades administradas). Un atacante que explote este SSRF puede apuntar a las direcciones locales de metadatos (el clásico 169.254.169.254).
Si la infraestructura utiliza el servicio de metadatos de AWS IMDSv1, o si IMDSv2 está configurado con un límite de saltos (hop limit) permisivo, el atacante puede extraer las credenciales temporales de seguridad del rol asignado a la instancia. Esto significa que un compromiso en la API de MLflow se traduce de forma casi inmediata en un acceso legítimo a tu consola de AWS, con los privilegios que tuviera ese nodo para leer datos de S3, escribir en bases de datos o modificar la configuración de red.
En el contexto de un homelab o redes locales corporativas, este SSRF sirve como vector de reconocimiento interno. Un atacante puede escanear puertos de bases de datos, paneles de virtualización como Proxmox, o APIs de red que de otro modo estarían protegidas por el firewall perimetral.
Plan de acción inmediato y mitigación técnica
Si gestionas instancias de MLflow, la prioridad es cortar el vector de ataque antes de que sea descubierto por escaneos automatizados:
1. Actualización a MLflow 3.15.0+: La solución definitiva pasa por parchear el servidor. Las últimas versiones restringen la manipulación de llamadas salientes desde el registro de modelos y aplican saneamiento estricto de URLs en la API de webhooks.
2. Configurar IMDSv2 estricto: En AWS, fuerza el uso de IMDSv2 en las instancias EC2 que alojen MLflow o los nodos de Kubernetes. Configura el Metadata Response Hop Limit a 1 para impedir que los contenedores accedan al servicio de metadatos del host a través de saltos de red adicionales.
3. Políticas de red en Kubernetes (NetworkPolicies): Si corres MLflow en K8s, define una NetworkPolicy que prohíba explícitamente el tráfico saliente desde el pod de MLflow hacia el rango IP del de metadatos de la nube (169.254.169.254) y hacia otras subredes internas críticas que no requiera para su funcionamiento diario.
4. Control de acceso perimetral: No expongas la interfaz web ni la API de MLflow directamente a internet sin una capa de autenticación previa, como un proxy inverso con autenticación OIDC, Cloudflare Access o una VPN corporativa.
Comentarios