Vulnerabilidades del gateway de IA LiteLLM: clave por defecto, explotación en entornos reales y camino hacia las credenciales en la nube

LiteLLM, un popular gateway open source entre aplicaciones y proveedores de modelos de lenguaje, se ha situado en el centro de una serie de incidentes de seguridad. Según datos de Wiz Research, en febrero de 2026 casi uno de cada diez servidores LiteLLM expuestos en internet aceptaba sk-1234, un ejemplo de clave administrativa del manual oficial de instalación. Esta clave abre el acceso a todas las API keys de los proveedores de modelos almacenadas en el servidor y, en determinadas condiciones, también a credenciales IAM en la nube. CISA ya ha incluido una de las vulnerabilidades de LiteLLM en el catálogo de vulnerabilidades explotadas conocidas, y Microsoft y Wiz han registrado ataques reales con instalación de criptomineros y robo de secretos. Las organizaciones que utilicen LiteLLM deben cambiar de inmediato la clave maestra y actualizar a la versión 1.84.0 o superior.

Magnitud del problema con la clave por defecto

Según Wiz, en febrero de 2026 Shodan detectó 3 074 gateways LiteLLM accesibles públicamente. De ellos, 294 aceptaban la clave sk-1234. En 191 servidores la clave maestra ni siquiera estaba configurada: aceptaban cualquier solicitud con permisos de administrador. El resto utilizaba sin cambios el valor del manual de instalación. Un nuevo escaneo en agosto detectó más de 85 000 instancias, aunque Wiz señala que la mayoría probablemente son honeypots o sistemas de pruebas, por lo que no conviene comparar directamente estas cifras.

La clave maestra en LiteLLM cumple una doble función: actúa simultáneamente como credencial de administrador y como interruptor que activa la autenticación. Hasta la versión 1.82.0-stable, un gateway iniciado sin clave maestra otorgaba a cada solicitud entrante todos los privilegios de administrador. El administrador del gateway obtiene acceso a todas las API keys de los proveedores, ve todas las solicitudes y respuestas que pasan por el sistema y puede conectarse a herramientas internas mediante Model Context Protocol (MCP). Las claves de proveedores robadas permiten a un atacante ejecutar cargas de trabajo sobre modelos a costa de la víctima, un tipo de ataque conocido como LLMjacking.

Mapa de vulnerabilidades: cinco CVE y su interrelación

En torno a LiteLLM se ha formado todo un clúster de vulnerabilidades. Anteriormente ya hablamos de la inclusión de varias vulnerabilidades de LiteLLM en el catálogo CISA KEV. Veamos el panorama completo.

CVE-2026-59822 (CVSS 8.8, High): bypass de autenticación de MCP. Permite a un atacante no autenticado abrir una sesión MCP válida usando un token Bearer arbitrario, incluso de un solo carácter. Afecta a versiones anteriores a la 1.84.0. Según el aviso de seguridad de LiteLLM, se corrigió en la 1.84.0. CISA añadió esta vulnerabilidad al catálogo KEV el 2 de septiembre, con fecha límite para los organismos federales hasta el 16 de septiembre. De acuerdo con Wiz, observaron su explotación en sus honeypots a partir del 7 de julio: solicitudes con tokens de una sola letra sondeaban los endpoints de enumeración de modelos. Wiz precisa que esta vulnerabilidad «solo permite el acceso al servidor MCP» y que el daño real depende de las herramientas conectadas.

CVE-2026-42271 (CVSS 8.7, High): ejecución de comandos a través de endpoints de prueba de MCP. Según el aviso de seguridad de GitHub, afecta a versiones ≥1.74.2 y <1.83.7. Permite a un usuario autenticado con una API key válida del proxy ejecutar comandos a través de endpoints de prueba MCP stdio. Se corrigió en la 1.83.7. Esta vulnerabilidad se convirtió en el vector principal de los ataques reales.

CVE-2026-48710 (CVSS 6.5): bypass de la comprobación del encabezado Host en Starlette (≤1.0.0). Según el aviso de seguridad, encabezados Host manipulados provocan que request.url.path difiera de la ruta a la que se ha hecho el enrutamiento, evitando las comprobaciones de seguridad basadas en rutas. Se corrigió en Starlette 1.0.1. Horizon3.ai demostró que esta vulnerabilidad, combinada con CVE-2026-42271, permite ejecutar comandos sin autenticación.

CVE-2026-59821 (CVSS 2.1, Low según la valoración de LiteLLM CNA): bypass de las comprobaciones de seguridad del código en los endpoints de creación y actualización de guardrails definidos por el usuario. Afecta a versiones anteriores a la 1.82.0-stable. Según el aviso de seguridad, requiere una cuenta con privilegios, aunque las implementaciones sin clave maestra configurada trataban a quienes llamaban a estos endpoints como administradores. Wiz describe el mismo comportamiento como ejecución de código con privilegios de root dentro del contenedor del gateway: una discrepancia en la evaluación de la gravedad entre los investigadores y los mantenedores.

