LiteLLM es el gateway que muchas empresas ponen delante de sus modelos para centralizar claves de OpenAI, Anthropic o AWS Bedrock. El 21 de octubre alguien publicó con las propias credenciales de sus mantenedores una versión 1.107.0 con un robacredenciales y una puerta trasera. La parte instructiva no es el malware: es cómo se saltaron los controles de release.
Qué pasó, según el reporte oficial de LiteLLM
LiteLLM publicó un informe del incidente del 21 de octubre de 2026: el pipeline de release fue comprometido y una versión maliciosa litellm==1.107.0 llegó a PyPI y a los registros de contenedores. El propio informe advierte que algunas suposiciones iniciales resultaron inexactas o incompletas, así que conviene leerlo como un reporte en evolución. Socket, Datadog Security Labs, StepSecurity, OX Security y Mend publicaron análisis del mismo incidente.
Ventanas de exposición: PyPI, de 11:39 a 13:23 UTC; Docker Hub (v1.107.0, latest, main-latest, main-stable), de 11:46 a 14:20 UTC. El tag de código v1.107.0 en el repositorio oficial no contiene los archivos maliciosos, y según el informe los clientes con registro privado empresarial no se vieron afectados.
Cómo funciona el ataque: el pipeline como objetivo
El atacante no vulneró PyPI: usó tres sets de tokens OAuth de GitHub CLI de desarrolladores. Con uno, con permisos de propietario de la organización, desactivó la protección de ramas y modificó el workflow de release; con otro cumplió la aprobación que exigía producción; con el tercero borró el rastro. Datadog añade que el fork usado, Berri-AI/litellm, se parece al legítimo en un solo guion. LiteLLM dice que permisos de release se habían ampliado temporalmente esa semana, lo que facilitó que dos credenciales robadas bastaran.
Qué hacía el paquete
Según Mend, los siete wheels compilados traían tres archivos extra. Uno es un hook .pth que se ejecuta cada vez que arranca Python, aunque nunca importes LiteLLM; otro es un cargador que descarga y ejecuta código remoto cada hora (una puerta trasera tipo RAT, en palabras de OX Security). El informe oficial nombra los archivos cook.pth, cook.py y sitecustomize.py. Un daemon de Python se queda en segundo plano con un lockfile en /tmp/remote_code_loader.lock. Quitar solo la carpeta de LiteLLM no basta: los componentes de arranque viven fuera de ella.
Qué hacer si instalaste 1.107.0
- Fijá
litellm==1.106.2u otra versión anterior al incidente y reconstruí imágenes y virtualenvs desde cero. No corraspip installprimero en el entorno sospechoso: Python reejecuta los archivos al arrancar. - Eliminá los archivos mencionados de cada
site-packagesy matá el daemon. - Si corrió en un host con salida a internet, asumí que hubo exfiltración: rotá el rol IAM, las claves de proveedores guardadas en la base del proxy, master y virtual keys, la contraseña de
DATABASE_URLy los secretos en variables de entorno. Revisá CloudTrail por llamadasGetCallerIdentitycerca de la instalación.