Wiz: casi 1 de cada 10 gateways de LiteLLM expuestos aceptan la clave de administrador de ejemplo sk-1234

El 9 de septiembre de 2026, Wiz Research publicó un estudio sobre LiteLLM, la puerta de enlace de IA de código abierto que se sitúa entre las aplicaciones y los proveedores de modelos a los que pagan, e informó de que 294 de las 3.074 implementaciones de LiteLLM a las que pudo llegar en la internet pública —el 9,6 %, casi una de cada diez— aceptaban sk-1234, la clave maestra de ejemplo impresa en la propia documentación de configuración del proyecto, o no requerían ninguna credencial. Esa cadena no es una clave de API ordinaria: en LiteLLM es tanto la credencial de administrador como el interruptor que activa la autenticación, por lo que quien la presente puede leer todas las claves de proveedores de modelos almacenadas en la puerta de enlace, observar cada prompt y cada completion que pasan por ella y llegar a cada servidor de herramientas conectado mediante el Model Context Protocol. Los coautores de Wiz, Amitai Cohen y Yaara Shriki, encadenaron ese acceso con la ejecución de código a nivel de root y con el robo de las credenciales de IAM en la nube del host. Este relato se basa en el informe de Wiz, los propios avisos de seguridad de LiteLLM y la lista de vulnerabilidades conocidas explotadas de CISA que siguió, y el archivo de incidentes de IA contiene este registro junto con sus vecinos, cada uno con sus propias fuentes, gravedad y grado de confianza.

La fecha de publicación es la única fecha que lleva el registro, y es una fecha de publicación. El escaneo que hay detrás del titular se ejecutó en febrero de 2026; los dos fallos de código que describe Wiz ya contaban con correcciones publicadas a más tardar a mediados de mayo, en versiones que los propios registros del proyecto fechan en marzo y mayo; los identificadores CVE se emitieron en julio; y la inclusión en el catálogo llegó en septiembre. Casi todo en el informe ya era antiguo para cuando se imprimió, lo cual constituye una gran parte de lo que sostiene el informe.

El 9,6 % corresponde a un único escaneo, y Wiz afirma que su propio seguimiento de agosto no puede compararse con él.

La medición es sencilla y Wiz expone su método con claridad: 3.074 proxies LiteLLM accesibles desde internet encontrados mediante Shodan en febrero de 2026, cada uno de ellos probado para determinar si se autenticaría con la clave de ejemplo documentada. De ellos, 294 lo hicieron. Dentro de ese grupo, 191 no tenían ninguna clave maestra configurada y habrían aceptado cualquier cadena que se les ofreciera; el resto había dejado en su lugar el valor de marcador de posición de la guía de configuración. Ninguno de los dos modos de fallo requiere un error de software. Ambos necesitan únicamente la dirección de la puerta de enlace y el valor impreso en el propio README del proyecto.

También se trata del escaneo de un único proveedor. La cifra de Wiz ha sido repetida por la Iniciativa de Seguridad de IA de Cloud Security Alliance el 10 de septiembre y por The Hacker News ese mismo día, pero ambos la repiten con atribución, y no se localizó ninguna réplica independiente de la cifra de 3.074 para este artículo. Wiz realizó un segundo escaneo en agosto de 2026 y encontró más de 85.000 instancias, unas veintisiete veces el recuento de febrero. La empresa afirma que la mayoría de esas parecen ser honeypots o implementaciones de prueba, y que los dos recuentos no se pueden comparar. No existe una cifra de exposición actual, y cualquier artículo que cite una está citando la de febrero.

Una cifra más en el informe proviene de la propia telemetría de Wiz en lugar de un escaneo: la empresa afirma que LiteLLM está presente en aproximadamente un tercio de los entornos de nube que observa. Esa es la visión de un proveedor sobre su propia base de clientes y conviene tomarla con cautela, pero explica por qué los investigadores trataron una configuración incorrecta de la puerta de enlace como un problema de nube y no de aplicación.

La clave maestra es tanto la credencial de administrador como el interruptor que activa la autenticación

El diseño de LiteLLM le asigna dos funciones a un solo secreto. La clave maestra autentica las solicitudes administrativas, y es su presencia la que permite que exista autenticación siquiera: sin clave maestra y sin configuración de JWT u OAuth2, el proxy se ejecuta abierto y acepta todas las solicitudes. Wiz abordó el código con Claude Code de Anthropic, en busca de funciones que tomen entrada controlada por el usuario y la pasen a un contexto de ejecución, y el controlador de autenticación fue una de las tres superficies que señaló.

