Una cuenta predeterminada con bajos privilegios en un proxy LiteLLM puede ascender a administrador completo y ejecutar código en el servidor encadenando tres vulnerabilidades, revelaron investigadores de Obsidian Security.
LiteLLM es una puerta de enlace de IA de código abierto ampliamente implementada que gestiona llamadas a más de 100 proveedores de modelos detrás de una interfaz compatible con OpenAI.
Una toma de control del servidor expone cada clave de proveedor que posee, los secretos que descifran sus credenciales almacenadas y cada mensaje y respuesta que pasa a través de él.
Obsidian califica el CVSS de cadena completa con 9.9, en el rango Crítico. berriaiel mantenedor, incluyó el conjunto de correcciones completo en LiteLLM v1.83.14-stable, que GitHub enumera como lanzado el 2 de mayo. Actualice a esa versión o posterior para cerrar la cadena de tres CVE.
los tres bichos
El primer enlace es CVE-2026-47101una omisión de autorización. Cuando un usuario normal (un usuario interno) genera una clave API virtual, LiteLLM almacena el campo de rutas permitidas proporcionado por la persona que llama sin compararlo con la función del usuario.
Se supone que el campo limita lo que puede hacer una clave. En cambio, el proxy también lo trata como una concesión alternativa, por lo que alguien que no sea administrador puede crear una clave con Allow_routes: [«/*»]un comodín que llega a todas las rutas, incluidas las exclusivas para administradores. La misma escritura no verificada aparece en los otros puntos finales de administración de claves, razón por la cual la solución requirió tres solicitudes de extracción para llegar.
Una vez pasada la puerta de ruta, los manejadores detrás de ella se vuelven accesibles. Varios de ellos suponen que la puerta ya ha pasado el control, lo que abre dos caminos.
uno es CVE-2026-47102escalada de privilegios. El punto final /user/update permite al usuario editar su propio registro, pero no restringe qué campos puede escribir. Se acepta y guarda una actualización automática con user_role: «proxy_admin», lo que promueve a la persona que llama a administrador de proxy completo. Un org_admin puede llegar a este punto final a través de una ruta de código legítima y prevista sin necesidad de omitirla; un usuario interno predeterminado lo alcanza después de CVE-2026-47101.
VulnCheck, que asignó el CVE, le otorga una puntuación de 8,7 en CVSS 4.0 y 8,8 en 3.1.
El otro es CVE-2026-40217un escape de espacio aislado en Custom Code Guardrail, que compila y ejecuta Python proporcionado por el administrador. Los puntos finales de producción ejecutaron el código a través de exec() sin filtrado a nivel de fuente. Cuando exec() obtiene un dictado global sin __builtins__, Python inyecta silenciosamente el módulo integrado completo, que entrega el código __import__, open y eval. Una carga útil simple que llamara a os.system fue suficiente para un shell inverso.
Una ruta separada en el punto final del área de juegos /guardrails/test_custom_code, encontrada de forma independiente por X41 D-Secderrotó una lista de denegación de expresiones regulares mediante la reescritura del código de bytes en tiempo de ejecución. Ambos terminaron en la ejecución de código del lado del servidor.
Lo que obtiene un atacante
LiteLLM se encuentra en un cuello de botella, por lo que el alcance es amplio. Una cadena completa expone la clave maestra, la clave salt que descifra las credenciales almacenadas y la URL de la base de datos. También expone todas las claves de proveedor configuradas, para OpenAI, Anthropic, Gemini, Bedrock, Azure y el resto.
Las claves en la configuración o el entorno son texto sin formato; Las claves de la base de datos están cifradas pero se pueden recuperar con la clave salt. Todo lo que se envía a través de la puerta de enlace, indicaciones y respuestas, se vuelve legible, que en implementaciones reales es donde terminan la PII, el código fuente, los tickets internos y los secretos pegados.
Si el proxy también se ejecuta como protocolo de contexto modelo (MCP) o puerta de enlace de agente, los tokens de OAuth y las credenciales de herramientas también están dentro del alcance.
El mayor riesgo no es lo que lee un atacante sino lo que puede reescribir. La puerta de enlace se encuentra en el cable entre un agente de IA y el modelo, por lo que un compromiso le permite alterar las respuestas en tránsito.
Obsidiana demostrada esto contra Claude Code enrutado a través de un proxy comprometido. Esta no es una inyección inmediata. En lugar de persuadir al modelo para que se comporte mal, el atacante utiliza el mecanismo de devolución de llamada integrado de LiteLLM, un punto de extensión que se activa con cada solicitud y nunca aparece en la interfaz de usuario del administrador. La devolución de llamada intercambia la respuesta del modelo por una llamada de herramienta falsificada y reescribe el contexto de verificación de seguridad para que la acción se lea como aprobada.
En la demostración, el desarrollador escribe una palabra, hola, y el atacante abre un shell inverso en la máquina del desarrollador.
Separado de la cadena, LiteLLM le entrega a proxy_admin una ruta de ejecución de código intencional: su soporte MCP le permite a un administrador registrar servidores stdio MCP que el proxy inicia como subprocesos locales. Se trata de una compensación de diseño más que de un error, y los parches no lo cambian, por lo que llegar al administrador es efectivamente llegar a la ejecución del código.
Obsidian reprodujo un caparazón inverso de esta manera en v1.88.0. Un error genuino en la misma maquinaria stdio-MCP, CVE-2026-42271, permite a las personas que llaman generar subprocesos a través de los puntos finales de vista previa de MCP de LiteLLM; fue explotado en estado salvaje y agregado al catálogo KEV de CISA a principios de este mes.
Nada de esto es el primer momento difícil para LiteLLM este año. En marzo, un compromiso de la cadena de suministro bloqueó dos versiones de LiteLLM en PyPI y, en abril, se aprovechó una inyección SQL crítica dentro de las 36 horas posteriores a la divulgación.
Obsidian enmarca la cadena aquí como una falla revelada con una demostración funcional, no como una explotación vista en la naturaleza, pero la posición del proxy sigue convirtiéndola en un objetivo.
que hacer
Actualice a v1.83.14 estable o posterior, la primera versión con el conjunto completo de correcciones. Luego audite. Vuelva a verificar cada cuenta que tenga proxy_admin y trate esa función como acceso a nivel de host. Revise cada medida de seguridad de código personalizado en el proxy.
Verifique las devoluciones de llamada cargadas desde config.yaml en litellm_settings.callbacks, ya que nunca aparecen en la consola y son exactamente donde se escondería un atacante posterior a RCE. Verifique la integridad del código implementado, no solo la configuración. Si se sospecha una exposición, rote las claves del proveedor, las credenciales de la base de datos y los tokens MCP almacenados.
Un proxy comprometido no sólo filtra datos. Se sitúa entre el agente y el modelo y puede forjar las respuestas sobre las que actúa el agente. La cadena que lleva a un atacante allí tiene una confianza fuera de lugar en cada capa: la puerta de ruta confiaba en el campo proporcionado por la persona que llama, los controladores confiaban en la puerta de ruta y nadie realmente comprobó.
