Investigadores de Obsidian Security descubrieron que una cuenta de bajos privilegios en LiteLLM puede obtener control total del servidor mediante la combinación de tres vulnerabilidades críticas. Esto permite a un atacante robar claves de API, leer datos sensibles y ejecutar código remoto para comprometer máquinas de desarrolladores. La solución es actualizar a la versión v1.83.14-stable o posterior y auditar los permisos de administrador.

Una cuenta predeterminada de bajos privilegios en un proxy de LiteLLM puede escalar a administrador total y ejecutar código en el servidor encadenando tres vulnerabilidades, según revelaron investigadores de Obsidian Security.

LiteLLM es una pasarela de IA de código abierto ampliamente desplegada que gestiona llamadas a más de 100 proveedores de modelos detrás de una interfaz compatible con OpenAI.

La toma de control de un servidor expone cada clave de proveedor que posea, los secretos que descifran sus credenciales almacenadas y cada prompt y respuesta que pase a través de él.

Obsidian califica la cadena completa con un CVSS 9.9, en el rango Crítico. BerriAI, el mantenedor, incluyó el conjunto completo de correcciones en LiteLLM v1.83.14-stable, que GitHub lista como lanzada el 2 de mayo. Actualiza a esa versión o posterior para cerrar la cadena de tres CVE.

Los tres errores

El primer enlace es CVE-2026-47101, un bypass de autorización. Cuando un usuario regular (internal_user) genera una clave API virtual, LiteLLM almacena el campo allowed_routes proporcionado por el llamador sin verificarlo contra el rol del usuario.

Se supone que el campo debe restringir lo que una clave puede hacer. En su lugar, el proxy también lo trata como una concesión de respaldo, por lo que un no administrador puede crear una clave con allowed_routes: ["/*"], un comodín que llega a todas las rutas, incluidas las exclusivas de administrador. Esta misma escritura sin verificar aparece en otros endpoints de gestión de claves, razón por la cual la corrección requirió tres pull requests para implementarse.

Con la puerta de rutas saltada, los controladores detrás de ella se vuelven accesibles. Varios de ellos asumen que la puerta ya ha realizado el filtrado, lo que abre dos caminos.

Uno es CVE-2026-47102, escalada de privilegios. El endpoint /user/update permite que un usuario edite su propio registro, pero no restringe qué campos puede escribir. Se acepta y guarda una auto-actualización con user_role: "proxy_admin", promoviendo al llamador a administrador total del proxy. Un org_admin puede acceder a este endpoint a través de una ruta de código legítima e intencionada sin necesidad de bypass; un internal_user predeterminado llega a él después de CVE-2026-47101.

VulnCheck, que asignó el CVE, lo califica con 8.7 bajo CVSS 4.0 y 8.8 bajo 3.1.

El otro es CVE-2026-40217, un escape de sandbox en el Custom Code Guardrail, que compila y ejecuta Python proporcionado por el administrador. Los endpoints de producción ejecutaban el código a través de exec() sin filtrado a nivel de fuente. Cuando exec() recibe un diccionario de globales sin __builtins__, Python inyecta silenciosamente el módulo builtins completo, lo que otorga al código __import__, open y eval. Una carga útil simple llamando a os.system fue entonces suficiente para obtener una reverse shell.

Una ruta separada en el endpoint de patio de juegos /guardrails/test_custom_code, encontrada independientemente por X41 D-Sec, derrotó una lista de denegación regex mediante la reescritura de bytecode en tiempo de ejecución. Ambas terminaron en la ejecución de código en el lado del servidor.

Qué obtiene un atacante

LiteLLM se encuentra en un punto crítico, por lo que el alcance es amplio. Una cadena completa expone la clave maestra, la clave de sal que descifra las credenciales almacenadas y la URL de la base de datos. También expone cada clave de proveedor configurada, para OpenAI, Anthropic, Gemini, Bedrock, Azure y el resto.

Las claves en la configuración o el entorno están en texto plano; las claves en la base de datos están cifradas pero son recuperables con la clave de sal. Todo lo enviado a través de la pasarela, prompts y respuestas, se vuelve legible, que en despliegues reales es donde terminan los PII, código fuente, tickets internos y secretos pegados.



Si el proxy también funciona como una pasarela de Model Context Protocol (MCP) o de agentes, los tokens OAuth y las credenciales de herramientas también están en el alcance.

El riesgo más agudo no es lo que un atacante lee, sino lo que puede reescribir. La pasarela se sitúa en la línea entre un agente de IA y el modelo, por lo que un compromiso permite alterar las respuestas en tránsito.

Obsidian demostró esto contra Claude Code enrutado a través de un proxy comprometido. Esto no es una inyección de prompts. En lugar de persuadir al modelo para que se comporte mal, el atacante utiliza el mecanismo de callback integrado de LiteLLM, un punto de extensión que se dispara en cada solicitud y que nunca aparece en la interfaz de administrador. El callback intercambia la respuesta del modelo por una llamada a herramienta falsificada y reescribe el contexto de verificación de seguridad para que la acción parezca aprobada.

En la demo, el desarrollador escribe una palabra, "hello", y el atacante lanza una reverse shell en la máquina del desarrollador.

Independientemente de la cadena, LiteLLM ofrece a un proxy_admin una ruta de ejecución de código intencionada: su soporte de MCP permite a un administrador registrar servidores MCP stdio que el proxy lanza como subprocesos locales. Esto es una decisión de diseño más que un error, y los parches no lo cambian, por lo que llegar a ser administrador es efectivamente llegar a la ejecución de código.

Obsidian reprodujo una reverse shell de esta manera en v1.88.0. Un error genuino en la misma maquinaria stdio-MCP, CVE-2026-42271, permitió a los llamadores generar subprocesos a través de los endpoints de vista previa de MCP de LiteLLM; fue explotado en entornos reales y añadido al catálogo KEV de CISA a principios de este mes.

Nada de esto es el primer tropiezo de LiteLLM este año. En marzo, un compromiso de la cadena de suministro instaló un backdoor en dos versiones de LiteLLM en PyPI, y en abril, una inyección SQL crítica fue explotada a las 36 horas de su divulgación.

Obsidian presenta la cadena aquí como un fallo divulgado con una demo funcional, no como una explotación vista en la naturaleza, pero la posición del proxy sigue convirtiéndolo en un objetivo.

Qué hacer

Actualiza a v1.83.14-stable o posterior, la primera versión con el conjunto completo de correcciones. Luego audita. Vuelve a verificar cada cuenta que tenga el rol de proxy_admin y trata ese rol como acceso a nivel de host. Revisa cada Custom Code Guardrail en el proxy.

Comprueba los callbacks cargados desde config.yaml bajo litellm_settings.callbacks, ya que esos nunca aparecen en la consola y son exactamente donde un atacante post-RCE se escondería. Verifica la integridad del código desplegado, no solo la configuración. Si sospechas de una exposición, rota las claves de proveedor, las credenciales de la base de datos y cualquier token MCP almacenado.

Un proxy comprometido no solo filtra datos. Se sitúa entre el agente y el modelo y puede falsificar las respuestas sobre las que el agente actúa. La cadena que lleva a un atacante hasta allí es la confianza mal depositada en cada capa: la puerta de rutas confió en el campo proporcionado por el llamador, los controladores confiaron en la puerta de rutas, y nadie verificó realmente nada.

Fuente:
THN