Una vulnerabilidad crítica en Bifrost, una puerta de enlace de IA de código abierto que enruta solicitudes a más de 20 proveedores de modelos de lenguaje grande (LLM), permite a un atacante no autenticado ejecutar comandos arbitrarios en el servidor de la puerta de enlace con una sola solicitud HTTP.
La falla, rastreada como CVE-2026-90898 (puntuación CVSS: 9.8), afecta a todas las versiones del transporte HTTP de Bifrost anteriores a la 2.1.0 cuando la autenticación de gestión está deshabilitada, que es la configuración predeterminada. La corrección está disponible en transports/v2.1.0.
Yuval Moravchick, de JFrog Security Research, quien descubrió la falla, señaló que un atacante puede registrar un cliente MCP de tipo stdio mediante una única solicitud POST no autenticada al endpoint de la API de gestión /api/mcp/client. Bifrost inicia el comando especificado de inmediato, antes de cualquier handshake MCP, con el usuario del proceso de la puerta de enlace.
En la imagen oficial de Docker, ese usuario es appuser. Dado que la puerta de enlace almacena claves de API para cada proveedor conectado, la ejecución de comandos en el proceso de la puerta de enlace otorga al atacante acceso a esas credenciales.
El binario estándar de Bifrost vincula la API de gestión a localhost de forma predeterminada, lo que limita la exposición a la máquina local. La imagen oficial de Docker la vincula a 0.0.0.0, lo que hace que la API de gestión sea accesible desde fuera del contenedor si se publica el puerto.
Los operadores deben actualizar a transports/v2.1.0, que devuelve un código 403 cuando un llamante no autenticado intenta registrar un cliente MCP stdio. Quienes no puedan actualizar de inmediato deben establecer governance.auth_config.is_enabled en true, usar credenciales sólidas y mantener el listener de gestión fuera de redes no confiables.
JFrog aconseja tratar cualquier instancia que haya funcionado con la autenticación deshabilitada y la API de gestión expuesta como comprometida, y rotar las claves virtuales y las claves de API de los proveedores.
Los operadores en transports/v2.0.0 siguen afectados por la falla de MCP. Esa versión solo corrigió una vulnerabilidad anterior de complementos y no bloquea el registro no autenticado. La línea 1.6.x hasta la 1.6.11 no contiene ninguna de las dos correcciones.
Una segunda falla relacionada, encontrada por Or Peles del mismo equipo de investigación, se divulgó el 6 de septiembre. CVE-2026-86242 (puntuación CVSS: 8.1) permite a un atacante no autenticado registrar un complemento personalizado cuya ruta sea una URL HTTP. Bifrost descarga el archivo, lo escribe como un objeto compartido temporal y lo carga mediante la función plugin.Open de Go.
En compilaciones con enlace dinámico, que Bifrost requiere para complementos Go personalizados, el complemento se carga y su código se ejecuta con el usuario del proceso de la puerta de enlace. En compilaciones con enlace estático, incluida la imagen oficial de Docker, plugin.Open falla y el resultado es solo falsificación de solicitud del lado del servidor (SSRF). La corrección está en transports/v2.0.0.
Ambas fallas comparten la misma causa raíz: la API de gestión de Bifrost se entrega con la autenticación deshabilitada de forma predeterminada. Son el segundo y tercer problema de seguridad divulgados en el proyecto en menos de un mes, después de una falla SSRF no relacionada (CVE-2026-55245) corregida a finales de agosto.
La falla de MCP sigue un patrón que ya ha provocado ataques en el mundo real. En abril de 2026, los investigadores divulgaron un defecto de diseño en el transporte STDIO de MCP que afecta a los SDK oficiales de Anthropic. Una falla similar de inyección de comandos en LiteLLM, otra puerta de enlace de IA, fue explotada activamente y añadida al catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA en junio.
Ninguno de los CVE de Bifrost aparece en el catálogo KEV hasta la publicación.
Deja una respuesta