Casi uno de cada diez servidores LiteLLM expuestos a Internet que Wiz Research escaneó en febrero aceptaban 'sk-1234', la clave de administrador de ejemplo que aparece en la propia guía de configuración de LiteLLM.
LiteLLM es una puerta de enlace de IA de código abierto, el software que una empresa coloca entre sus aplicaciones y los proveedores de modelos que contrata. Esa clave es la credencial de administrador de la puerta de enlace.
Quien la posea puede leer todas las claves de API de los proveedores de modelos almacenadas en el servidor. En las pruebas de Wiz, también permitía acceder a las credenciales de IAM en la nube de la máquina donde se ejecuta la puerta de enlace.
Cambiar la clave no requiere una actualización y cierra todas las rutas del informe de Wiz que dependen de poseerla.
De dónde proviene la cifra
Wiz realizó un escaneo. En febrero encontró 3074 puertas de enlace LiteLLM en Shodan, 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 valor. El resto tenía el valor de la guía de configuración sin modificar.
Un segundo escaneo en agosto encontró más de 85 000 instancias, pero Wiz afirma que la mayoría parecen ser honeypots o sistemas de prueba, por lo que las dos cifras no son comparables. No hay una cifra actual.
A fecha del 9 de septiembre, la guía de configuración de LiteLLM todavía usa 'sk-1234', encima de un comentario que indica a los operadores que la reemplacen por un valor aleatorio largo antes de cualquier uso real.
Por qué una sola clave es tan importante
La clave maestra cumple dos funciones a la vez, y eso es lo que hace que un valor predeterminado sea grave. Es la credencial de administrador y el interruptor que habilita la autenticación.
Antes de la versión 1.82.0-stable, una puerta de enlace que se iniciaba sin clave maestra otorgaba derechos de administrador completos a todas las solicitudes entrantes.
Un administrador en uno de estos servidores tiene mucho a su alcance. La puerta de enlace puede contener una clave de API para cada proveedor al que enruta, ver cada indicación y respuesta que pasa por ella, y conectarse a herramientas internas a través del Protocolo de Contexto de Modelo (MCP).
También suele ejecutarse con los permisos en la nube de la carga de trabajo donde se despliega. Las claves de proveedor robadas por sí solas permiten a un atacante ejecutar cargas de trabajo de modelos a cargo de la víctima, un abuso conocido como LLMjacking.
Cómo llega la clave a la cuenta en la nube
LiteLLM permite a un administrador crear un punto final de paso directo, una ruta que reenvía solicitudes a cualquier URL que elija el administrador.
La URL de destino no se verifica contra rangos de direcciones privadas, localhost ni direcciones de metadatos en 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 evita esto. LiteLLM documenta que cualquier encabezado enviado con el prefijo x-pass- se pasa al destino con el prefijo eliminado, y Wiz usó 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 acceso de administrador primero.
Wiz dice que la función posiblemente funcione según lo previsto, porque el modelo de amenazas de LiteLLM considera a los administradores como confiables. No tiene CVE ni corrección.
El proyecto dice algo similar sobre la forma de entrada. Su política de seguridad publicada 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 barrera de seguridad y una gravedad disputada
El único fallo de ejecución de código en el informe de Wiz es CVE-2026-59821, y los investigadores y los mantenedores lo describen de manera muy diferente.
Wiz lo llama ejecución de código posterior a la autenticación a nivel de root, y muestra una prueba que devuelve uid=0(root) dentro del contenedor de la puerta de enlace. 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 con altos privilegios.
Ambos describen el mismo comportamiento. Antes de 1.82.0-stable, los puntos finales que crean y actualizan barreras de seguridad de código personalizado omitían la sandbox y las comprobaciones de patrones que aplicaba el punto final de prueba, por lo que cualquiera que pudiera alcanzarlos podía enviar código Python que se ejecutaba dentro del contenedor.
El aviso añade que un despliegue sin clave maestra trataba a los llamantes como administradores del proxy, lo que ponía esos puntos finales a su alcance.
El informe de Wiz afirma que después de 1.82.0, un atacante con la clave predeterminada solo podía ejecutar código dentro de una sandbox. El propio registro de LiteLLM no respalda eso para todas las versiones.
Un aviso separado publicado en mayo, CVE-2026-40217, dice que la sandbox podía escaparse usando técnicas de bytecode ejecutando código en el proceso proxy, que según el aviso se ejecuta como root en la imagen Docker predeterminada.
Cubre versiones desde 1.81.8 hasta, pero sin incluir, 1.83.10, y alcanzar el punto final requiere una credencial de administrador del proxy. La clave maestra es esa credencial.
Ambos fallos reportados por Wiz se corrigieron meses antes de su informe del 9 de septiembre, en febrero y abril, y sus CVE se publicaron en julio.
Aparte: los fallos de LiteLLM que ya están siendo explotados
Estos son problemas más antiguos, y ninguno es la ruta a las credenciales en la nube descrita anteriormente. Se enumeran aquí porque afectan al mismo producto y son fáciles de confundir con él.
CISA añadió un fallo de LiteLLM a su catálogo de vulnerabilidades explotadas conocidas el 2 de septiembre. CVE-2026-59822 (puntuación CVSS: 8.8), también encontrado por Wiz, permite a un atacante no autenticado abrir una sesión MCP válida usando cualquier token Bearer, incluido uno de un solo carácter. Las agencias civiles federales tienen hasta el 16 de septiembre para abordarlo.
Wiz lo vio usarse contra sus propios honeypots a partir del 7 de julio, en solicitudes que llevan tokens de un solo carácter para sondear puntos finales de listado de modelos. Wiz no describió ningún otro uso.
Ese fallo no alcanza las rutas de ejecución de código o credenciales anteriores. Wiz afirma que "solo permite el acceso al servidor MCP". A qué puede llegar depende de qué servidores de herramientas haya conectado una organización.
El fallo de LiteLLM que los atacantes han usado para ejecutar código es otro. CVE-2026-42271 (puntuación CVSS: 8.7) permitía a cualquier usuario autenticado ejecutar comandos en el host a través de dos puntos finales de prueba MCP, y Horizon3.ai informó en junio que podía encadenarse con un fallo de encabezado de host de Starlette, CVE-2026-48710, para hacer lo mismo sin credenciales en absoluto.
Los honeypots de Wiz registraron que ese fallo se usó para instalar un minero de criptomonedas.
Microsoft publicó un caso en agosto en el que los atacantes ejecutaron comandos dentro de un proceso de puerta de enlace LiteLLM, leyeron el entorno del contenedor para obtener la clave maestra, las claves de 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 obtuvieron acceso a través de la puerta de enlace expuesta y dice que el punto de entrada coincide con la cadena CVE-2026-42271 y CVE-2026-48710. "Trate las puertas de enlace de IA como almacenes de secretos de Nivel 0", dijo la compañía.
Qué hacer ahora
Actualizar a 1.84.0 o posterior cubre todos los fallos de la tabla. Los rangos de versiones son los indicados en los avisos.
- Cambie la clave maestra de 'sk-1234' a un valor aleatorio largo. Esto no requiere actualización. Verifique primero si hay una clave de salt separada configurada, porque el procedimiento de rotación difiere y usar el incorrecto puede dejar credenciales almacenadas ilegibles.
- Actualice a 1.84.0 o posterior. Esa versión está por encima de la versión corregida de cada fallo en la tabla.
- Si no puede actualizar aún, bloquee /mcp/ y los dos puntos finales de prueba MCP, POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list, en su proxy inverso o puerta de enlace API.
- También bloquee POST /guardrails/test_custom_code, y restrinja POST /guardrails y PUT /guardrails/{guardrail_id} a administradores. Estas son las soluciones alternativas en los propios avisos de LiteLLM.
- Revise los puntos finales de paso directo en la puerta de enlace, restrinja el acceso de red saliente del contenedor y otorgue a la carga de trabajo el rol de IAM en la nube más limitado posible.
- Si cree que un atacante pudo haber tenido acceso, revise la lista de barreras de seguridad en busca de entradas que no creó y reinicie el proceso para borrar el código en memoria, luego rote las claves de proveedor, la clave maestra y las credenciales de la base de datos. Actualizar no elimina ni una barrera de seguridad que un atacante haya registrado ni una clave SSH que haya añadido.
No hay parche para la ruta de paso directo a los metadatos de la instancia, porque LiteLLM no lo considera un fallo. Los límites de red saliente y los roles de IAM limitados son los únicos controles disponibles.
Ninguna fuente explica cómo verificar si las rutas MCP o de paso directo están habilitadas en una puerta de enlace que haya heredado. Las consultas de búsqueda de Microsoft encuentran explotación, no configuración.