Antes de v1.82.0-stable, la consecuencia de esa segunda tarea era peor que un proxy abierto. Wiz descubrió que, cuando no se configuraba ninguna clave maestra, el controlador de autenticación asignaba el rol PROXY_ADMIN a todas las solicitudes entrantes, de modo que a un solicitante no autenticado no solo se le admitía, sino que se le admitía como administrador. La solicitud de incorporación de cambios #22095, citada en el informe, cambió el rol predeterminado a INTERNAL_USER y añadió una comprobación de administrador a los endpoints de guardarraíl.

El acceso administrativo a una puerta de enlace no es un privilegio limitado. La instancia guarda una clave de API para cada proveedor al que enruta, y eso es lo que la convierte en un objetivo para el LLMjacking: ejecutar cargas de trabajo de modelos a costa de la factura de la víctima. Ve los prompts y las completions. Se conecta hacia el exterior con servidores de herramientas MCP que, en una implementación interna, probablemente incluyan gestores de incidencias, chat, bases de datos y canalizaciones de despliegue.

Wiz también demostró una vía desde ese puesto administrativo hasta la identidad en la nube del host. LiteLLM permite a un administrador registrar una ruta de paso directo a cualquier URL de destino, y el destino no se comprueba contra rangos de direcciones privadas, localhost ni la dirección de metadatos de la nube. Apuntar una ruta al servicio de metadatos de la instancia devuelve las credenciales de IAM con las que se ejecuta la carga de trabajo. Cambiar el servicio de metadatos a IMDSv2, que normalmente neutraliza esta clase de falsificación de solicitudes al exigir un token de sesión obtenido por separado, no ayuda: LiteLLM reenvía cualquier encabezado con el prefijo x-pass- al destino con el prefijo eliminado, por lo que el encabezado del token puede colarse. Wiz dice que la función, podría decirse, funciona según lo previsto dentro de un modelo de amenazas que confía en los administradores, y que, por lo tanto, no tiene ningún CVE ni corrección.

Ese último párrafo es una demostración, no un ataque observado. The Hacker News, al informar sobre la investigación el 10 de septiembre, afirma que ninguna fuente informa de que alguien lo haya hecho contra una implementación real y que requiere primero acceso de administrador. El planteamiento de Wiz es el mismo: el pass-through es una propiedad de diseño que solo se convierte en vulnerabilidad cuando la credencial de administrador es una cadena de la documentación.

8.8 y 2.1 están puntuando la misma cadena desde posiciones de partida diferentes

Dos CVE contienen los hallazgos técnicos, y sus puntuaciones publicadas difícilmente podrían estar más distantes.

CVE-2026-59822 es la omisión de autenticación de MCP, y el aviso de LiteLLM lo clasifica como Alto, 8,8 según CVSS 4.0, sin privilegios requeridos, sin interacción del usuario y sin requisitos de ataque. El endpoint de MCP tiene su propio controlador de autenticación, creado para aceptar una clave de LiteLLM o un token OAuth2 destinado a un servidor de herramientas upstream. Cuando un token no superaba la validación de LiteLLM, el controlador capturaba el 401 y sustituía el objeto de autenticación por uno vacío en lugar de rechazar la solicitud. Por lo tanto, cualquier token Bearer producía una sesión MCP válida, incluido un solo carácter: la prueba de concepto de Wiz envía un token bearer de una sola letra y recibe de vuelta un identificador de sesión. La falla está corregida en 1.84.0.

CVE-2026-59821 es el fallo de guardrail, y el aviso del mismo proyecto lo califica como Bajo, 2.1, con privilegios altos requeridos y requisitos de ataque presentes. La función de guardrail de código personalizado permite a un administrador enviar Python que el servidor compila y ejecuta. El endpoint de prueba de la Web UI validaba el código contra una lista de patrones prohibidos y eliminaba los builtins antes de ejecutarlo; los endpoints de producción de creación y actualización no hacían ninguna de las dos cosas. Python vuelve a poblar los builtins cuando están ausentes, por lo que el código enviado llegó a la biblioteca estándar. La prueba de concepto de Wiz registra un guardrail que ejecuta un comando de shell en el momento del registro —antes de cualquier solicitud al modelo— y devuelve la salida del comando como motivo del bloqueo, que en su prueba volvió como root. El fallo está corregido en v1.82.0-stable.

Las dos descripciones son compatibles, y la frase que las concilia está en el propio aviso: LiteLLM señala que, en implementaciones sin una clave maestra configurada, los llamadores podrían tratarse como administradores del proxy, que es lo que puso los endpoints de salvaguarda al alcance. Un 2.1 asume un usuario privilegiado. La cadena de Wiz es lo que ocurre cuando la clave predeterminada hace que todos los llamadores sean privilegiados. Ninguna de las dos puntuaciones se equivoca respecto de su propia posición inicial; discrepan sobre con qué frecuencia esa posición está libre.

