LiteLLM 1.107.0 comprometida: infostealer y RAT en PyPI y Docker

El 21 de octubre de 2026 el pipeline de publicación de LiteLLM, el gateway de código abierto de BerriAI que ofrece una interfaz única hacia OpenAI, Anthropic, Google Gemini y otros proveedores de modelos, publicó una versión maliciosa: la 1.107.0, en PyPI, Docker Hub y GHCR. Contenía un infostealer dirigido a credenciales de la nube, de desarrollo y de servicios de IA, además de un troyano de acceso remoto (RAT). Es el segundo ataque a la cadena de suministro del proyecto este año, tras el de marzo vinculado al escáner Trivy usado en su CI/CD.

Qué ha pasado

Según el informe de LiteLLM, el atacante usó los tokens OAuth de la GitHub CLI de tres desarrolladores: una cuenta modificó el pipeline e inició la publicación, una segunda la aprobó y una tercera borró los registros del workflow. Según SecurityWeek, también desactivó las protecciones de las ramas e hizo que la publicación apuntara al repositorio Berri-AI/litellm, a un guion del legítimo BerriAI/litellm. El workflow firmó y publicó después los artefactos envenenados: las imágenes firmadas introducidas tras marzo no bastaron.

La empresa cree que los tokens se sacaron de los registros de una instalación interna de LiteLLM expuesta en internet, en la que apareció una cuenta de usuario inesperada con un nombre inocuo. Ha observado casos concretos en los que Claude Code incluye el token de la GitHub CLI en el cuerpo de una respuesta: si se registran los cuerpos de las respuestas, el token acaba en los registros. Cómo entró el atacante no está confirmado; LiteLLM sospecha de una vulnerabilidad corregida hace poco. Un artículo de The Hacker News del 24 de octubre señala en su titular una master key de LiteLLM filtrada: no hemos podido leer su texto.

Ventanas de exposición del informe, recogidas por BleepingComputer:

• PyPI: litellm==1.107.0, las siete wheels para Windows, Linux y macOS, de 11:39 a 13:23 UTC;
• Docker Hub: etiquetas v1.107.0, latest, main-latest y main-stable de 11:46 a 14:20 UTC, hacia el índice sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e;
• GHCR: las mismas etiquetas hasta las 13:51 UTC, también para las variantes litellm-database y litellm-non_root.

SecurityWeek, la única de las fuentes que lo hace, calcula más de 49.000 descargas. La última versión limpia es la 1.106.2; los clientes del registro privado enterprise no están afectados.

Detalles técnicos

El código de la aplicación no se tocó: el paquete añadía tres archivos en la raíz de site-packages.

• cook.pth: las líneas ejecutables de los archivos .pth se procesan cada vez que arranca el intérprete, y esta lanza cook.py, el infostealer;
• sitecustomize.py: también se importa al arrancar y lanza un cargador separado que cada hora lee un puntero alojado en GitHub (dead drop), y luego descarga y ejecuta código Python.

Por tanto, el malware se ejecuta cada vez que arranca Python en el entorno, aunque la aplicación no use LiteLLM, e incluso al lanzar python o pip para investigar.

Según Wiz el infostealer tiene 16 módulos. Recoge credenciales de AWS (~/.aws/, variables de entorno, metadatos de EC2/ECS), Google Cloud, Azure, Kubernetes y Docker; secretos de Git, GitHub, npm, PyPI y CI/CD, archivos .env, claves SSH y GPG, historial de la shell; claves API de OpenAI, Anthropic y otros proveedores, archivos de autenticación de Codex, Claude, Gemini y Cursor; contraseñas, cookies e historial de los navegadores. También busca las credenciales de los proveedores guardadas en la base de datos del proxy LiteLLM: según los investigadores, eso muestra la intención, no un éxito demostrado. Los datos, cifrados con AES-256-CBC y con la clave protegida por RSA-4096, salen mediante un POST HTTP hacia www.litellm[.]dev/healthcheck.

Indicadores públicos: según Aikido, /tmp/.pc_once_* (la exfiltración se ha producido) y /tmp/remote_code_loader.lock (el cargador se ha ejecutado o está activo); además, el dominio litellm[.]dev, el repositorio Berri-AI/litellm y el digest de la imagen indicado antes.

Uso de las credenciales: Wiz vio al atacante, unas cuatro horas y media después de la exfiltración, validar claves de AWS tomadas de runners de CI y nodos de Kubernetes y probar el acceso a los modelos de Amazon Bedrock (LLMjacking); en unos pocos entornos enumeró después roles, usuarios y claves de IAM.

En nuestra lectura, las técnicas MITRE ATT&CK pertinentes son T1195.002 (Compromise Software Supply Chain), T1546.018 (Python Startup Hooks), T1552 (Unsecured Credentials) y T1102.001 (Dead Drop Resolver).

Impacto para las empresas europeas e italianas

Un gateway de IA concentra las claves de varios proveedores y a menudo funciona con identidades en la nube y acceso a bases de datos: el daño puede ir mucho más allá de las claves API. También están expuestos los equipos de desarrollo y los runners de CI que instalaron la biblioteca como dependencia. Dos lecciones generales: una firma válida dice que el artefacto no ha cambiado desde la firma, no que fuera seguro; y los registros de un gateway de IA pueden recoger secretos.

Para las entidades NIS2 la seguridad de la cadena de suministro es una medida obligatoria: la ejecución de la 1.107.0 en sistemas con acceso a la infraestructura debe valorarse como posible incidente notificable, según los accesos obtenidos. Si la base de datos del proxy guardaba registros con datos personales, hay que valorar también la notificación prevista por el RGPD.

Qué hacer ya

1. Localiza entornos, equipos y runners con la 1.107.0 y las imágenes descargadas en la ventana con las etiquetas latest, main-latest o main-stable: lockfiles, registros de paquetes, digests.
2. No arranques Python ni pip en los sistemas sospechosos: busca desde fuera cook.pth, cook.py, sitecustomize.py y los archivos de /tmp, y en los registros de red el dominio litellm[.]dev. Que no haya indicadores no prueba que el entorno esté limpio.
3. Aísla y reconstruye desde imágenes de confianza, conservando las pruebas: quitar solo el paquete puede dejar activos los archivos de arranque y el cargador. Fija la 1.106.2 por hash o digest, no por etiqueta.
4. Rota todos los secretos accesibles: nube, proveedores de IA (también los guardados en el proxy), Kubernetes, CI/CD, Git y registros, claves SSH; cierra las sesiones de los navegadores de los equipos afectados.
5. Busca el uso de las credenciales desde el 21 de octubre: llamadas a Bedrock, enumeración de IAM, claves nuevas, consumos anómalos de tokens de los modelos.
6. Refuerza el pipeline: aprobación independiente de los cambios en los workflows de publicación, nada de cuerpos de respuesta en los registros del gateway, interfaces de gestión no expuestas en internet.

Cómo ayuda ARXDOME

ARX Sentry recoge con su agente el inventario de software y procesos de ordenadores y servidores Windows, Linux y macOS, y controla la integridad de los archivos en las carpetas establecidas: te ayuda a encontrar las máquinas en las que funciona LiteLLM y a detectar archivos nuevos donde no deberían estar. Si una máquina es sospechosa, ARX Shield te permite aislarla de la red hasta su reconstrucción.

Última actualización: 24 de octubre de 2026