Wiz Research descubrió que muchos servidores de LiteLLM mantienen la clave de administrador predeterminada (sk-1234), permitiendo que atacantes roben claves de API y credenciales de la nube. También se identificaron fallos críticos que permiten la ejecución de código remoto y el bypass de autenticación en versiones antiguas. Se recomienda actualizar a la versión 1.84.0 o superior y cambiar inmediatamente la clave maestra por una aleatoria.





Casi uno de cada diez servidores LiteLLM expuestos a internet que Wiz Research analizó en febrero aceptaba sk-1234, la clave de administrador de ejemplo de la propia guía de configuración de LiteLLM.

LiteLLM es una pasarela de IA de código abierto, el software que una empresa coloca entre sus aplicaciones y los proveedores de modelos que paga. Esa clave es la credencial de administrador de la pasarela.

Cualquiera que la posea puede leer cada clave API de los proveedores de modelos almacenada en el servidor. En las pruebas de Wiz, también se alcanzó las credenciales de IAM de la nube de la máquina en la que se ejecuta la pasarela.

Cambiar la clave no requiere ninguna actualización y cierra todas las rutas del informe de Wiz que dependen de poseerla.

De dónde viene el número

Wiz realizó un análisis. Encontró 3.074 pasarelas LiteLLM en Shodan en febrero, y 294 de ellas aceptaban la clave.

En 191 de esas 294, no se había configurado ninguna clave, por lo que habrían aceptado cualquier cosa. El resto mantenía el valor de la guía de configuración.

Un segundo análisis en agosto encontró más de 85.000 instancias, pero Wiz dice que la mayoría parecen ser honeypots o sistemas de prueba, por lo que los dos recuentos no se pueden comparar. No hay una cifra actual.

Hasta el 9 de septiembre, la guía de configuración de LiteLLM sigue utilizando sk-1234, encima de un comentario que indica a los operadores que lo sustituyan por un valor aleatorio largo antes de cualquier uso real.

Por qué una clave importa tanto

La clave maestra hace dos trabajos a la vez, y eso es lo que hace que un valor predeterminado sea grave. Es la credencial de administrador y el interruptor que activa la autenticación.

Antes de la versión 1.82.0-stable, una pasarela que se iniciaba sin una clave maestra concedía derechos completos de administrador a cada solicitud entrante.

Un administrador en uno de estos servidores tiene mucho a su alcance. La pasarela puede contener una clave API para cada proveedor al que enruta, ver cada prompt y respuesta que pasa y conectarse a herramientas internas a través del Protocolo de Contexto de Modelo (MCP).

También suele ejecutarse con los permisos de nube de la carga de trabajo en la que está desplegada. El robo de claves de proveedores por sí solo permite a un atacante ejecutar cargas de trabajo de modelos a cargo de la víctima, un abuso conocido como LLMjacking.

Cómo la clave llega a la cuenta de la nube

LiteLLM permite a un administrador crear un endpoint de paso (pass-through), una ruta que reenvía solicitudes a cualquier URL que el administrador elija.

La URL de destino no se comprueba frente a rangos de direcciones privadas, localhost o direcciones de metadatos de la nube. Por lo tanto, un administrador puede apuntar una ruta al servicio de metadatos de la instancia y leer las credenciales de IAM que devuelve.

Cambiar a IMDSv2 no detiene esto. La documentación de LiteLLM indica que cualquier encabezado enviado con el prefijo x-pass- se pasa al destino sin el prefijo, y Wiz utilizó eso para enviar los encabezados que requiere IMDSv2.

Ninguna fuente informa que alguien haya hecho esto contra un despliegue real. Es una demostración y requiere primero acceso de administrador.

Wiz dice que la función probablemente funciona como se pretendía, porque el modelo de amenazas de LiteLLM trata a los administradores como confiables. No tiene CVE ni corrección.

El proyecto dice algo similar sobre la vía de entrada. Su política de seguridad publicada en GitHub enumera los ataques que requieren un error de configuración, como no establecer una clave maestra, como "explícitamente fuera de alcance" y no los trata como vulnerabilidades.

El fallo de guardrails y una severidad disputada

El único fallo de ejecución de código en el informe de Wiz es el CVE-2026-59821, y los investigadores y los mantenedores lo describen de manera muy diferente.

Wiz lo llama ejecución de código post-autenticación a nivel de root, y muestra una prueba que devuelve uid=0(root) dentro del contenedor de la pasarela. El aviso de LiteLLM para el mismo CVE lo califica como Bajo (2.1 en la escala CVSS), describiéndolo como un fallo que requiere una cuenta de altos privilegios.



Ambos describen el mismo comportamiento. Antes de 1.82.0-stable, los endpoints que crean y actualizan guardrails de código personalizado omitían el sandbox y las comprobaciones de patrones que aplicaba el endpoint de prueba, por lo que cualquiera que pudiera acceder a ellos podía enviar Python que se ejecutara dentro del contenedor.

El aviso añade que un despliegue sin clave maestra trataba a los llamadores como administradores de proxy, que es lo que ponía esos endpoints al alcance.

El informe de Wiz afirma que después de 1.82.0, un atacante con la clave predeterminada solo podría ejecutar código dentro de un sandbox. El propio registro de LiteLLM no respalda eso para todas las versiones.

Un aviso separado publicado en mayo, CVE-2026-40217, dice que el sandbox podía ser evadido utilizando técnicas de bytecode ejecutando código en el proceso del proxy, el cual, según el aviso, se ejecuta como root en la imagen de Docker predeterminada.

Cubre versiones desde la 1.81.8 hasta, pero sin incluir, la 1.83.10, y llegar al endpoint requiere una credencial de proxy-admin. La clave maestra es esa credencial.

