Supply Chain Attack en LiteLLM: el gateway de los LLMs comprometido
El 24 de marzo de 2026, las versiones 1.82.7 y 1.82.8 de LiteLLM fueron comprometidas en PyPI con un infostealer que robaba credenciales de nube, claves SSH y tokens de Kubernetes —sin necesidad de importar el paquete.
Acción inmediata requerida
Si instalaste dependencias Python el 24 de marzo sin versiones fijadas, asume compromiso. Versiones afectadas: litellm==1.82.7 y litellm==1.82.8. Ancla a litellm<=1.82.6 hasta nuevo aviso.
¿Qué es LiteLLM y por qué es un objetivo de alto valor?
LiteLLM es una capa de abstracción open-source que unifica bajo una API común más de 100 proveedores de LLMs (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, etc.). Su propuesta de valor es simple: escribes código una sola vez y puedes enrutar peticiones a cualquier proveedor sin cambiar tu aplicación.
Esto lo convierte en el chokepoint perfecto para un atacante. Por diseño, LiteLLM reside en entornos que concentran todas las API keys de producción, credenciales de nube y secretos de infraestructura. Con más de 3,4 millones de descargas diarias y presencia en el 36% de entornos cloud, comprometer este paquete es comprometer simultáneamente una fracción enorme del ecosistema de IA en producción.
3.4M+
Descargas diarias
100+
Proveedores de LLM
36%
Entornos cloud afectados
Cronología del ataque
19 Mar 2026
Compromiso de Trivy
Los atacantes del grupo TeamPCP roban credenciales de mantenedor al comprometer el escáner de seguridad Trivy. Esto les da acceso al pipeline de CI/CD de dependencias relacionadas.
24 Mar 2026
Publicación de versiones maliciosas
Saltando el flujo de publicación oficial de GitHub, los atacantes suben directamente a PyPI las versiones 1.82.7 y 1.82.8 de LiteLLM. La ausencia de un mecanismo de firma verificable en PyPI hace posible esta maniobra.
24 Mar 2026
Detección y retirada
Investigadores de seguridad detectan anomalías en el contenido del paquete. Las versiones maliciosas son reportadas y retiradas de PyPI, pero el daño ya está hecho para entornos que instalaron las versiones afectadas.
Análisis técnico del payload
El malware inyectado es un infostealer ofuscado mediante doble codificación Base64. Lo verdaderamente notable no es qué robaba, sino cómo garantizaba su ejecución.
Ejecución en import
El código malicioso se incrustó directamente en el módulo del proxy server del paquete. Se ejecutaba en el momento en que cualquier parte del código realizaba from litellm.proxy import .... Requería que el proceso importara ese submódulo específico.
Persistencia vía .pth — el vector crítico
Esta versión escaló la sofisticación significativamente. Los atacantes introdujeron un archivo llamado litellm_init.pth en el directorio site-packages/ del entorno Python.
Mecanismo .pth: Python procesa automáticamente todos los archivos .pth en site-packages/ al iniciarse el intérprete. Cualquier línea que empiece por import se ejecuta inmediatamente. Esto significa que no era necesario importar litellm —bastaba con arrancar Python en la máquina comprometida.
Datos exfiltrados
Una vez activo, el malware leía todas las variables de entorno del proceso y las enviaba silenciosamente al servidor de comando y control models.litellm.cloud. El botín típico en un entorno de desarrollo de IA incluye:
Por qué este ataque es estructuralmente diferente
Los supply chain attacks en PyPI no son nuevos, pero este tiene tres características que lo hacen especialmente peligroso:
Dependencia transitiva invisible
LiteLLM es una dependencia de frameworks como LangChain, LlamaIndex, AutoGen y muchos otros. Es posible tenerlo instalado en tu entorno sin haberlo declarado explícitamente en tu requirements.txt. Ejecuta pip show litellm para comprobarlo.
Vector de ataque en cadena (Trivy → LiteLLM)
El ataque no empezó en LiteLLM. Empezó en Trivy, un escáner de seguridad de contenedores ampliamente usado en pipelines de CI/CD. Las credenciales robadas allí fueron el pivote para comprometer LiteLLM. Es un recordatorio de que tus herramientas de seguridad también son superficie de ataque.
Supervivencia post-desinstalación
El archivo .pth puede sobrevivir a un pip uninstall si la caché de pip o uv no se limpia correctamente. El malware también instala servicios de persistencia en systemd (~/.config/sysmon/) y puede crear pods en Kubernetes (node-setup-*), lo que requiere una auditoría más profunda que simplemente borrar el paquete.
Plan de respuesta: qué hacer ahora
Ejecuta los siguientes pasos en orden. No te saltes la rotación de secretos aunque no encuentres artefactos.
Identifica si estás afectado
Comprueba también entornos virtuales, imágenes Docker construidas el 24 de marzo y pipelines de CI/CD que no fijen versiones.
Elimina el paquete y limpia cachés
La limpieza de caché es crítica. Sin ella, una reinstalación podría volver a traer la versión maliciosa desde caché local.
Busca artefactos de persistencia
Rota absolutamente todos tus secretos
No te limites a la API key de OpenAI. Rota todo lo que pudiera haber estado en variables de entorno en la máquina afectada: credenciales de AWS/GCP/Azure, claves SSH, tokens de Kubernetes, contraseñas de base de datos y cualquier token de servicio. Recuerda que el malware leía env vars del proceso completo, no solo las relacionadas con LiteLLM.
Reflexión: la superficie de ataque del stack de IA
Este incidente es un síntoma de algo más profundo: el stack de desarrollo de IA ha madurado tan rápido que su seguridad no ha seguido el mismo ritmo. Frameworks, wrappers, herramientas de orquestación de agentes y librerías auxiliares se instalan sin el nivel de escrutinio que se aplica a, por ejemplo, una dependencia de una aplicación bancaria.
LiteLLM es un gateway a docenas de proveedores. Instalar un gateway sin verificar su integridad —sin pinning de versiones, sin hashes de paquete, sin firma verificable— es equivalente a poner todas las llaves de tu castillo en un llavero y dejarlo colgado en la puerta.
En seguridad, los vectores más peligrosos son siempre los que permanecen latentes, invisibles hasta que ya es demasiado tarde. De eso va este blog.