LiteLLM 1.107.0 distribuyó malware desde PyPI y Docker: cómo evaluar el riesgo
LiteLLM confirmó que la versión 1.107.0 y varias imágenes Docker estuvieron contaminadas durante unas horas. La ejecución exige tratar el entorno como comprometido, revisar credenciales y reconstruir desde limpio.
El incidente de LiteLLM no fue una dependencia maliciosa escondida en un repositorio cualquiera: el 21 de octubre apareció una versión contaminada en los canales oficiales de distribución. La versión 1.107.0 de PyPI y varias etiquetas Docker llevaban código para robar credenciales y abrir una vía de ejecución remota. Si una de ellas llegó a ejecutarse, el proyecto pide tratar el entorno como comprometido; descargarla sin instalarla no prueba por sí solo que el malware se activara.
Dos canales, dos ventanas de exposición
LiteLLM sitúa la publicación de los siete wheels de Python entre las 11:39 y las 13:23 UTC del 21 de octubre. En Docker Hub, las etiquetas v1.107.0, latest, main-latest y main-stable apuntaron a una imagen afectada entre las 11:46 y las 14:20 UTC; las imágenes equivalentes de GHCR dejaron de estar disponibles antes, a las 13:51 UTC. Las ventanas no son intercambiables: los registros de instalación de pip y los eventos de pull de contenedores tienen que revisarse por separado.
-SecureCrew dice: «latest» es cómodo hasta que descubre que también significa «el atacante decide qué es lo último».-
Según LiteLLM, la publicación maliciosa incluía un ladrón de credenciales y un cargador de herramientas de acceso remoto. Datadog observó que el código podía ejecutarse al iniciar Python mediante mecanismos de inicialización del intérprete, incluso si la aplicación nunca importaba directamente LiteLLM. Por eso, el dato importante no es solo si la biblioteca aparece en el archivo de dependencias, sino si el entorno inició Python o ejecutó una imagen durante el intervalo afectado.
La firma del artefacto no salvó la cadena
La investigación del proyecto describe un flujo de publicación comprometido: credenciales OAuth de GitHub CLI asociadas a tres desarrolladores fueron usadas para alterar y lanzar el pipeline de producción. La secuencia publicó artefactos construidos desde un repositorio de apariencia casi idéntica, Berri-AI/litellm, en lugar del repositorio legítimo BerriAI/litellm. El proyecto dice que los registros de ejecución también fueron borrados, lo que complica reconstruir la cronología completa.
El detalle incómodo es que las protecciones no fallaron todas a la vez. El pipeline rechazó primero un cambio que no había pasado las reglas habituales; después, una cuenta privilegiada logró desactivar esa protección y forzar la modificación. Los artefactos se publicaron por canales y procesos que normalmente se consideran de confianza. Una firma válida acredita quién firmó un paquete y qué bytes se firmaron; por sí sola no demuestra que el código fuente autorizado fuera el correcto.
-SecureCrew dice: los candados de la tubería ayudan, pero una identidad con permiso para quitarlos sigue siendo parte de la superficie de ataque.-
Qué debe revisar un entorno afectado
LiteLLM recomienda asumir compromiso si se instaló 1.107.0 o se arrancó una de las imágenes afectadas dentro de su ventana. La guía oficial señala archivos como cook.pth y sitecustomize.py como indicadores útiles, pero advierte que no encontrarlos no demuestra que el sistema esté limpio. Además, iniciar Python en un entorno contaminado puede volver a ejecutar el código de arranque; por eso el proyecto aconseja no empezar la recuperación ejecutando pip allí.
Para quienes confirmaron la ejecución, el proyecto recomienda reconstruir el entorno desde una base limpia, fijar temporalmente una versión anterior conocida como 1.106.2 y rotar los secretos a los que el proceso podía acceder. Eso incluye credenciales de proveedores de modelos, claves del proxy, contraseñas de base de datos y roles de nube disponibles para la carga de trabajo. Si el host tenía salida a Internet, LiteLLM pide asumir que la extracción pudo ocurrir aunque no haya un marcador visible; la ausencia de evidencia local no cierra el análisis.
Lo que queda por aclarar
El proyecto afirma que los registros privados Enterprise no estuvieron afectados y que las versiones anteriores a 1.107.0 son seguras; son conclusiones de su investigación, que sigue abierta. Datadog añade que la vía de publicación utilizó tokens OAuth robados y un repositorio señuelo, pero la forma inicial en que se obtuvieron las credenciales aún no estaba confirmada en su análisis. No hay base para convertir este episodio en prueba de que cualquier instalación de LiteLLM o cualquier registro privado haya sido alcanzado.
-SecureCrew dice: en una intrusión de cadena de suministro, un «no aparece en el log» puede significar limpieza, no tranquilidad; guarda las evidencias antes de reconstruir.-
Para equipos de plataforma, la lección operativa es cruzar la versión realmente ejecutada, el digest de la imagen y el momento de arranque, no limitarse al tag que figura en un manifiesto actual. Después toca invalidar credenciales accesibles desde los procesos afectados y buscar su uso fuera de la infraestructura habitual. La rotación no revierte accesos ya realizados, pero evita que una clave exfiltrada siga siendo una llave válida.
Diccionario de la Crew
Wheel — archivo de distribución binaria de Python, preparado para instalar un paquete en un entorno.
Token OAuth — credencial delegada que permite a una aplicación actuar con los permisos concedidos a una cuenta.
Pipeline CI/CD — cadena automatizada que prueba, construye y publica cambios de software.