Alerta LiteLLM expuesto: tres CVE críticos revelan la fragilidad de la confianza mutable

La cadena de fallos divulgada por Obsidian Security contra LiteLLM es un recordatorio duro de cómo decisiones de diseño, validaciones ausentes y puntos únicos de control pueden convertir una cuenta de bajo privilegio en un acceso total al servidor. LiteLLM actúa como pasarela para más de 100 proveedores de modelos y, en muchos despliegues, procesa prompts, respuestas y claves sensibles, por eso la exposición es proporcionalmente grave: robo de claves de proveedor, de la sal de cifrado de credenciales, de la URL de la base de datos y capacidad para alterar las respuestas a agentes y usuarios.

La ruta de explotación encadena tres CVE críticos: CVE-2026-47101 permite saltarse la autorización al aceptar sin validar un campo caller-supplied allowed_routes que puede ser "/*"; CVE-2026-47102 permite que un usuario se autoeleve cambiando su user_role a "proxy_admin" a través de /user/update; y CVE-2026-40217 es una fuga del sandbox en el guardrail de código personalizado que ejecuta código Python con exec() y termina exponiendo __builtins__ y funciones como __import__ o os.system. Obsidian califica la cadena completa en CVSS 9.9, y BerriAI publicó el conjunto completo de parches en la versión v1.83.14-stable, listada en GitHub como publicada el 2 de mayo; actualizar a esa versión o posteriores es la primera y más urgente acción. Ver el repositorio oficial: GitHub — LiteLLM v1.83.14-stable y el aviso del investigador en la web de seguridad para contexto general: Obsidian Security.

Más allá del exploit técnico, la geometría del ataque muestra una lección clásica: confianza mutable en varias capas. El proxy aceptó una ruta de acceso dictada por el cliente y luego el resto del código asumió que esa puerta de enrutamiento había hecho todo el filtrado. Esa confianza encadenada es la que permitió que un fallo relativamente sencillo en la gestión de claves virtuales se convirtiera en control remoto del servidor.

La consecuencia operacional es doble y peligrosa. Por un lado, un atacante que logra la cadena puede leer todo lo que pasa por la pasarela, incluyendo PII, fragmentos de código y secretos que los usuarios pegan en prompts. Por otro lado, y quizás más sutil pero más explotable por agentes autónomos, el atacante puede alterar respuestas en tránsito y hacer que un agente o un flujo automatizado ejecute acciones maliciosas sin que el modelo haya sido manipulado por prompt injection: la pasarela puede forjar tool calls y reescribir contexto de seguridad usando callbacks internos que no aparecen en la UI.

Hay además vectores independientes que agravan el riesgo: el soporte MCP (Model Context Protocol) de LiteLLM permite que un proxy_admin registre servidores stdio locales que el proxy lanza como subprocessos —una decisión de diseño que implica que tener rol proxy_admin es, en la práctica, equivalente a tener capacidad de ejecutar código en la máquina. Un CVE distinto, CVE-2026-42271, afectó el preview de MCP y ya fue observado en explotaciones reales y listado en la catalogación de CISA para vulnerabilidades explotadas activamente; vale la pena consultarlo en el catálogo conocido de CISA: CISA KEV.

¿Qué deben hacer los responsables de infra y seguridad ahora mismo? La respuesta empieza por la actualización: parchee a v1.83.14-stable o superior inmediatamente. Después de aplicar la corrección, no basta con cerrar el agujero: hay que asumir que cualquier instancia comprometida pudo haber tenido acceso a claves y a los datos en tránsito, por lo que la acción siguiente es una auditoría y rotación de secretos.

Audite y trate el rol proxy_admin como acceso a nivel de host: revalide cada cuenta con ese rol, cierre cuentas obsoletas y exija autenticación fuerte y just-in-time donde sea posible. Revise todas las Custom Code Guardrails y busque cargas útiles sospechosas; recuerde que las callbacks declaradas en configuración (p. ej. litellm_settings.callbacks) no aparecen en la consola y son un lugar lógico donde un atacante post-explotación ocultaría persistencia o trampas. Verifique además la integridad del código desplegado frente a la fuente en Git y hashes de release firmados: no confíe solo en la configuración.

Si sospecha compromiso, rote inmediatamente todas las claves de proveedor (OpenAI, Anthropic, Gemini, Bedrock, Azure, etc.), cambie la sal y las credenciales de la base de datos y los tokens MCP; considere que las claves en ficheros de configuración o variables de entorno podrían haber sido leídas en texto claro. Active detección de anomalías en logs y tráfico: picos de solicitudes a endpoints administrativos, cambios en campos de usuarios, creación de claves virtuales con allowed_routes amplios o callbacks nuevos son indicadores de compromiso.

En lo operativo y de arquitectura a medio plazo, replantee la ubicación de este tipo de pasarela crítica y su modelo de confianza: minimizar la cantidad de datos sensibles que atraviesan un único punto, segregar redes y roles, usar gestores de secretos externos y cifrado con separación de funciones para que la pasarela no tenga acceso directo a claves maestras son medidas que reducen el blast radius. Asimismo, las reglas de ejecución de código (guardrails) deben diseñarse con modelos de seguridad por defecto, filtros a nivel de bytecode y no solo regex, y evitar exec() directo con globals incompletos.

También es momento de revisar la cadena de suministros y el proceso de actualizaciones: LiteLLM ya sufrió intentos de backdoor en PyPI en marzo y una inyección SQL explotada en abril, lo que demuestra que proyectos de infraestructura de IA son blancos atractivos. Firme y verifique tarballs y paquetes, aplique escaneos de dependencias y use políticas de bloqueo de versiones en entornos productivos.

Para equipos que operan agentes o gateways de modelos, este incidente debe cambiar la matriz de amenaza: una pasarela comprometida no solo filtra datos, puede alterar la propia lógica que gobierna a los agentes. Considere controles finales en el endpoint que validen la integridad de las respuestas antes de ejecutar acciones críticas, y mantenga una separación clara entre datos sensibles y prompts que acceden a sistemas productivos.

En resumen: actualice a la versión parcheada, audite roles y callbacks, rote secretos si hubo exposición y reevalúe la arquitectura de confianza que pone a un único servicio en el centro del tráfico de IA. El fallo no es solo técnico: es una lección operativa sobre cómo diseñamos y defendemos las puertas que median entre humanos, agentes y modelos.