La peor pesadilla de un paranoico se hizo realidad: un fallo en LiteLLM sustituye las respuestas de la IA por código ajeno

Las pasarelas de IA se están convirtiendo cada vez más en un punto por el que pasan no solo las solicitudes a los modelos, sino también las claves de acceso, datos internos y las instrucciones de los agentes. Los especialistas de Obsidian Security revelaron una cadena de tres vulnerabilidades en LiteLLM que permite a un usuario con privilegios mínimos obtener el control total del servidor proxy y ejecutar código en el equipo host.

LiteLLM funciona como una pasarela única entre aplicaciones y más de cien proveedores de modelos de IA a través de una interfaz compatible con OpenAI. Si se compromete ese nodo, el atacante obtiene acceso a las claves de los proveedores, a los datos para descifrar cuentas guardadas, así como a las solicitudes y respuestas que pasan por el proxy.

La primera vulnerabilidad, CVE-2026-47101 (8.8 en la escala CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), está relacionada con la comprobación de permisos. Un usuario normal podía crear una clave de API virtual y especificar por sí mismo las rutas permitidas para ella. LiteLLM no verificaba el campo allowed_routes con el rol del usuario, por lo que el valor ["/*"] daba acceso a todas las rutas, incluidas las administrativas.

Tras eludir la comprobación, quedaban disponibles funciones que asumían que el filtrado de permisos ya se había aplicado. Mediante CVE-2026-47102 (8.8 en la escala CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) el usuario podía actualizar su propio registro y asignarse el rol proxy_admin. Y mediante CVE-2026-40217 (8.8 en la escala CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) se abría otra vía: el mecanismo Custom Code Guardrail ejecutaba código Python con privilegios de administrador mediante exec() sin un aislamiento completo, por lo que un comando sencillo podía llevar a la ejecución de código en el servidor.

El riesgo principal no se limita al robo de claves. LiteLLM está entre el agente de IA y el modelo, por lo que una pasarela comprometida puede modificar las respuestas en su trayecto hacia el agente. En una demostración de Obsidian Security con Claude Code, el atacante utilizó el mecanismo integrado de callback, suplantó la respuesta del modelo por una llamada falsa a una herramienta y logró ejecutar una shell inversa en la máquina del desarrollador. La demostración es de prueba; por ahora no hay indicios de uso de estas vulnerabilidades en ataques reales.

Los especialistas señalaron además que el acceso administrativo a LiteLLM ya equivale de por sí a un acceso al host. El soporte para MCP permite al administrador registrar servidores stdio MCP que el proxy ejecuta como subprocesos locales. Ese mecanismo se considera un compromiso arquitectónico, no un error aislado, por lo que la actualización no cambia el propio modelo de confianza.

BerriAI cerró la cadena en LiteLLM v1.83.14-stable, publicada el 2 de mayo. Para reducir el riesgo, hay que actualizar a esa versión o a una posterior, comprobar a todos los usuarios con el rol proxy_admin, revisar el Custom Code Guardrail, examinar el callback en config.yaml, verificar la integridad del código desplegado y, si se sospecha una compromisión, cambiar las claves de los proveedores, las credenciales de la base de datos y los tokens MCP guardados.