LiteLLM 1.107.0 comprometido: cómo saber si te afecta y qué hacer

La versión 1.107.0 de LiteLLM se publicó en PyPI y Docker con un ladrón de credenciales. Qué pasó, cómo saber si te afecta y qué hacer ahora mismo.

El 21 de octubre de 2026 se publicó una versión maliciosa de LiteLLM, la librería y proxy de Python que permite usar más de cien modelos de IA con una sola API y que forma parte de nuestro stack. La versión 1.107.0 llevaba dentro un programa que roba credenciales y una puerta trasera para ejecutar código remoto.

En resumen: si el 21 de octubre instalaste litellm 1.107.0 o arrancaste una imagen Docker de LiteLLM con las etiquetas v1.107.0, latest, main-latest o main-stable, trata ese entorno como comprometido. No empieces con pip install: limpia, reconstruye desde cero con la versión 1.106.2 y rota todos los secretos a los que tenía acceso.

Qué ha pasado

Según el informe oficial de LiteLLM, alguien comprometió su cadena de publicación de versiones y publicó la 1.107.0 en PyPI y en sus registros de Docker. El código de la etiqueta v1.107.0 en GitHub está limpio: los paquetes maliciosos se construyeron desde un repositorio controlado por el atacante con un nombre casi idéntico, Berri-AI/litellm en lugar del oficial BerriAI/litellm.

El problema lo detectó el equipo de investigación de seguridad de Upwind, que lo reportó en un issue público del repositorio. Los paquetes se retiraron en unas dos horas, pero durante ese tiempo cualquier instalación sin versión fijada pudo descargarlos.

¿Un intento o un ataque consumado?

Fue un ataque consumado, no solo un intento. La versión maliciosa estuvo publicada y disponible para descarga:

PyPI: los siete paquetes (wheels) de litellm 1.107.0, para macOS, Linux y Windows, entre las 11:39 y las 13:23 UTC.
Docker Hub: las etiquetas v1.107.0, latest, main-latest y main-stable, entre las 11:46 y las 14:20 UTC.
GHCR: las mismas etiquetas de las imágenes litellm, litellm-database y litellm-non_root, hasta las 13:51 UTC.

Lo que no se sabe es cuántos entornos llegaron a instalarla. LiteLLM tiene unos 23 millones de descargas semanales, así que incluso dos horas son suficientes para un alcance amplio. Las versiones anteriores son seguras, y los clientes Enterprise que usan el registro privado de LiteLLM no se vieron afectados.

Qué hace el código malicioso

El paquete añade tres ficheros (cook.pth, cook.py y sitecustomize.py) que Python ejecuta automáticamente cada vez que arranca en ese entorno, aunque tu aplicación ni siquiera importe litellm. Eso incluye ejecutar pip.

Roba credenciales. Recoge claves SSH, credenciales de AWS, Azure, GCP, Kubernetes, Docker y GitHub, ficheros .env, certificados y claves privadas, contraseñas guardadas en el navegador, configuraciones de herramientas de IA y las variables de entorno de todos los procesos que puede leer.
Vacía la base de datos del proxy. Si encuentra DATABASE_URL, extrae las tablas donde LiteLLM guarda las claves de todos los proveedores de IA configurados.
Roba la identidad de la máquina en la nube. Pide credenciales temporales a los servicios de metadatos de AWS, GCP y Azure, y comprueba que funcionan antes de enviarlas.
Deja una puerta trasera. En Linux y macOS lanza un proceso en segundo plano que cada hora consulta un fichero en GitHub y, si contiene un dominio, descarga y ejecuta código desde él. Según Upwind, ese fichero está vacío por ahora, pero el atacante puede reactivarlo cuando quiera.

Los datos robados se cifran y se envían a litellm.dev, un dominio registrado por el atacante el 13 de octubre. El dominio oficial del proyecto es litellm.ai.

Cómo consiguieron entrar

LiteLLM explica que, tras un incidente anterior en marzo, había reforzado su proceso de publicación, y que el atacante tuvo que saltarse varios controles independientes. Según su investigación, todavía en curso:

Un despliegue interno de LiteLLM de la propia empresa estaba expuesto a Internet, y el atacante creó en él una cuenta de usuario. Sospechan que entró por una vulnerabilidad parcheada recientemente.
En los logs de ese despliegue había tokens OAuth de GitHub CLI de tres ingenieros. LiteLLM afirma haber observado casos concretos en los que Claude Code incluía ese token en el cuerpo de una respuesta, que después quedaba registrado en los logs del proxy.
Uno de esos tokens pertenecía a un propietario de la organización en GitHub. Con él, el atacante desactivó las protecciones de rama, modificó el flujo de publicación para que construyera desde el repositorio falso y después borró los registros de ejecución.

La lección va más allá de LiteLLM: un gateway de IA que registra el contenido completo de peticiones y respuestas puede acabar guardando secretos en sus logs.

Cronología del 21 de octubre (hora UTC)

10:08: GitHub rechaza un cambio no autorizado en el flujo de publicación; segundos después, una cuenta privilegiada fuerza el cambio.
11:39: se suben a PyPI los siete paquetes maliciosos de la 1.107.0.
11:46: se publican las imágenes Docker con el mismo código malicioso.
11:53: una tercera cuenta borra los registros de las ejecuciones, lo que limita la investigación.
11:55: el escáner de malware de Chainguard detecta el paquete, 16 minutos después de su publicación.
13:23: PyPI retira la versión 1.107.0.
13:51 y 14:20: se retiran las etiquetas afectadas en GHCR y en Docker Hub, respectivamente.

