LiteLLM es una librería Python que actúa como gateway unificado para acceder a múltiples modelos de IA a través de una sola API. Creada por BerriAI, alcanza 97 millones de descargas mensuales y proporciona compatibilidad con más de 100 modelos de IA de diferentes proveedores (OpenAI, Anthropic, Google, Meta, entre otros).
En pocas palabras: No actualices LiteLLM a las versiones 1.82.7 ni 1.82.8 — fueron comprometidas el 24 de marzo con malware que roba credenciales cloud, SSH keys y API keys. La última versión segura es la 1.82.6. El grupo TeamPCP fue responsable.
El 24 de marzo de 2026, las versiones 1.82.7 y 1.82.8 de LiteLLM — la librería Python con 97 millones de descargas mensuales que sirve como gateway unificado para más de 100 modelos de IA — fueron comprometidas en PyPI con malware que roba credenciales cloud, claves SSH, API keys y hasta wallets crypto. El paquete LiteLLM PyPI comprometido fue subido directamente al repositorio sin pasar por GitHub, y el grupo TeamPCP se atribuyó el ataque.
En 30 segundos
- Las versiones 1.82.7 y 1.82.8 de LiteLLM en PyPI contienen malware que roba credenciales de AWS, GCP, Azure, Kubernetes, claves SSH y API keys — la última versión segura es la 1.82.6
- El ataque fue ejecutado por TeamPCP, el mismo grupo que comprometió Trivy y KICS en marzo de 2026, encadenando credenciales robadas para saltar entre ecosistemas
- La versión 1.82.8 incluye un archivo .pth que se ejecuta automáticamente con cualquier proceso Python del entorno, sin necesidad de importar la librería
- Los datos robados se cifran con AES-256-CBC + RSA 4096-bit y se exfiltran a models.litellm.cloud, un dominio falso que imita al oficial
- En entornos Kubernetes, el malware lee todos los secrets del cluster y despliega backdoors persistentes en el namespace kube-system
Qué es LiteLLM y por qué importa este ataque
LiteLLM es una librería Python de código abierto desarrollada por BerriAI que funciona como proxy y gateway unificado para más de 100 proveedores de modelos de lenguaje: OpenAI, Anthropic, Google Gemini, Mistral, Cohere y muchos más. Con más de 40.000 estrellas en GitHub y 95 millones de descargas mensuales según CyberInsider, es una de las dependencias más usadas en stacks de IA empresariales.
La gracia de LiteLLM es que te abstrae la complejidad de manejar múltiples APIs de LLMs con una interfaz unificada. Lo usan equipos de ML para construir aplicaciones RAG, orquestar agentes de IA y gestionar pipelines de inferencia. Eso significa que la librería tiene acceso privilegiado a prácticamente todo: API keys de cada proveedor, credenciales cloud para despliegue, tokens de autenticación. Un lugar ideal para meter un backdoor.
Qué pasó: cronología del ataque a LiteLLM en PyPI
El 24 de marzo de 2026 a las 10:52 UTC, según los issues reportados en GitHub, apareció en PyPI la versión 1.82.8 de LiteLLM. La versión 1.82.7 también estaba comprometida. Acá viene lo importante: ninguna de las dos versiones tiene un tag ni un release correspondiente en el repositorio de GitHub.
El paquete fue subido directamente a PyPI, salteando por completo el flujo normal de CI/CD de BerriAI. Cualquiera que haya mantenido un paquete open source sabe que eso es una señal de alarma enorme. El proceso legítimo pasa por GitHub Actions, genera el build, y publica. Acá alguien consiguió las credenciales de la cuenta PyPI del proyecto y subió el paquete a mano. Si te interesa, podés leer más sobre nuestra guía completa sobre ChatGPT.
La detección no tardó mucho — la comunidad empezó a reportar comportamiento sospechoso en cuestión de horas, y PyPI terminó eliminando el paquete completo. La última versión limpia es la 1.82.6.
Cómo funciona el malware: mecanismo técnico del ataque
El ataque usa dos vectores distintos, uno por cada versión comprometida. No es un copiar y pegar — cada payload tiene su propio mecanismo de ejecución, lo que sugiere un nivel de sofisticación considerable.
Versión 1.82.7: código ofuscado en el proxy
La 1.82.7 esconde 12 líneas de código ofuscado dentro de proxy/proxy_server.py, insertadas durante el build del wheel. El código se ejecuta cuando el proxy arranca, algo que pasa en prácticamente cualquier despliegue de LiteLLM en producción. Si te interesa, podés leer más sobre todo sobre los modelos GPT.
Versión 1.82.8: el archivo .pth que no necesita import
La 1.82.8 va más lejos. Incluye un archivo llamado litellm_init.pth que, según el análisis de SafeDep, se ejecuta automáticamente al iniciar cualquier proceso Python en el entorno donde está instalado. Ni siquiera hace falta que tu código importe LiteLLM. Si la librería está en el entorno virtual, el .pth se ejecuta. Punto.
Eso es especialmente grave en entornos de CI/CD y servidores compartidos, donde un entorno Python puede correr múltiples aplicaciones.
Qué roba y cómo lo exfiltra
Una vez activo, el malware recolecta de todo:
- Claves SSH (
~/.ssh/) - Credenciales cloud: AWS access keys, GCP ADC, tokens de Azure
- Configuraciones de Kubernetes (
~/.kube/config) - Wallets de criptomonedas
- API keys de archivos
.env - Contraseñas de bases de datos
.gitconfige historial de shell
Todo eso se cifra con AES-256-CBC y una clave RSA de 4096 bits — o sea que solo el atacante puede descifrar lo capturado — y se envía vía POST a models.litellm.cloud. Ojo: el dominio legítimo de LiteLLM es litellm.ai. El dominio de exfiltración es un typosquatting diseñado para pasar desapercibido en logs de red.
En entornos Kubernetes, la cosa empeora. El malware lee todos los secrets del cluster, crea pods privilegiados con imagen alpine:latest en el namespace kube-system, e instala un backdoor persistente en /root/.config/sysmon/sysmon.py con un servicio systemd para que sobreviva a reinicios. Si te interesa, podés leer más sobre la guía de Gemini que preparamos.
TeamPCP: el grupo detrás de la campaña
LiteLLM no es un caso aislado. Según Endor Labs, TeamPCP ejecutó tres ataques encadenados durante marzo de 2026, cada uno financiando o habilitando el siguiente:
- Trivy (Aqua Security): entre el 28 de febrero y el 19 de marzo, comprometieron 75-76 tags de la GitHub Action de Trivy con backdoors
- KICS (Checkmarx): el 23 de marzo, la GitHub Action de KICS estuvo comprometida entre las 12:58 y las 16:50 UTC
- LiteLLM (BerriAI): el 24 de marzo, las versiones 1.82.7 y 1.82.8 en PyPI
El patrón es claro: cada ataque les dio credenciales que usaron para desbloquear el siguiente. Las credenciales robadas de la GitHub Action de Trivy probablemente les dieron acceso a tokens de CI/CD de otros proyectos. También desplegaron CanisterWorm en npm según Wiz, lo que significa que la campaña abarca al menos 5 ecosistemas de supply chain en un mes.
El commit que dejaron en el repo de BerriAI decía “teampcp owns BerriAI”. No es sutileza lo que les falta.
Cómo verificar si estás afectado
Antes que nada, revisá qué versión tenés instalada:
pip show litellm
Si dice 1.82.7 o 1.82.8, estás en problemas. Pero el chequeo no termina ahí. Si usás uv como gestor de paquetes, revisá también la caché:
find $(uv cache dir) -name "litellm*" -ls
Para detectar el archivo malicioso .pth en tu entorno virtual:
find /path/to/venv -name "litellm_init.pth"
En entornos Kubernetes, buscá pods sospechosos:
kubectl get pods -n kube-system | grep node-setup
Y verificá si hay archivos de backdoor:
find /root/.config/sysmon/ -type f 2>/dev/null
Finalmente, revisá tus logs de red en busca de conexiones salientes hacia models.litellm.cloud. Si encontrás tráfico hacia ese dominio, asumí compromiso total. Si te interesa, podés leer más sobre cómo funcionan los modelos de lenguaje.
Qué hacer si instalaste las versiones comprometidas
Esto no es un “desinstalar y listo”. Si tuviste la 1.82.7 o 1.82.8 instalada en algún momento, el plan de remediación tiene que ser agresivo:
- Desinstalar y reinstalar:
pip uninstall litellm && pip install litellm==1.82.6. Si ya hay una versión limpia posterior, usá esa. - Rotar TODAS las credenciales: claves SSH, tokens de AWS/GCP/Azure, credenciales de Kubernetes, API keys de cualquier proveedor de LLM, contraseñas de bases de datos. Todo. Si el malware estuvo activo, hay que asumir que capturó todo lo accesible.
- Auditar Kubernetes: buscar pods no autorizados en
kube-system, secrets accedidos recientemente, y servicios systemd nuevos en los nodos. - Revisar logs de red: cualquier conexión a
models.litellm.cloudconfirma exfiltración. - Notificar al equipo de seguridad: esto es un incidente de seguridad completo, no un bug. Tratalo como tal.
La rotación de credenciales es lo más urgente. El malware cifra los datos con RSA 4096-bit, así que no podés interceptar ni ver qué se exfiltró — solo podés asumir lo peor y actuar en consecuencia.
Cómo proteger tus proyectos Python de ataques supply chain
Después de Ultralytics en diciembre 2024, dYdX en febrero 2026, y ahora LiteLLM, la pregunta dejó de ser “si” te va a tocar un ataque de supply chain y pasó a ser “cuándo”. Según FutureSearch, entre julio de 2025 y enero de 2026 se detectaron 128 paquetes phantom en PyPI con más de 121.000 descargas combinadas.
| Herramienta / Práctica | Qué hace | Dificultad de implementación |
|---|---|---|
| Pinear versiones con hashes (pip-tools, poetry.lock) | Garantiza que instalás exactamente el binario verificado, no una versión modificada | Baja — un cambio en el workflow de dependencias |
| pip-audit | Verifica paquetes instalados contra la base de datos de vulnerabilidades conocidas | Baja — un comando en CI |
| GuardDog (Datadog) | Análisis estático de paquetes PyPI/npm antes de instalarlos | Media — requiere integración en el pipeline |
| Trusted Publishers en PyPI | Vincula los releases de PyPI con builds específicos de CI/CD, impidiendo uploads manuales | Media — requiere configuración en PyPI y CI |
| Retrasar actualizaciones 24-48h | Da tiempo a la comunidad de detectar paquetes maliciosos antes de que lleguen a tu entorno | Baja — política, no tooling |
| Verificar tags de GitHub vs PyPI | Si PyPI tiene una versión sin tag correspondiente en GitHub, es sospechosa | Baja — verificación manual o scripteable |
| Endor Labs / Snyk en CI/CD | Escaneo continuo de dependencias con detección de comportamiento malicioso | Media-alta — requiere suscripción y configuración |
El punto más importante, y el más fácil de implementar, es dejar de correr pip install --upgrade a ciegas. Pineá versiones. Verificá hashes. Y si ves una versión nueva de una dependencia crítica, esperá al menos un día antes de actualizar en producción. Si te interesa, podés leer más sobre nuestra guía sobre Claude de Anthropic.
Impacto en el ecosistema de herramientas de IA
Lo que hace particular a este ataque es el target. No es un paquete random de npm con nombre similar a otro — es una pieza central de infraestructura de IA que usan empresas para manejar acceso a modelos de lenguaje en producción. Un proxy de LLMs comprometido tiene acceso a las API keys de cada proveedor configurado. Si tu empresa usa LiteLLM para rutear requests a OpenAI, Anthropic y Google, un atacante con esas keys puede generar costos masivos, acceder a datos procesados por los modelos, o simplemente vender las credenciales.
El patrón de TeamPCP marca una tendencia preocupante: atacar herramientas de seguridad y de IA, infraestructura que se ejecuta con privilegios altos porque necesita acceder a todo. Trivy es un escáner de vulnerabilidades — corre en CI/CD con acceso a repositorios y registros de containers. KICS analiza infraestructura como código — tiene acceso a configs de Terraform y Kubernetes. LiteLLM maneja credenciales de APIs de IA. Son targets de alta confianza.
Para equipos en Latinoamérica que están adoptando stacks de IA en producción, la lección es directa: las dependencias de IA necesitan el mismo nivel de escrutinio que cualquier otra dependencia crítica. Si desplegás LiteLLM en un servidor cloud, las credenciales de ese servidor — incluyendo las de donweb.com u otro proveedor de infraestructura — están en juego si el paquete se compromete.
Errores comunes
Creer que con desinstalar alcanza
Si el malware corrió aunque sea una vez, ya capturó y exfiltró credenciales. Desinstalar LiteLLM soluciona el vector de ataque futuro, pero no deshace el daño. Hay que rotar todo: SSH keys, tokens cloud, API keys, passwords de DB. Sin excepción. Si te interesa, podés leer más sobre el ecosistema de IA de Google.
Revisar solo el entorno de producción
Muchos equipos corren pip install litellm en máquinas de desarrollo, notebooks de Jupyter, runners de CI/CD y ambientes de staging. El archivo .pth de la versión 1.82.8 se activa en cualquier proceso Python del entorno, no solo cuando usás LiteLLM. Si actualizaste en tu laptop para probar algo, esa laptop está comprometida.
Confiar en que PyPI valida la seguridad de los paquetes
PyPI no hace análisis de malware antes de publicar un paquete. Es un repositorio, no un antivirus. Si alguien tiene las credenciales de una cuenta de mantenedor, puede subir lo que quiera. La responsabilidad de verificar qué instalás es tuya. Trusted Publishers ayuda a mitigar esto vinculando los releases con builds de CI específicos, pero todavía no es obligatorio.
Asumir que el lockfile te protege
Un poetry.lock o requirements.txt con versiones pineadas te protege de actualizaciones automáticas, sí. Pero si corriste pip install litellm --upgrade manualmente o si tu CI usa >=1.82.0 como constraint, el lockfile no sirvió de nada. Los hashes en el lockfile son la protección real — sin hashes, solo verificás el número de versión, no el contenido.
Preguntas Frecuentes
¿Qué versiones de LiteLLM están comprometidas y cuál es la última segura?
Las versiones 1.82.7 y 1.82.8 en PyPI contienen malware. La última versión segura confirmada es la 1.82.6. Si tenés cualquiera de las dos versiones afectadas, desinstalá inmediatamente y volvé a la 1.82.6.
¿El malware se ejecuta solo si importo LiteLLM en mi código?
No. La versión 1.82.8 incluye un archivo .pth que se ejecuta automáticamente cuando arranca cualquier proceso Python en el entorno donde LiteLLM está instalado. No necesitás importar la librería ni usarla — basta con que esté en el entorno virtual o en el sistema.
¿Cómo sé si mis credenciales fueron exfiltradas?
Revisá los logs de red en busca de conexiones salientes a models.litellm.cloud. Si encontrás tráfico hacia ese dominio, la exfiltración se confirmó. Pero incluso sin evidencia en logs, si la versión comprometida estuvo instalada y corrió algún proceso Python, asumí que las credenciales fueron capturadas y rotalas todas.
¿Qué otros proyectos atacó TeamPCP en marzo de 2026?
TeamPCP comprometió la GitHub Action de Trivy (Aqua Security) entre el 28 de febrero y el 19 de marzo, la GitHub Action de KICS (Checkmarx) el 23 de marzo, y desplegó CanisterWorm en npm. Cada ataque les proporcionó credenciales que usaron para ejecutar el siguiente, abarcando al menos 5 ecosistemas de supply chain.
Conclusión
El compromiso de LiteLLM en PyPI no es un incidente aislado — es el tercer eslabón de una campaña coordinada de TeamPCP que en menos de un mes vulneró herramientas de seguridad y de IA usadas por miles de empresas. Lo que hace esto particularmente grave es la posición privilegiada que LiteLLM ocupa: un proxy de LLMs tiene acceso a todas las API keys, credenciales cloud y configuraciones del entorno donde corre.
Si usás LiteLLM, verificá tu versión ahora. Si tuviste la 1.82.7 o 1.82.8 instalada, tratá el incidente como un compromiso completo y rotá todas las credenciales. Y para el futuro: pineá versiones con hashes, esperá antes de actualizar dependencias críticas, y usá Trusted Publishers en PyPI si mantenés paquetes propios. La cadena de suministro de software es tan fuerte como su eslabón más débil, y hoy ese eslabón son las cuentas de mantenedores sin 2FA.
¿Cuál es la última versión segura de LiteLLM?
La última versión segura es la 1.82.6. Las versiones 1.82.7 y 1.82.8 fueron subidas directamente a PyPI con malware, sin pasar por el repositorio de GitHub. Podés verificar tu versión con pip show litellm y, si tenés alguna de las comprometidas, desinstalar e instalar la 1.82.6 inmediatamente.
¿El malware de LiteLLM se ejecuta aunque no importe la librería en mi código?
Sí, la versión 1.82.8 incluye un archivo litellm_init.pth que se ejecuta automáticamente al iniciar cualquier proceso Python en el entorno donde está instalado. No hace falta que tu código importe LiteLLM; basta con que la librería esté en el entorno virtual para que el payload se active.
¿Qué tengo que hacer si instalé LiteLLM 1.82.7 o 1.82.8?
Desinstalá la librería con pip uninstall litellm e instalá la versión limpia 1.82.6. Después, rotá todas las credenciales del sistema: claves SSH, tokens de AWS/GCP/Azure, API keys de proveedores de LLM y contraseñas de bases de datos. Si usás Kubernetes, auditá el namespace kube-system en busca de pods no autorizados.
Fuentes
- GitHub BerriAI/litellm #24512 – Reporte original del compromiso de las versiones 1.82.7 y 1.82.8
- SafeDep – Análisis técnico del malware en LiteLLM 1.82.8
- Endor Labs – TeamPCP Isn’t Done: análisis de la campaña multi-ecosistema
- CyberInsider – Supply chain attack hits LiteLLM with 95M monthly downloads
- Wiz – TeamPCP attack on KICS GitHub Action
Ejemplo práctico
Martín García es CTO de IA Labs Argentina, una startup que desarrolla asistentes de IA para empresas de logística. El 25 de marzo de 2026 a las 14:32, ejecuta pip install --upgrade litellm en la máquina de desarrollo para obtener las últimas mejoras. Sin revisar la lista de cambios, pip actualiza automáticamente de v1.82.6 a v1.82.7. El código que usa LiteLLM en su pipeline CI/CD importa la librería, lo que dispara la ejecución del archivo .pth malicioso. En menos de 3 segundos, el malware lee el archivo ~/.aws/credentials (donde Martín tiene una clave de AWS con acceso a 8 instancias EC2 de producción) y la cifra + envía a los servidores de TeamPCP.
Los atacantes usan la credencial robada a las 14:47 (15 minutos después) para lanzar 24 instancias p3.8xlarge de GPU en us-east-1 (AWS para GPU intensivo). La factura de AWS salta de $1,200 USD/mes a $3,545 USD en solo 6 horas. El equipo de Martín detecta la anomalía a las 20:15 cuando recibe un alert de AWS sobre gastos inusuales. Para ese momento ya hay $2,345 USD en cargos no autorizados, y pierden 4 horas en forensics (costo de tiempo del equipo: ~$800 USD adicionales).
Resultado medible: $3,145 USD de pérdida directa + 2 días de downtime en desarrollo + revocación de 23 API keys de clientes que estaban en ~/.ssh/config. Si Martín hubiera revisado los cambios de v1.82.6 a v1.82.7 antes de actualizar (o usado un ambiente aislado), esto se prevenía en 60 segundos.