Una salvedad se aplica a la afirmación de Wiz de que, después de 1.82.0, un atacante que tuviera la clave predeterminada solo podría ejecutar código dentro de una sandbox. Hacker News señala un aviso separado de mayo de 2026, CVE-2026-40217, que describe cómo escapar de esa sandbox mediante técnicas de bytecode en versiones desde la 1.81.8 hasta, pero sin incluir, la 1.83.10, dentro de un proceso de proxy que, según el aviso, se ejecuta como root en la imagen de contenedor predeterminada. Alcanzar ese endpoint requiere una credencial de administrador de proxy, que es precisamente lo que es la clave maestra.

El 8.8 tampoco es universal. La nota de investigación de Cloud Security Alliance observa que el aviso de GitLab enumera una puntuación base de 8.2 para la misma vulnerabilidad y se abstiene de decidir entre las dos metodologías, señalando solo que ambas se sitúan en el rango alto. La severidad alta del registro no depende de qué número se utilice.

Se explotó una CVE en entornos reales; la exposición de la clave predeterminada no tiene ninguna víctima identificada.

CISA añadió CVE-2026-59822 al catálogo de Vulnerabilidades Explotadas Conocidas el 2 de septiembre de 2026 y fijó una fecha límite de remediación del 16 de septiembre de 2026 para las agencias civiles federales; la entrada del catálogo incluye CWE-287 y CWE-306, autenticación incorrecta y autenticación ausente. La nota de Cloud Security Alliance informa que los rastreadores de la industria lo han descrito como el primer fallo específico de MCP en esa lista. Wiz ha publicado la explotación que observó: desde el 7 de julio de 2026, sus honeypots registraron solicitudes que llevaban tokens bearer de un solo carácter sondeando endpoints de listado de modelos, y Wiz no describe ningún otro uso del fallo.

No existe nada comparable para la clave predeterminada. No se nombra a ninguna víctima, no se identifica ninguna puerta de enlace como tomada mediante sk-1234 y ninguna telemetría muestra que se estén utilizando los 294 hosts. La entrada del archivo no registra ningún daño real, lo cual es una afirmación sobre la evidencia y no sobre el mecanismo: la exposición se midió, no se presenció su uso.

Otros dos elementos suelen clasificarse junto con estos y no son lo mismo. CVE-2026-42271, ejecución de comandos a través de dos endpoints de prueba MCP, es la falla de LiteLLM que los atacantes han usado realmente para ejecutar código; los honeypots de Wiz registraron que instalaba un minero de criptomonedas. El caso de agosto de 2026 que publicó Microsoft, en el que un intruso leyó las variables de entorno de un contenedor de gateway, recuperó la clave maestra, las claves de los proveedores y una cadena de conexión a una base de datos, y luego copió registros de las tablas de modelos y de claves virtuales de LiteLLM, ilustra lo que vale un gateway comprometido, más que una nueva forma de entrada; The Hacker News informa que Microsoft evalúa el punto de entrada como la cadena CVE-2026-42271.

La postura de los mantenedores es que la falta de una clave maestra es un error de configuración, no una vulnerabilidad.

La política de seguridad de LiteLLM es explícita. Incluye entre los problemas fuera de alcance "ataques que requieren una configuración incorrecta durante la puesta en marcha (p. ej., no establecer una master_key en la configuración del proxy)", y afirma que estos quedan explícitamente fuera de alcance y no se consideran vulnerabilidades. Wiz llega a una conclusión compatible desde la dirección opuesta cuando califica el comportamiento de paso directo (pass-through) como, presumiblemente, el funcionamiento previsto.

Esa postura se ha puesto a prueba en público. El 15 de agosto de 2026, un investigador presentó el issue #37054 de GitHub, en el que informaba de que un proxy con LITELLM_MASTER_KEY sin definir autentica cualquier valor de clave y de que el archivo docker-compose distribuido no define ninguna. El issue se cerró 30 minutos después, y el único comentario que aparece en él es de la misma cuenta: cita la instrucción de la política de seguridad de que los informes se presenten mediante informes privados de vulnerabilidades en lugar de issues públicos, se disculpa por haberlo presentado públicamente y dice que el informe completo se estaba presentando por el canal de avisos de seguridad en su lugar. No aparece ninguna respuesta de los mantenedores en el hilo, por lo que el registro muestra que el reportero retiró el informe público, no una respuesta del proyecto a este. No hay registro público de qué fue del envío privado.

No se encontró para este artículo ninguna declaración pública de BerriAI que defendiera o revisara esa postura sobre el informe de septiembre. La respuesta visible de la empresa está en sus notas de la versión y sus archivos de configuración, más que en prosa.

La ejecución llegó el 3 de octubre, veinticuatro días después del informe.

