Casi uno de cada diez gateways LiteLLM expuestos aceptaba la clave de ejemplo sk-1234

Wiz Research escaneó en febrero las pasarelas LiteLLM accesibles desde internet y encontró que casi una de cada diez aceptaba sk-1234, la clave de administración de ejemplo que aparece en la propia guía de instalación del proyecto. Son 294 de las 3.074 instancias que localizó en Shodan. Esa credencial da acceso a todas las claves de API de proveedores de modelos guardadas en el servidor, y sustituirla no exige actualizar nada.

De dónde sale el número

Fue un solo escaneo. En 191 de esas 294 no había ninguna clave configurada, así que habrían aceptado cualquier cosa; el resto conservaba el valor del manual. Un segundo escaneo en agosto encontró más de 85.000 instancias, pero Wiz dice que la mayoría parecen señuelos o sistemas de prueba y que las dos cifras no se pueden comparar. No hay dato actual: a 9 de septiembre, la guía del proyecto seguía usando sk-1234, justo debajo de un comentario que pide cambiarla por un valor aleatorio largo antes de usarla de verdad.

Por qué una clave importa tanto

La clave maestra hace dos trabajos a la vez: es la credencial del administrador y el interruptor que activa la autenticación. Antes de la versión 1.82.0-stable, una pasarela que arrancaba sin clave maestra concedía permisos de administrador a cualquier petición entrante. Y ahí hay mucho en juego: las claves de todos los proveedores a los que enruta, todas las consultas y respuestas que la atraviesan, herramientas internas vía MCP y, casi siempre, los permisos cloud de la carga de trabajo donde corre. Con las claves robadas, un atacante ejecuta cargas de modelos a cuenta de la víctima, lo que se conoce como LLMjacking.

El salto a la cuenta cloud va por un endpoint que reenvía peticiones a cualquier URL que elija el administrador, sin comprobar si apunta a rangos privados, a localhost o a direcciones de metadatos. Basta con dirigirlo al servicio de metadatos de la instancia para leer de vuelta las credenciales IAM. Pasar a IMDSv2 no lo impide: LiteLLM documenta que cualquier cabecera con prefijo x-pass- se reenvía al destino sin el prefijo, y Wiz usó eso para mandar las cabeceras que IMDSv2 exige. Nadie ha reportado que se haya hecho contra un despliegue real: es una demostración y hace falta ser administrador primero. No tiene CVE ni parche, y la política de seguridad del proyecto considera los ataques que dependen de no poner clave maestra «explícitamente fuera de alcance».

El fallo de guardrails y una severidad discutida

El único fallo de ejecución de código del informe es CVE-2026-59821, y cada parte lo cuenta a su manera. Wiz habla de ejecución post-autenticación como root y muestra un uid=0(root) dentro del contenedor. El aviso de LiteLLM lo puntúa como Baja, 2,1 en la escala CVSS. El comportamiento es el mismo: antes de la 1.82.0-stable, los endpoints que crean y actualizan guardrails de código se saltaban el sandbox y las comprobaciones de patrones que sí aplicaba el endpoint de prueba. Los dos fallos que reportó Wiz se corrigieron en febrero y abril, meses antes de su informe del 9 de septiembre, aunque sus CVE no se publicaron hasta julio.

Más antiguos y sin relación con la vía hacia la nube: CVE-2026-59822 (CVSS 8,8) deja que un atacante sin autenticar abra una sesión MCP válida con cualquier token Bearer, incluso de un solo carácter. CISA lo añadió a su catálogo de vulnerabilidades ya explotadas el 2 de septiembre, y las agencias civiles federales estadounidenses tienen hasta el 16 para resolverlo. CVE-2026-42271 (CVSS 8,7) permitía a cualquier usuario autenticado ejecutar comandos en el host a través de dos endpoints de prueba de MCP, y Horizon3.ai lo encadenó en junio con un fallo de host-header de Starlette para lograrlo sin credenciales. Los señuelos de Wiz registraron su uso para instalar un minero de criptomonedas.

La corrección más rentable no es un parche: cambiar la clave maestra cierra todos los caminos del informe que dependen de tenerla y no requiere tocar la versión instalada. Lo demás sigue en manos del proyecto, que mantiene al administrador como figura de confianza y deja el endpoint de reenvío sin filtrar a dónde apunta.