¿Me afecta?

Te afecta si el 21 de octubre ocurrió cualquiera de estas cosas:

Instalaste o actualizaste litellm sin fijar versión entre las 11:39 y las 13:23 UTC (por ejemplo, un build de CI, un pip install -U o una imagen reconstruida).
Arrancaste o descargaste una imagen de LiteLLM con las etiquetas v1.107.0, latest, main-latest o main-stable entre las 11:46 y las 14:20 UTC.

Si usas litellm como dependencia de otra herramienta, comprueba también qué versión resolvió su instalación. Para revisarlo sin arrancar Python (recuerda que pip también es Python y activaría el código malicioso), puedes buscar los ficheros desde la shell:

# Paquete 1.107.0 instalado en algún entorno
find / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null

# Ficheros del malware en site-packages
find / \( -name "cook.pth" -o -name "cook.py" -o -name "sitecustomize.py" \) -path "*site-packages*" 2>/dev/null

# Marcadores en el sistema
ls -la /tmp/.pc_once_* /tmp/remote_code_loader.lock 2>/dev/null

# Imágenes Docker de LiteLLM descargadas (compara el digest con el aviso oficial)
docker images --digests | grep -i litellm

Encontrar cualquiera de estos ficheros confirma la exposición. No encontrarlos no demuestra que el entorno esté limpio: los contenedores y la limpieza de /tmp pueden haberlos borrado. Si sabes que la 1.107.0 llegó a ejecutarse, da el entorno por comprometido.

Qué hacer ahora mismo

Si la versión maliciosa se ejecutó en tu entorno, sigue estos pasos, basados en las recomendaciones de LiteLLM y de Upwind:

No ejecutes Python ni pip en ese entorno. Cada arranque vuelve a ejecutar el código malicioso.
Borra los ficheros desde la shell: cook.pth, cook.py y sitecustomize.py, junto con sus versiones compiladas en __pycache__, en todos los site-packages afectados.
Mata el proceso en segundo plano que mantiene el fichero /tmp/remote_code_loader.lock.
Reconstruye desde cero los entornos virtuales y las imágenes con litellm==1.106.2 fijado. Es mejor que reinstalar encima.
Da por robado todo lo que la máquina podía leer si tenía salida a Internet, y rótalo: el rol IAM de la instancia o tarea, todas las claves de proveedores de IA guardadas en el proxy, la master key y las virtual keys de LiteLLM, la contraseña de DATABASE_URL y cualquier secreto en las variables de entorno de la máquina.
Revisa CloudTrail en busca de llamadas GetCallerIdentity del rol de la instancia alrededor de la hora de instalación, y de uso de esas credenciales desde fuera de tu infraestructura. Haz lo equivalente en GCP o Azure.
Bloquea los indicadores del ataque en tu firewall o proxy de salida, empezando por el dominio litellm.dev, y busca conexiones previas a él en tus logs de red.

Aunque no te haya afectado, fija la versión de litellm en tus dependencias y deja de usar las etiquetas latest, main-latest y main-stable en producción.

Qué tener en cuenta para lo que viene

Es la segunda vez en siete meses. En marzo de 2026 ya se publicaron versiones maliciosas de LiteLLM (1.82.7 y 1.82.8) tras el robo de la cuenta de PyPI de un mantenedor. Trata la próxima versión con cautela hasta que LiteLLM cierre su investigación.

Hay una vulnerabilidad pendiente para el 27 de octubre. LiteLLM menciona en su informe una vulnerabilidad cuya divulgación está prevista para esa fecha y que ya ha corregido en su versión Enterprise. Está atento para actualizar en cuanto se publique la corrección abierta.

Esta semana no viene sola. En los mismos días hemos visto PHP2Shell y el incidente de Railway. Los atacantes apuntan a las herramientas donde se concentran las claves de IA y de nube.

Prácticas que reducen el riesgo frente a ataques a la cadena de suministro:

Fija versiones y verifica hashes. Usa lockfiles con hashes (por ejemplo, pip install --require-hashes, uv o Poetry) y fija las imágenes Docker por digest, no por etiqueta.
No adoptes versiones el mismo día. Esperar unos días antes de actualizar dependencias críticas, salvo parches de seguridad, habría evitado este ataque por completo.
Usa un registro intermedio con escaneo. Un mirror de paquetes con detección de malware puede bloquear una versión maliciosa en minutos, como ocurrió con Chainguard.
Restringe la salida a Internet de los contenedores del proxy a los proveedores de IA que realmente usas. Sin salida libre, el robo de datos falla.
Cuida lo que registras. Evita guardar cuerpos completos de peticiones y respuestas en los logs del gateway, o filtra los secretos antes de guardarlos. Y no expongas paneles internos a Internet.
Tokens de desarrollo con mínimo privilegio. Los tokens de GitHub de los desarrolladores no deberían poder desactivar protecciones de rama ni publicar versiones. Separa esos permisos y protégelos con aprobaciones.

¿Necesitas ayuda? En Experimentality Labs te acompañamos

Si usas LiteLLM u otras herramientas de IA en tu stack y no tienes claro si te ha afectado, en Experimentality Labs podemos ayudarte a revisar tus entornos, limpiar y reconstruir lo que haga falta, rotar las credenciales de forma ordenada y endurecer tu cadena de dependencias para la próxima vez. Escríbenos y lo revisamos contigo.

LiteLLM 1.107.0 comprometido: qué ha pasado y qué hacer si lo usas