Ambos fallos informados por Wiz fueron corregidos meses antes de su informe del 9 de septiembre, en febrero y abril, y sus CVE fueron publicados en julio.

Independientemente: fallos de LiteLLM que ya están siendo explotados

Estos son problemas más antiguos y ninguno de ellos es la ruta a las credenciales de la nube descritas anteriormente. Se enumeran aquí porque afectan al mismo producto y son fáciles de confundir.

CISA añadió un fallo de LiteLLM a su catálogo de Vulnerabilidades Explotadas Conocidas el 2 de septiembre. El CVE-2026-59822 (puntuación CVSS: 8.8), también encontrado por Wiz, permite que un atacante no autenticado abra una sesión MCP válida utilizando cualquier token Bearer, incluso uno de un solo carácter. Las agencias civiles federales tienen hasta el 16 de septiembre para solucionarlo.

Wiz vio que se utilizaba contra sus propios honeypots a partir del 7 de julio, en solicitudes que llevan tokens de un solo carácter para sondear los endpoints de listado de modelos. Wiz no describió ningún otro uso.

Ese fallo no llega a la ejecución de código ni a las rutas de credenciales mencionadas arriba. Wiz afirma que "solo permite el acceso al servidor MCP". Lo que puede alcanzar depende de a qué servidores de herramientas se haya conectado una organización.

El fallo de LiteLLM que los atacantes han usado para ejecutar código es otro diferente. El CVE-2026-42271 (puntuación CVSS: 8.7) permitía que cualquier usuario autenticado ejecutara comandos en el host a través de dos endpoints de prueba MCP, y Horizon3.ai informó en junio que podía encadenarse con un fallo de host-header de Starlette, CVE-2026-48710, para hacer lo mismo sin ninguna credencial.

Los honeypots de Wiz registraron que ese fallo se utilizó para instalar un minero de criptomonedas.

Microsoft publicó un caso en agosto en el que los atacantes ejecutaron comandos dentro de un proceso de pasarela LiteLLM, leyeron el entorno del contenedor para obtener la clave maestra, las claves del proveedor y la cadena de conexión de la base de datos, y luego usaron esa cadena para acceder a la base de datos PostgreSQL subyacente y copiar registros de las tablas de modelos y claves virtuales de LiteLLM.

Microsoft evalúa con alta confianza que los atacantes ganaron acceso a través de la pasarela expuesta y dice que el punto de entrada coincide con la cadena de CVE-2026-42271 y CVE-2026-48710. "Traten las pasarelas de IA como almacenes de secretos de Nivel 0", dijo la compañía.

Qué hacer ahora

Actualizar a la versión 1.84.0 o posterior cubre cada fallo de la tabla. Los rangos de versiones son los indicados en los avisos.

Fallo: CVE-2026-59822 (enlace), bypass de autenticación MCP. Qué permite: Sesión MCP autenticada desde cualquier token Bearer, llegando a las herramientas MCP configuradas. Versiones afectadas: Antes de 1.84.0. Corregido en: 1.84.0.

Fallo: CVE-2026-42271, ejecución de comandos en endpoint de prueba MCP. Qué permite: Cualquier usuario autenticado ejecuta comandos en el host. Versiones afectadas: 1.74.2 hasta, pero sin incluir, 1.83.7. Corregido en: 1.83.7.

Fallo: CVE-2026-59821 (enlace), bypass de comprobación de guardrails de código personalizado. Qué permite: Ejecución de código dentro del contenedor de la pasarela. Versiones afectadas: Antes de 1.82.0-stable. Corregido en: 1.82.0-stable.

Fallo: CVE-2026-40217 (enlace), escape de sandbox de guardrail. Qué permite: Ejecución de código como root en la imagen de contenedor predeterminada. Versiones afectadas: 1.81.8 hasta, pero sin incluir, 1.83.10. Corregido en: 1.83.10 (aunque el texto del aviso dice 1.83.11).


1. Cambia la clave maestra de sk-1234 a un valor aleatorio largo. Esto no requiere actualización. Comprueba primero si se ha establecido una clave de salt separada, ya que el procedimiento de rotación (enlace) difiere y usar la incorrecta puede dejar las credenciales almacenadas ilegibles.
2. Actualiza a 1.84.0 o posterior. Esa versión está por encima de la versión corregida de cada fallo de la tabla.
3. Si aún no puedes actualizar, bloquea /mcp/ y los dos endpoints de prueba MCP, POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list, en tu proxy inverso o pasarela API.
4. Bloquea también POST /guardrails/test_custom_code y restringe POST /guardrails y PUT /guardrails/{guardrail_id} a administradores. Estas son las soluciones temporales en los avisos de LiteLLM.
5. Revisa los endpoints de paso en la pasarela, restringe el acceso de red saliente del contenedor y asigna a la carga de trabajo el rol de IAM de nube más restringido con el que pueda trabajar.
6. Si crees que un atacante pudo haber tenido acceso, revisa la lista de guardrails en busca de entradas que no hayas creado y reinicia el proceso para borrar el código mantenido en memoria, luego rota las claves del proveedor, la clave maestra y las credenciales de la base de datos. Actualizar no elimina ni un guardrail que un atacante haya registrado ni una clave SSH que hayan añadido.

No hay un parche para la ruta de paso a los metadatos de la instancia, porque LiteLLM no lo trata como un fallo. Los límites de red saliente y los roles de IAM restringidos son los únicos controles disponibles.

Ninguna fuente explica cómo comprobar si las rutas MCP o de paso están habilitadas en una pasarela que hayas heredado. Las consultas de búsqueda de Microsoft encuentran la explotación, no la configuración.

Fuente:
THN