CVE-2026-40217 (CVSS 5.9, Moderate): escape de la sandbox en guardrails personalizados mediante técnicas de bytecode. Según el aviso de seguridad, afecta a versiones ≥1.81.8 y <1.83.10, aunque en la descripción del aviso se indica la versión 1.83.11 como la corrección, una contradicción interna. El proceso del proxy en la imagen Docker por defecto se ejecuta como root. Para su explotación son necesarias credenciales de administrador del proxy, es decir, la clave maestra.

Camino hacia las credenciales en la nube

Merece una atención especial un mecanismo que no tiene CVE asignado. Según Wiz, LiteLLM permite al administrador crear endpoints de paso (pass-through) que redirigen las solicitudes a URLs arbitrarias. No se comprueba si la URL de destino pertenece a rangos de direcciones privadas, a localhost o a direcciones de metadatos de la nube. El administrador puede apuntar una ruta al servicio de metadatos de la instancia y obtener credenciales IAM. El paso a IMDSv2 no bloquea este camino: LiteLLM documenta que los encabezados con el prefijo x-pass- se envían al servidor de destino sin el prefijo, lo que permite enviar los encabezados exigidos por IMDSv2. Wiz señala que esta función «funciona según lo diseñado», ya que el modelo de amenazas de LiteLLM considera de confianza a los administradores. No hay parche previsto para este comportamiento.

Ataques reales: del criptominería al robo de bases de datos

Las vulnerabilidades de LiteLLM se explotan activamente. Según Wiz, en sus honeypots han registrado la explotación de CVE-2026-42271 para instalar un criptominer. Microsoft publicó en agosto la descripción de un incidente en el que los atacantes ejecutaron comandos dentro del proceso del gateway LiteLLM, extrajeron del entorno del contenedor la clave maestra, las claves de proveedores y la cadena de conexión a la base de datos, y luego la utilizaron para acceder a PostgreSQL y copiar registros de las tablas de modelos y claves virtuales. Microsoft evalúa con un alto grado de confianza que el punto de entrada corresponde a la cadena CVE-2026-42271 y CVE-2026-48710. La compañía recomienda «tratar los gateways de IA como almacenes de secretos de nivel Tier-0».

Indicadores de compromiso

Según Wiz, en la campaña con el criptominer se utilizaron los siguientes indicadores:

• Direcciones IP: 185.62.1[.]8, 185.84.98[.]85, 94.26.106[.]29
• URL de descarga: http://185.62.1.8/mon/mon.zip
• Ruta de instalación del miner: /tmp/.dbus-cache/gmon
• Dominio del pool: pool.hashvault[.]pro

Priorización de la respuesta

Entre todos los problemas descritos, los que representan la amenaza más inmediata son CVE-2026-59822 y CVE-2026-42271: ambos tienen explotación confirmada y afectan a endpoints MCP accesibles desde internet. El camino a través de pass-through hacia los metadatos de la nube requiere haber obtenido previamente acceso administrativo y constituye un vector de post-explotación, no un punto de entrada independiente.

Recomendaciones

1. Cambie de inmediato la clave maestra de sk-1234 a un valor largo y aleatorio. Esto no requiere actualizar la versión. Antes de cambiarla, compruebe si se ha configurado una clave de sal independiente: el procedimiento de rotación difiere y un error puede hacer que las credenciales almacenadas dejen de ser legibles.
2. Actualice a la versión 1.84.0 o superior. Esta versión está por encima del umbral de corrección de todas las vulnerabilidades de LiteLLM enumeradas, incluida CVE-2026-40217, para la que el aviso presenta una inconsistencia interna entre la 1.83.10 y la 1.83.11.
3. Si no es posible actualizar de inmediato, bloquee a nivel de reverse proxy o API gateway: /mcp/, POST /mcp-rest/test/connection, POST /mcp-rest/test/tools/list, POST /guardrails/test_custom_code. Limite POST /guardrails y PUT /guardrails/{guardrail_id} solo a administradores.
4. Limite el acceso de red saliente del contenedor y asigne a la carga de trabajo el rol IAM mínimo necesario en la nube: es la única protección frente a la ruta hacia los metadatos de la instancia mediante pass-through.
5. Si sospecha de una posible compromisión: revise la lista de guardrails en busca de entradas ajenas, reinicie el proceso para limpiar el código en memoria y, a continuación, rote las claves de proveedores, la clave maestra y las credenciales de la base de datos. La actualización de versión no elimina ni los guardrails registrados por el atacante ni las claves SSH añadidas.

Un gateway LiteLLM accesible desde internet con la clave por defecto sk-1234 es, de hecho, un almacén de secretos expuesto. Cambiar la clave maestra es una acción que lleva un minuto y cierra la mayoría de los vectores de ataque descritos sin necesidad de actualizar la versión. La actualización a la 1.84.0 cierra el resto. Las organizaciones que detecten en su entorno LiteLLM con la configuración por defecto deben partir de la hipótesis de una posible compromisión y proceder a la rotación de todos los secretos relacionados.