LiteLLM confirma la versión 1.107.0 comprometida en PyPI y sus imágenes
Una intrusión en el pipeline de publicación de LiteLLM distribuyó la versión 1.107.0 con malware por PyPI, Docker Hub y GHCR durante ventanas de unas horas. El proyecto retiró los artefactos; si alguno se ejecutó, su propia guía recomienda tratar el entorno y los secretos accesibles como comprometidos.
LiteLLM confirmó que una intrusión en su pipeline de publicación llevó litellm==1.107.0 a PyPI y versiones de contenedor comprometidas a Docker Hub y GitHub Container Registry (GHCR) el 21 de octubre. El proyecto declaró el incidente contenido y retiró los artefactos. La ventana fue breve; el efecto de una instalación que se ejecutó durante ella puede durar bastante más.
Las ventanas de exposición no coinciden: LiteLLM publicó la rueda de Python entre las 11:39 y las 13:23 UTC. En Docker Hub, las etiquetas v1.107.0, latest, main-latest y main-stable apuntaron a una imagen comprometida entre las 11:46 y las 14:20 UTC; GHCR dejó de servir los índices afectados a las 13:51 UTC. Comprobar solo el horario de una descarga de PyPI no basta para descartar exposición si el despliegue consumía una imagen.
-InfraCrew dice: “Lo retiramos en dos horas” describe el registro; no describe cuánto tardan en rotarse las credenciales que leyó el proceso.-
El wheel cuenta otra historia que el repositorio
El paquete incluyó código malicioso que se ejecutaba al arrancar Python, aunque una aplicación no importara LiteLLM. JFrog encontró los archivos cook.pth, cook.py y sitecustomize.py en las ruedas distribuidas; estos mecanismos de inicio pueden ejecutarse en workers de CI, contenedores y servidores donde se haya iniciado el intérprete. La carga robaba secretos y habilitaba un canal de ejecución remota de código (RCE).
Hay una diferencia importante entre lo publicado y lo construido: JFrog no encontró los tres archivos maliciosos en el tag oficial ni en el archivo fuente, aunque sí detectó cambios de configuración asociados a la rueda. LiteLLM dice que los artefactos afectados se construyeron desde un repositorio controlado por el atacante. La evidencia apunta a una alteración del artefacto de distribución; el mecanismo exacto de intrusión aún no está confirmado, así que atribuirla a una credencial concreta o a un sistema CI específico sería ir más allá de lo demostrado.
-InfraCrew dice: Revisar solo el repositorio es como auditar la receta y no mirar el plato que salió de la cocina.-
El riesgo no se limita al proxy LLM. LiteLLM suele manejar credenciales de proveedores de modelos, pero el análisis de JFrog enumera también claves SSH, credenciales cloud, secretos de CI/CD, configuraciones de Kubernetes y datos que otras herramientas dejan en el mismo entorno. Si el paquete se ejecutó en un worker con acceso a esos recursos, la frontera de exposición es el host y sus permisos, no el nombre de la dependencia afectada.
La contención no limpia los entornos
Los artefactos afectados son concretos: LiteLLM identifica a quienes instalaron la versión 1.107.0 desde PyPI durante su ventana o arrancaron las etiquetas Docker comprometidas en el intervalo señalado. El proyecto recomienda fijar temporalmente la versión 1.106.2 o una versión explícita anterior; también indica que sus versiones previas eran seguras y que los artefactos comprometidos fueron retirados. Esa es una instrucción de selección de versión, no una garantía de que un host que ya ejecutó el paquete esté limpio.
Si la rueda llegó a ejecutarse, el aviso de LiteLLM pide asumir que hubo exfiltración. Aísla el entorno afectado y evita iniciar Python o ejecutar pip dentro de él hasta seguir un procedimiento de limpieza: JFrog advierte que los hooks pueden volver a activarse al arrancar el intérprete. Una búsqueda de los archivos identificados puede confirmar exposición, pero no encontrarlos no descarta compromiso; los contenedores efímeros pueden eliminar rastros temporales.
Después, realiza la rotación desde un entorno limpio de todos los secretos alcanzables por el proceso: claves de proveedores guardadas en el proxy, credenciales cloud y Kubernetes, claves de despliegue y acceso a bases de datos. Revisa también los logs de los servicios que consumían esas credenciales, especialmente si el proxy compartía identidad con automatización o despliegue. Cambiar LiteLLM sin rotar credenciales deja activa la consecuencia más valiosa para quien introdujo la carga.
-InfraCrew dice: Reinstalar una dependencia es rápido; convencer al inventario de secretos de que ya no confíe en el token viejo es la parte que rara vez cabe en el cambio.-
La excepción que declara LiteLLM se limita a los clientes que descargaban su registro empresarial privado; no equivale a decir que cualquier instalación enterprise estuviera a salvo. Para el resto, el equipo debe reconstruir qué artefacto exacto ejecutó cada job y cada contenedor durante las ventanas de compromiso. En ataques a la cadena de suministro, la versión visible y el binario descargado pueden dejar de ser la misma historia.
Diccionario de la Crew
cadena de suministro del software — Procesos, cuentas, repositorios y artefactos por los que pasa una dependencia antes de llegar al entorno que la ejecuta.
wheel — Formato de paquete binario de Python que se instala con herramientas como pip.
RCE — Ejecución de código en un sistema remoto a través de una vulnerabilidad o una carga maliciosa.
CI/CD — Automatización que integra, prueba y publica software de forma continua.
Fuentes
LiteLLM — informe del incidente del 21 de octubre | https://docs.litellm.ai/blog/security-incident-oct-21-2026
JFrog Security Research — análisis de LiteLLM 1.107.0 | https://research.jfrog.com/post/litellm-hijacked-again/
