Fallo crítico en Bifrost: un POST sin autenticación ejecuta comandos en el gateway

Una vulnerabilidad crítica en Bifrost, el gateway de IA open source que enruta peticiones hacia más de 20 proveedores de LLM, permite a un atacante no autenticado ejecutar comandos arbitrarios en el servidor con una sola petición HTTP. El fallo está catalogado como CVE-2026-90898, con una puntuación CVSS de 9,8, y afecta a todas las versiones del transporte HTTP anteriores a la 2.1.0 cuando la autenticación de la API de gestión está desactivada, que es la configuración por defecto. El arreglo llega en transports/v2.1.0.

Un POST y ya está

Yuval Moravchick, de JFrog Security Research, es quien encontró el agujero. El ataque es un único POST sin autenticar al endpoint de gestión /api/mcp/client en el que se registra un cliente MCP de tipo stdio. Bifrost lanza el comando indicado de inmediato, antes de cualquier handshake MCP, y lo hace con el usuario del proceso del gateway: appuser en la imagen Docker oficial. Como el gateway almacena las claves de API de todos los proveedores conectados, quien consiga ejecutar comandos en ese proceso se lleva también esas credenciales.

Hay un matiz importante para medir la exposición real. El binario estándar de Bifrost ata la API de gestión a localhost, lo que limita el alcance a la propia máquina. La imagen Docker oficial la ata a 0.0.0.0, de modo que la API queda accesible desde fuera del contenedor si se publica el puerto.

La vía directa es actualizar a transports/v2.1.0, que devuelve un 403 cuando alguien sin autenticar intenta registrar un cliente MCP stdio. Quien no pueda subir de versión tiene que activar governance.auth_config.is_enabled, usar credenciales fuertes y mantener el listener de gestión fuera de redes no confiables. JFrog recomienda además dar por comprometida cualquier instancia que haya corrido con la autenticación desactivada y la API expuesta, y rotar tanto las claves virtuales como las claves de proveedor.

Conviene fijarse en qué versión se tiene exactamente. La transports/v2.0.0 sigue siendo vulnerable al fallo de MCP: esa entrega solo cerró una vulnerabilidad anterior de plugins y no bloquea el registro sin autenticar. La línea 1.6.x, hasta la 1.6.11, no contiene ninguno de los dos arreglos.

El segundo fallo, y la causa común

El mismo equipo encontró un segundo problema, revelado el 6 de septiembre. CVE-2026-86242, con CVSS 8,1, lo firma Or Peles y permite a un atacante sin autenticar registrar un plugin cuyo path es una URL HTTP. Bifrost descarga el archivo, lo escribe como objeto compartido temporal y lo carga con plugin.Open de Go. En las builds enlazadas dinámicamente, que son las que Bifrost necesita para plugins Go personalizados, el código se ejecuta con el usuario del proceso del gateway. En las estáticas, como la imagen Docker oficial, plugin.Open falla y el resultado se queda en un SSRF. El arreglo está en transports/v2.0.0.

Ambos comparten la misma raíz: la API de gestión de Bifrost se envía con la autenticación desactivada por defecto. Son el segundo y el tercer problema de seguridad del proyecto en menos de un mes, después de un SSRF sin relación (CVE-2026-55245) corregido a finales de agosto.

Y el patrón no es nuevo. En abril de 2026 se divulgó un fallo de diseño en el transporte STDIO de MCP que afecta a los SDK oficiales de Anthropic. Un fallo similar de inyección de comandos en LiteLLM, otro gateway de IA, se explotó de forma activa y entró en el catálogo de vulnerabilidades explotadas conocidas de CISA en junio. Ninguno de los dos CVE de Bifrost aparece en esa lista.

Si la instancia corría con la API de gestión expuesta y sin autenticación, parchear no arregla el pasado: toca rotar claves y revisar registros. Y el detalle de fondo sigue ahí, porque una API de gestión que viene apagada de fábrica no es un descuido de un proyecto concreto, es una decisión de diseño que se repite en esta generación de gateways de IA.