Los dos fallos de código se corrigieron mucho antes del informe. La cronología de divulgación de Wiz registra la ejecución de código del mecanismo de salvaguarda notificada el 18 de febrero de 2026 y corregida el 25 de febrero en la v1.82.0, la omisión de MCP corregida el 25 de abril en la v1.84.0, la explotación observada el 7 de julio, los identificadores CVE publicados el 8 de julio y la inclusión en el catálogo el 2 de septiembre. Los artefactos de publicación llevan fechas posteriores a las de las correcciones: el índice de paquetes muestra la v1.82.0 el 1 de marzo de 2026 y la v1.84.0 el 14 de mayo, que marcan cuándo cada corrección pasó a estar instalable, en lugar de cuándo se incorporó. Dos registros de publicación propios fechan las mismas correcciones más tarde que esa cronología. La publicación v1.82.0-stable en GitHub lleva el 11 de marzo de 2026 y el paquete 1.82.0 en PyPI, el 1 de marzo; la v1.84.0 está fechada el 14 de mayo de 2026 en ambos. Nada de lo publicado explica la discrepancia, y no afecta al argumento, ya que cada una de esas fechas cae meses antes del informe de septiembre. Los dos avisos de GitHub añaden aún una tercera fecha: se publicaron el 30 de junio de 2026, tres semanas antes de los identificadores CVE que, según Wiz, salieron el 8 de julio.

Lo que ninguna de esas versiones corrigió era el valor predeterminado. Wiz informó que, a 9 de septiembre, la clave maestra seguía configurada como sk-1234 al instalar LiteLLM mediante Docker Compose o pip install, y The Hacker News confirmó que la guía de configuración seguía usando ese valor ese día. El cambio llegó con la v1.104.0, subida al Python Package Index el 3 de octubre de 2026, cuyas notas de la versión lo catalogan como un cambio incompatible: el proxy ahora se niega a arrancar con una clave maestra sin establecer, vacía o de conocimiento público, indicando el origen del valor incorrecto en el error de arranque e imprimiendo un comando que genera una clave segura. Una entrada complementaria registra un cambio para dejar de anunciar un valor de clave maestra débil de conocimiento público en las configuraciones y ejemplos distribuidos, y el archivo docker-compose de la rama principal del proyecto ya no establece ninguna clave.

Esa es la secuencia que vale la pena conservar. El código se parcheó en primavera. El valor que hizo insuficientes esos parches permaneció en las instrucciones de instalación hasta octubre, y solo entonces empezó el software a rechazarlo. Nada en ninguna de las dos correcciones exigía que la otra esperara.

Lo que no ha cambiado es la ruta de paso directo al servicio de metadatos de instancias. Sigue sin tener CVE ni corrección, porque el proyecto considera que los administradores son de confianza. Por lo tanto, la lista de remediaciones de Wiz es principalmente trabajo para el operador: una clave maestra fuerte y única, una revisión de las salvaguardas registradas seguida de un reinicio del proceso para borrar el código retenido en memoria, una auditoría de los endpoints de paso directo con salida de contenedores restringida y roles de IAM con privilegios mínimos. Ninguna de esas cuatro se consigue solo con una actualización.

Lo que el registro no establece

• No se localizó ninguna replicación independiente del escaneo de 3.074 hosts. El 9,6 % es una medición de Wiz, y toda otra mención de la cifra la repite de forma atributiva.

• No existe una cifra actual de exposición. El seguimiento de agosto encontró más de 85.000 instancias, que, según Wiz, son en su mayoría honeypots o implementaciones de prueba y no pueden compararse con el recuento de febrero.

• Ninguna víctima. Nada en el registro nombra una puerta de enlace, un operador o una cuenta en la nube comprometida mediante la clave predeterminada, y la explotación que Wiz documenta es la del bypass de MCP en lugar de la de sk-1234.

• No hay pruebas de que se utilizaran los 294 hosts. El escaneo comprobó si autenticarían, lo cual es una afirmación más débil que demostrar que alguien lo hizo.

• No hay una gravedad consensuada para el fallo de la salvaguarda. Wiz y los mantenedores describen el mismo comportamiento y lo califican de forma muy distinta, y la diferencia tiene que ver con los privilegios que cada uno supone que el atacante ya posee.

Wiz es también un proveedor de seguridad en la nube que vende detección para este tipo de exposición, y el informe cierra con una sección sobre cómo sus propios productos identifican implementaciones de LiteLLM, versiones vulnerables e instancias en la sombra. Eso es contexto para leer la sección de remediación, no una razón para descartar una medición cuyos detalles técnicos están corroborados por los propios avisos de los mantenedores.

La parte del registro que viaja más allá de LiteLLM es el espacio entre dos fechas. La vulnerabilidad se cerró en primavera. El valor predeterminado que hacía que la vulnerabilidad importara a un desconocido todavía se imprimía en las instrucciones de instalación en septiembre, y el software solo comenzó a rechazarlo en octubre. Los operadores que cambiaron la cadena nunca tuvieron que esperar nada de eso.