La cuenta predeterminada con pocos privilegios en el proxy LiteLLM podría elevarse al estado de administrador total y ejecutar código en el servidor encadenando tres vulnerabilidades, revelaron los investigadores de Obsidian Security.
LiteLLM es una puerta de enlace de IA de código abierto ampliamente implementada que media en llamadas a más de 100 proveedores de modelos detrás de una interfaz compatible con OpenAI.
Si un servidor se ve comprometido, quedan expuestas todas las claves de proveedor que posee el servidor, los secretos que descifran las credenciales almacenadas y todas las indicaciones y respuestas que pasan a través del servidor.
Obsidian califica CVSS de cadena completa 9.9 en el rango crítico. El mantenedor BerriAI ha incluido un conjunto completo de correcciones en LiteLLM v1.83.14-stable, que figura como versión del 2 de mayo en GitHub. Actualice a esa versión o posterior para cerrar las tres cadenas CVE.
3 errores
El primer enlace es CVE-2026-47101, Omisión de autorización. Cuando un usuario normal (internal_user) genera una clave API virtual, LiteLLM almacena el campo de rutas permitidas especificado por la persona que llama sin que coincida con la función del usuario.
Se supone que este campo limita lo que puede hacer la clave. En cambio, el proxy también lo trata como un permiso alternativo, por lo que los usuarios que no son administradores pueden crear claves con Allow_routes: («/*»), un comodín que llega a todas las rutas, incluidas las rutas exclusivas para administradores. Las mismas escrituras no verificadas ocurren en otros puntos finales de administración de claves, por lo que se necesitaron tres solicitudes de extracción para completar la solución.
Una vez que se pasa por alto la puerta raíz, se puede llegar al controlador que se encuentra detrás de ella. Algunos suponen que la puerta ya está cerrada y eso abre dos caminos.
Uno es CVE-2026-47102, escalada de privilegios. El punto final /user/update permite a los usuarios editar sus propios registros, pero no limita los campos en los que pueden escribir. user_role: la actualización automática realizada por «proxy_admin» se acepta y se guarda, promoviendo a la persona que llama a administrador de proxy completo. org_admin puede acceder a este punto final a través de la ruta de código legítima prevista sin necesidad de omitirlo. Se alcanza el usuario externo predeterminado después de CVE-2026-47101.
La puntuación de VulnCheck para asignar CVE es 8,7 para CVSS 4.0 y 8,8 para 3.1.
El otro, CVE-2026-40217, es un escape de zona protegida de código personalizado que compila y ejecuta Python proporcionado por el administrador. El punto final de producción ejecutó código a través de exec() sin ningún filtrado a nivel de fuente. Cuando exec() obtiene el dictado global sin __builtins__, Python inyecta silenciosamente el módulo integrado completo y pasa el código __import__, open y eval. Una carga útil simple que llama a os.system fue suficiente para el shell inverso.
X41 D-Sec descubrió de forma independiente otra ruta en el punto final del área de juegos /guardrails/test_custom_code y rompió la lista de denegación de expresiones regulares mediante la reescritura del código de bytes en tiempo de ejecución. Ambos terminaron con la ejecución de código del lado del servidor.
Lo que gana el atacante
LiteLLM está ubicado en un punto crítico, por lo que su alcance es amplio. La 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 proveedores configuradas, como OpenAI, Anthropic, Gemini, Bedrock y Azure.
Las claves en configuraciones o entornos son texto sin formato. Las claves de la base de datos están cifradas, pero se pueden recuperar utilizando una clave salt. Todas las indicaciones y respuestas enviadas a través del portal son legibles. En una implementación real, eventualmente se almacenarán 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 riesgo más grave no es lo que un atacante puede leer, sino lo que puede reescribir. Debido a que la puerta de enlace está en la red entre el agente de IA y el modelo, puede comprometer y cambiar las respuestas en tránsito.
Obsidian ha demostrado esto contra el código de Claude enviado a través de un proxy comprometido. Esta no es una inyección inmediata. En lugar de obligar al modelo a comportarse mal, el atacante utiliza el mecanismo de devolución de llamada integrado de LiteLLM. Este es un punto de extensión que se activa con cada solicitud y nunca es visible en la interfaz de usuario administrativa. La devolución de llamada intercambia la respuesta del modelo a la llamada falsa a la herramienta y reescribe el contexto de verificación de seguridad para que la acción se lea como autorizada.
En la demostración, cuando un desarrollador escribe una sola palabra, «Hola», un atacante abre un shell inverso en la máquina del desarrollador.
LiteLLM pasa la ruta de ejecución del código prevista a proxy_admin por separado de la cadena. Su compatibilidad con MCP permite a los administradores registrar un servidor MCP de salida estándar que el proxy inicia como un subproceso local. Esta es una compensación de diseño, no un error, y no se cambiará en un parche, por lo que contactar al administrador es efectivamente contactar con la ejecución del código.
Obsidian recreó conchas inversas de esta manera en v1.88.0. Un error real en el mismo mecanismo stdio-MCP, CVE-2026-42271, permite a las personas que llaman generar subprocesos a través del punto final de vista previa de MCP de LiteLLM. Esto fue explotado en estado salvaje y agregado al catálogo KEV de CISA a principios de este mes.
Ninguna de estas es la primera situación difícil para LiteLLM este año. En marzo, un compromiso de la cadena de suministro afectó 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 publicación.
Obsidian enmarca la cadena aquí como una falla revelada en una demostración funcional en lugar de un exploit visto en la naturaleza, pero su estado de proxy continúa convirtiéndola en un objetivo.
que hacer
Actualice a la versión 1.83.14 estable o posterior, que es la primera versión con un conjunto completo de correcciones. Luego audite. Vuelva a verificar cualquier cuenta que tenga proxy_admin y trate esa función como acceso a nivel de host. Verifique todas las barreras de seguridad de código personalizado en sus servidores proxy.
Verifique las devoluciones de llamada cargadas desde config.yaml en litellm_settings.callbacks. Las devoluciones de llamada nunca se muestran en la consola, ya que es exactamente donde se esconden los atacantes después de un RCE. Verifique la integridad del código implementado, no solo la configuración. Si sospecha de una infracción, rote las claves del proveedor, las credenciales de la base de datos y los tokens MCP almacenados.
Cuando un proxy se ve comprometido, se filtran más que solo datos. Se sitúa entre el agente y el modelo y puede falsificar las respuestas sobre las que actúa el agente. La cadena que lleva al atacante hasta allí ha perdido la confianza en cada capa. La puerta raíz confiaba en los campos especificados por la persona que llama, el controlador confiaba en la puerta raíz y nadie verificaba realmente.
Source link
