Atacantes están explotando activamente una vulnerabilidad de autorización (CVE-2026-35029) en el gateway de IA LiteLLM. Este fallo, presente en versiones anteriores a la 1.83.0, permite que usuarios con privilegios bajos accedan al endpoint /config/update, otorgándoles un control administrativo total sobre el sistema y permitiéndoles robar secretos.

Los atacantes están sondeando activamente los despliegues de la puerta de enlace de IA LiteLLM en busca de un fallo de autorización conocido que puede convertir una cuenta de bajos privilegios en un control administrativo total.

El problema, registrado como CVE-2026-35029, afecta a las versiones de LiteLLM anteriores a la 1.83.0 y permite que los usuarios autenticados accedan al sensible punto final /config/update sin el rol de administrador requerido.

LiteLLM actúa como una puerta de enlace de IA entre las aplicaciones empresariales y los proveedores de modelos. Puede almacenar claves API de proveedores, detalles de conexión a bases de datos, datos de usuario, registros de gastos y credenciales administrativas.

Esto convierte a los planos de control de LiteLLM expuestos en un objetivo valioso para los atacantes que buscan credenciales de la nube, claves de servicios de IA o una vía de entrada a la infraestructura conectada. La vulnerabilidad surge de la ausencia de una comprobación de autorización en la ruta de la API /config/update.

Eplotan el fallo de la API de administración de LiteLLM

En las versiones afectadas, una cuenta autenticada con un rol limitado, como el rol de solo lectura proxy_admin_viewer, podría modificar ajustes reservados para administradores totales. LiteLLM corrigió el problema en la versión 1.83.0 exigiendo el rol proxy_admin para los cambios de configuración.

Los investigadores observaron que los atacantes abusaban del fallo para modificar variables de entorno y valores de configuración. Una técnica consiste en cambiar UI_LOGO_PATH, un ajuste que identifica el archivo del logotipo del panel de control.

Al sustituir la ruta de imagen normal por un archivo sensible del lado del servidor, como /app/.env o /proc/self/environ, un atacante puede hacer que LiteLLM lo lea.

El contenido puede recuperarse posteriormente a través del punto final /get_image, que según se informa no requiere autenticación en los despliegues vulnerables.

Esta técnica puede exponer secretos almacenados en archivos de entorno y archivos de configuración. Los datos potencialmente expuestos incluyen claves API de proveedores de modelos, la clave maestra de LiteLLM, URLs de bases de datos, credenciales de AWS y tokens de plataformas de observabilidad.

El fallo también puede utilizarse para sobrescribir las variables de entorno UI_USERNAME y UI_PASSWORD, lo que permite a un atacante reemplazar las credenciales del panel de control y tomar el control de la interfaz de administración.

El impacto en la seguridad puede ir más allá del robo de datos. Los avisos indican que los atacantes pueden registrar controladores de puntos finales de paso maliciosos mediante una configuración alterada.

Dichos controladores pueden apuntar a código o infraestructura controlada por el atacante, creando una ruta para la ejecución remota de código o la exfiltración de secretos.

La telemetría del honeypot de Zenity registró aproximadamente 3.900 solicitudes contra los puntos finales de la API administrativa de LiteLLM entre febrero y junio de 2026, incluyendo unas 1.000 solicitudes dirigidas a /config/update.

Los primeros sondeos de actualización de configuración aparecieron el 7 de abril, un día después de que se revelara públicamente el CVE-2026-35029. Posteriormente, los investigadores vieron cargas útiles de lectura directa de archivos que intentaban cargar ubicaciones comunes de secretos, incluyendo /app/.env, /home/litellm/.env, /app/config.yaml y /app/proxy_server_config.yaml.

La actividad también incluyó intentos de adivinar claves maestras como sk-1234 y sk-litellm-master-key, generar nuevas claves API, crear cuentas de administrador, enumerar usuarios y claves, sondear rutas de aprovisionamiento SCIM y eliminar modelos.

Estas acciones demuestran que los actores de amenazas no están simplemente escaneando en busca del CVE, sino que están mapeando e intentando controlar entornos de puertas de enlace de IA expuestos.

Si tu organización utiliza LiteLLM, debes actualizar inmediatamente a la versión 1.83.0 o posterior. Esta versión añade la aplicación de autorización que faltaba para /config/update.

También debes eliminar la exposición de los servicios del plano de control de LiteLLM a la internet pública, colocar la interfaz de administración y los puntos finales administrativos detrás de un proxy inverso autenticado o una red interna, y asegurarte de que esté configurada una clave maestra fuerte y única. Nunca debes utilizar valores predeterminados o ejemplos de la documentación.

Tu equipo de seguridad debe revisar los registros en busca de solicitudes sospechosas a /config/update, /get_image, /key/generate, /user/new, /model/delete y /scim/. Las solicitudes que establezcan UI_LOGO_PATH en rutas de archivos locales deben tratarse como probables intentos de explotación.

Por último, si operaste una versión expuesta de LiteLLM antes de la 1.83.0, debes rotar todos los secretos potencialmente expuestos. Esto incluye las claves maestras de LiteLLM, las claves API de proveedores de LLM, las contraseñas de bases de datos, las credenciales de la nube y los tokens de monitoreo de terceros, ya que la vulnerabilidad puede exponer estos valores mediante la manipulación de la configuración y la lectura arbitraria de archivos.