Vuelven a hackear la pipeline de releases de LiteLLM: un infostealer distribuido como v1.107.0 en PyPI y Docker Hub
En la mañana del 21 de octubre de 2026, una versión maliciosa de LiteLLM aterrizó en PyPI y en las imágenes oficiales de Docker del proyecto. La versión 1.107.0 llevaba un ladrón de credenciales y un cargador de código remoto en lugar del código que sus mantenedores habían escrito. Según la actualización de seguridad del propio LiteLLM, la pipeline de releases fue comprometida usando credenciales de GitHub filtradas de cuentas de desarrolladores del proyecto. Las ruedas maliciosas estuvieron menos de dos horas en PyPI, y las etiquetas contaminadas de Docker sobrevivieron toda la tarde. En un ecosistema de builds automatizados y dependencias fijadas, fue tiempo de sobra para que importara.
Un tag limpio, un build envenenado
La revelación se lee como una lista de lo frágil que es la confianza en los paquetes. LiteLLM informa de que el atacante obtuvo tokens OAuth de GitHub CLI de tres cuentas de desarrolladores, al parecer capturados en los registros de un despliegue interno de LiteLLM expuesto a internet; una de las cuentas pertenecía al propietario de una organización de GitHub. Con esas credenciales se anuló la protección de ramas, se forzó un cambio en el workflow y la pipeline se apuntó a un repositorio casi idéntico: Berri-AI/litellm, a un guion del verdadero BerriAI/litellm. El tag oficial de git de v1.107.0 siguió limpio; los artefactos maliciosos se compilaron desde el repositorio impostor."Esta versión contenía malware compilado que roba credenciales y carga herramientas de ejecución remota de código". — actualización de seguridad de LiteLLM, 21 de octubre de 2026La detección, al menos, fue rápida. Como informa BleepingComputer, firmas de seguridad incluidas Socket y Endor Labs marcaron la versión en unos seis minutos, y PyPI retiró las ruedas a las 13:23 UTC, con Docker Hub limpiado esa misma tarde. LiteLLM dice que los clientes de su registro empresarial privado no se vieron afectados. Seis minutos siguen contando cuando el paquete registra unos 92 millones de descargas al mes y compañías como NVIDIA, Netflix y Okta figuran entre sus usuarios, según BleepingComputer.
Lo que el ladrón va buscando
La mecánica de la carga explica lo tajante de las recomendaciones. Las ruedas soltaban tres archivos —cook.pth, cook.py y sitecustomize.py— en el directorio site-packages de Python. Python ejecuta esos tipos de archivo en cada arranque del intérprete, así que cualquier proceso de Python de la máquina ejecutó el malware aunque LiteLLM nunca se importara. El análisis técnico de Datadog Security Labs añade que desinstalar el paquete litellm no elimina los archivos; hay que borrarlos a mano. El análisis del incidente de Kodem documenta lo que el ladrón estaba hecho para recolectar:- Credenciales de nube e infraestructura: claves de AWS, Azure y GCP, incluidos tokens de metadatos de instancia, más secretos de Kubernetes, Docker y Terraform
- Material de IA: claves de API de proveedores de LLM, credenciales guardadas en la base de datos del proxy LiteLLM y archivos de sesión de herramientas de programación con IA
- Tokens de desarrollador y de registros: credenciales de Git, tokens de GitHub, npm y PyPI, claves SSH, GPG y TLS
- Secretos locales: archivos .env, variables de entorno, historiales de shell y de bases de datos
- Datos del navegador: contraseñas guardadas, cookies y entradas de autorrelleno
Segundo incidente de pipeline del año
Es la segunda versión comprometida de LiteLLM en 2026. En marzo, un actor de amenazas rastreado como TeamPCP introdujo un backdoor en las versiones 1.82.7 y 1.82.8 tras comprometer un escáner Trivy dentro de la pipeline de CI/CD del proyecto y robar un token de PyPI. Datadog vincula ambas campañas solo por su objetivo: no hay conexión establecida entre los actores. El patrón es lo incómodo: una pasarela que se sienta en el centro de miles de stacks de IA, guardando claves de proveedores y credenciales de nube, ha visto su canal de distribución corrompido dos veces en ocho meses.La primera hora, según el runbook
Kodem acompañó sus indicadores con un runbook de respuesta para la primera hora, y el aviso de LiteLLM es igual de tajante. El núcleo común:- Bloquear litellm 1.107.0 en el proxy de paquetes, dejar de desplegar etiquetas flotantes como latest y fijar la última versión limpia, 1.106.2, por hash —las imágenes por digest—
- No ejecutar python ni pip en los hosts afectados antes de la limpieza, porque cada arranque del intérprete vuelve a ejecutar la carga
- Aislar hosts y contenedores y borrar a mano cook.pth, cook.py, sitecustomize.py y sus archivos .pyc compilados
- Rotar desde una máquina limpia: roles de nube, claves de proveedores guardadas en la base de datos del proxy, claves maestras y virtuales de LiteLLM, la contraseña de la base de datos y tokens de registros y de GitHub
- Revisar los registros de auditoría de nube en busca de llamadas GetCallerIdentity y de uso de credenciales desde infraestructura inesperada desde las 11:39 UTC del 21 de octubre