LiteLLM 1.107.0 salió con un ladrón de credenciales escondido y el ataque de cadena de suministro duró unas dos horas en público. LiteLLM, la biblioteca de Python que miles de equipos usan como puerta única hacia decenas de proveedores de modelos de lenguaje, publicó el 21 de octubre su aviso de incidente: su canal oficial de lanzamiento fue comprometido y la versión 1.107.0 llegó a PyPI y a los registros de Docker con programas maliciosos compilados que roban credenciales y cargan herramientas de ejecución remota de código.
La ventana fue corta y el alcance, enorme. Datadog Security Labs cifró en unas 23 millones de descargas semanales el uso de esta biblioteca. Quien instaló esa versión sin fijar otra, o arrancó la imagen oficial de Docker en las horas del ataque, debe tratar su equipo como comprometido. La propia compañía lo pide así, sin rodeos, en su aviso.
LiteLLM 1.107.0 y el ataque de cadena de suministro, hora por hora
El paquete malicioso estuvo vivo en PyPI desde las 11:39 hasta las 13:23 UTC del 21 de octubre, con sus siete archivos de instalación. Las imágenes de Docker con las etiquetas v1.107.0, latest, main-latest y main-stable sirvieron la versión alterada de 11:46 a 14:20 UTC. LiteLLM confirmó que todas las versiones anteriores son seguras, que los artefactos afectados fueron retirados y que los clientes empresariales que usan su registro privado no sufrieron el golpe.
El truco técnico explica la gravedad. La versión alterada deja tres archivos en la carpeta de paquetes del entorno de Python: cook.pth, cook.py y sitecustomize.py. Python ejecuta los archivos de extensión .pth y el archivo sitecustomize.py de forma automática cada vez que el intérprete arranca, aunque la aplicación nunca importe LiteLLM. Borrar la carpeta del paquete no elimina esos tres archivos, y abrir la terminal para desinstalar con pip también los vuelve a disparar. Datadog Security Labs detalló que el ladrón reúne credenciales de nube, llaves SSH, tokens de Git y de PyPI, archivos .env, contraseñas del navegador y las claves de proveedores que el propio LiteLLM guarda en su base de datos.
El segundo componente abre una puerta trasera: sitecustomize.py revisa cada hora un archivo en un repositorio de GitHub para obtener un dominio y descargar código desde ahí. Datadog anotó un matiz que baja un grado la alarma: ese archivo remoto solo contenía valores de prueba y ninguna segunda carga fue observada en uso real.
El repositorio gemelo de LiteLLM 1.107.0: un guion de diferencia
La entrada no fue por la puerta del código fuente. LiteLLM explicó que el atacante actuó con credenciales de la interfaz de línea de comandos de GitHub robadas a tres ingenieros. Una de esas credenciales pertenecía a un propietario de la organización y sirvió para desactivar las protecciones de rama y forzar el cambio que apuntó el flujo de lanzamiento a un repositorio controlado por el atacante: Berri-AI/litellm, con un guion, en lugar del legítimo BerriAI/litellm. La etiqueta oficial de la versión 1.107.0 en GitHub no contiene los archivos maliciosos; los artefactos envenenados se construyeron desde ese repositorio gemelo y salieron firmados por el canal de siempre.
El origen de los tokens robados apunta a una ironía difícil de tragar. La compañía observó que Claude Code puede incrustar el token de GitHub del usuario en el cuerpo de una respuesta, y esos cuerpos quedan en los registros de una instalación interna de LiteLLM expuesta a internet, donde apareció una cuenta que nadie reconoció. LiteLLM cree que el atacante sacó los tokens de esos registros y borró después los registros del flujo con la tercera credencial. La investigación sigue abierta y ese tramo inicial no está confirmado por completo.
Qué hacer si instalaste LiteLLM 1.107.0: limpieza antes que prisa
La recomendación oficial ordena las prioridades al revés de lo habitual. Nada de empezar con pip install: cualquier arranque de Python en el entorno afectado ejecuta otra vez los archivos maliciosos. Primero se borran a mano cook.pth, cook.py y sitecustomize.py, con sus copias compiladas, de cada carpeta de paquetes del sistema. Después se detiene el proceso en segundo plano que mantiene ocupado el archivo /tmp/remote_code_loader.lock. Recién entonces toca reinstalar fijando la versión 1.106.2, y la propia guía prefiere reconstruir desde cero los entornos virtuales y las imágenes de contenedor.
La rotación de credenciales no es opcional. Si el equipo afectado tenía salida a internet, LiteLLM pide asumir que la exfiltración tuvo éxito: rotar el rol de identidad de la instancia, cada clave de proveedor guardada en la base de datos del proxy, las claves maestras y virtuales, la contraseña de la base de datos y cualquier secreto presente en el entorno de cualquier proceso de ese equipo. Buscar rastros como cook.pth ayuda a confirmar, pero la ausencia del archivo marcador no prueba un equipo limpio.
Este es el segundo compromiso de la cadena de suministro de LiteLLM en 2026. Datadog vinculó el incidente de marzo, que tocó las versiones 1.82.7 y 1.82.8, con la actividad de TeamPCP, y aclaró que ningún vínculo quedó establecido entre aquella campaña y esta. Dos ataques en un año sobre la misma pieza dejan una lección concreta para cualquier equipo que programe con modelos de lenguaje: fijar versiones, revisar registros y tratar los tokens de los desarrolladores como llaves maestras.
Fuente: LiteLLM
Foto: Help Net Security
