LiteLLM troyanizado en PyPI: ataque supply chain IA

El 24 de marzo, usando credenciales robadas del ataque previo a Trivy, el grupo TeamPCP publicó dos versiones troyanizadas de LiteLLM en PyPI: 1.82.7 y 1.82.8. Estuvieron disponibles ~5 horas antes de ser removidas. El código malicioso se inyectó directamente en el proxy server de LiteLLM, comprometiendo a cualquiera que hubiera ejecutado pip install litellm en esa ventana. Según el análisis de Kaspersky, el malware robó SSH keys, tokens de cloud, credenciales de bases de datos y API keys de proyectos que usan LiteLLM como proxy para OpenAI, Anthropic y Gemini.

TeamPCP es un grupo cibernético que realiza ataques de cadena de suministro. Compromete paquetes de software en repositorios públicos, como LiteLLM en PyPI, para exfiltrar credenciales.

El contexto: TeamPCP comienza en Trivy, se expande a todo el ecosistema

Arrancamos el 19 de marzo. TeamPCP inyectó malware en Trivy, una herramienta de scanning de vulnerabilidades que millones de pipelines CI/CD ejecutan automáticamente (spoiler: eso convierte a Trivy en una puerta maestra). El malware vivía en las GitHub Actions oficiales y en las Docker images. Cada scan que se ejecutaba, aunque fuera en una rama de desarrollo, triggerizaba el robo de credenciales. Le asignaron CVE-2026-33634 con CVSS 9.4 (casi máximo). En pocas horas, 76 de 77 versiones publicadas de Trivy estaban comprometidas.

El drama: TeamPCP ya tenía credenciales adentro de la infraestructura de decenas de empresas grandes (robadas en un incidente anterior de febrero). Usaron eso como trampolín. Si vos hacés supply chain attack al software que todos confían y está integrado en el build, ganaste acceso a gran parte del ecosistema.

¿Y cuál fue el alcance? Más de 500.000 cuentas fueron marcadas como comprometidas según los reportes; cientos de gigabytes de datos exfiltrados hacia servidores del grupo.

LiteLLM en PyPI: versiones 1.82.7 y 1.82.8 troyanizadas

Así que llegamos al 24 de marzo. TeamPCP, con los accesos pivotados desde Trivy, se metió en las cuentas de mantenedores de PyPI y publicó dos nuevas versiones de LiteLLM: 1.82.7 y 1.82.8. Estuvieron online ~5 horas. El código malicioso se inyectó en proxy_server.py e __init__.py, que significa que se ejecutaba apenas instalabas el paquete.

¿Por qué LiteLLM de todas las cosas? Porque es el proxy de APIs de IA más usado en stacks de producción. Imaginá que vos trabajás con Langflow, o tenés agentes autónomos, o un sistema de RAG en producción. Para no estar hardcodeando 15 API keys diferentes en tu código, usás LiteLLM como intermediario unificado. LiteLLM maneja las requests a OpenAI, Anthropic, Gemini, juntas. (Si es que eso no suena a objetivo de oro para un ataque, no sé qué lo es.) El malware, al instalarse, hacía reconocimiento del entorno y enviaba datos a dominios typosquatting como models.litellm.cloud.

Eso pasó el 23 de marzo con Checkmarx KICS también, por cierto. Tres horas después que lo removieron ahí, cayó el ataque a LiteLLM.

Qué datos robaban los paquetes comprometidos

El script malicioso hacía un escaneo profundo del entorno donde se ejecutaba. Capturaba: En en nuestro análisis de GitHub y seguridad profundizamos sobre esto.

• Credenciales de cloud: tokens AWS, credenciales GCP, secretos de Azure
• Credentials de bases de datos: usuarios y passwords para MySQL, PostgreSQL, MongoDB, Redis
• SSH keys del usuario y credenciales de host remoto
• API keys de cualquier servicio (OpenAI, Anthropic, Gemini, Stripe, etc.) almacenadas en .env o en memoria
• Secretos de Kubernetes si el entorno estaba corriendo en K8s
• Wallets cripto (Solana especialmente)
• Información de GitHub (PATs, deploy keys)

Todo eso se enviaba a servidores del grupo. Si configuraste LiteLLM como proxy en un CI/CD pipeline (cosa común), el malware tenía acceso a todo lo que pasaba por ahí: requests a modelos, credenciales de clientes, datos sensibles.

Por qué LiteLLM es tan crítico en la infraestructura IA moderna

Dejame explicarte por qué esto fue un golpe tan certero. LiteLLM no es un toy: está en 20.000+ repositorios públicos de GitHub. Equipos de IA, MLOps, startups, grandes empresas con pipelines de inferencia, todos lo usan (fijate que es open source, mantenido activamente, documentado, barato de operar).

El rol de LiteLLM: actúa de proxy unificado. Vos llamas a completion(model="gpt-4") o completion(model="claude-3"), y LiteLLM traduce eso, maneja la autenticación, los reintentos, el logging. Un componente que tiene acceso a las llaves de toda tu capa de inferencia. Ataca LiteLLM y comprometiste OpenAI, Anthropic, Gemini en un solo golpe (en el contexto del proyecto víctima, claro).

Dicho eso, la verdadera crueldad del ataque fue que LiteLLM se instala automáticamente si vos estás usando Langflow o agentes como LangChain. Ni siquiera necesitabas saberlo (que no es poco).

El gusano se replica en npm: CanisterWorm

El ataque no quedó limitado a Python. TeamPCP también desplegó CanisterWorm, un malware autorreplicante que se propagó en el ecosistema npm (JavaScript/Node). Eso significa: si tenías un proyecto que mezclaba Python (LiteLLM) y JavaScript/Node en el mismo pipeline, probablemente fuiste compromet ido por ambas vías. Lo explicamos a fondo en en la guía de seguridad de GitHub.

Primer caso documentado en la historia donde una misma campaña coordina ataques simultáneos cross-ecosystem. ¿Por qué npm también? Porque muchos proyectos de IA usan Node para frontend, APIs, serverless functions. Si comprometés ambos, ganás profundidad.

Cómo verificar si tu entorno fue comprometido

Paso 1: Verificar LiteLLM. Ejecutá pip show litellm y mirá la versión. Si ves 1.82.7 o 1.82.8, actualiza inmediatamente a 1.82.9+. Si no, probablemente no bajaste las versiones maliciosas (aunque recomendamos actualizar igualmente para quedarte tranquilo).

Paso 2: Revisar logs. Buscá conexiones salientes a estos dominios typosquatting:

• scan.aquasecurity.org
• checkmarx.zone
• models.litellm.cloud

Si encontrás conexiones a esos dominios en tus logs (especialmente en el momento del 24 de marzo entre las 12 y 17 UTC), tu entorno fue visitado por el malware.

Paso 3: Auditar Trivy y Checkmarx KICS. Verificá qué versiones de trivy-action y setup-trivy estás usando. Versiones seguras: trivy-action v0.35.0 o superior, setup-trivy v0.2.6 o superior. Si estás por debajo de eso, actualiza. Ya lo cubrimos antes en como en los riesgos de proveedores.

Paso 4: Rotar credenciales. Si fuiste afectado: rotá todas las credenciales del entorno ahora. SSH keys, API keys, tokens de cloud, passwords de bases de datos. Todo. No pospongas esto.

Cómo blindar tu pipeline IA contra ataques a la cadena de suministro

El punto clave: después de supply chain attack como este, el standard de “confío en PyPI” se rompió. Tenés que asumir que un paquete podría estar comprometido hasta que verifiques lo contrario.

Confirmado vs. Pendiente de verificar

• ✅ Confirmado: Trivy fue comprometido el 19 de marzo (CVE-2026-33634). LiteLLM versiones 1.82.7 y 1.82.8 fueron publicadas por TeamPCP el 24 de marzo con malware. Checkmarx KICS fue comprometido el 23 de marzo. Más de 500.000 cuentas reportadas como comprometidas. CanisterWorm se propagó en npm de forma coordinada.
• ⏳ Pendiente de verificación independiente: El número exacto de desarrolladores que ejecutaron pip install en esa ventana de 5 horas. Cuántas personas efectivamente robaron credenciales vs. solo hizo reconocimiento. Si hay variantes del malware circulando que no fueron detectadas. Impacto exacto en proyectos de producción que corren LiteLLM en K8s (aunque la exposición teórica es alta).

Errores comunes que la gente comete ante ataques así

1. “Yo no uso esa versión, así que no me afecta” (error de lógica de dependencies)

Incorrecto. Si tu proyecto especifica litellm>=1.82.0 en requirements.txt y ejecutaste pip install -r requirements.txt el 24 de marzo entre las 12 y 17 UTC, bajaste la versión maliciosa automáticamente. pip resuelve dependencies hacia la versión más nueva disponible si usás operadores como >=. Revisá cada archivo requirements.txt, cada setup.py, cada poetry.lock. Lo complementamos en en los fallos de actualizaciones pasadas.

2. “Ya actualicé, listo” (falsa seguridad post-actualización)

Actualizar el paquete no quita el malware que ya se ejecutó. Si hace 4 días instalaste LiteLLM 1.82.7 y el malware ya robó tus credenciales, actualizar a 1.82.9 hoy no cambia eso. Tenés que rotar credenciales asumiendo que fueron comprometidas. El malware pudo haber implantado backdoors adicionales. Nuestros colegas de seguridadenwordpress.com lo analizan en en nuestra comparativa de protección.

3. “Esto es un problema de seguridad de Anthropic / OpenAI” (culpa desplazada)

Técnicamente sí, tus credenciales de OpenAI se vieron comprometidas, pero la cadena de ataques es más profunda. El ataque fue a PyPI / npmjs, no a los servidores de OpenAI. Tu código es el vector de entrada. Implementar las medidas de la tabla (hashes, sandboxing, SLSA) es responsabilidad tuya, no de Anthropic. Complementá con tal como vimos en ataques previos a npm.

Esto se conecta con Langflow y LiteLLM: el ataque a la cadena IA se expande a Py, donde analizamos cómo crecen estas vulnerabilidades.

Esto se conecta directamente con Langflow y LiteLLM: el ataque a la cadena IA se expande a Py, donde profundizamos en el tema.

Esto se conecta con Langflow y LiteLLM: el ataque a la cadena IA se expande a Py, que cubrimos en profundidad acá.

Preguntas Frecuentes

¿Qué versiones de LiteLLM estuvieron comprometidas?

1.82.7 y 1.82.8 publicadas el 24 de marzo. Estuvieron disponibles ~5 horas. Si ejecutaste pip install litellm o pip install litellm==latest en ese período, bajaste la versión maliciosa. Actualiza a 1.82.9+ inmediatamente.

¿Cómo sé si ejecuté pip install con esa versión?

Mirá el timestamp del archivo venv/lib/python3.*/site-packages/litellm-1.82.7.dist-info/ o litellm-1.82.8.dist-info/. Si el timestamp es 24 de marzo de 2026 entre las 12 y 17 UTC y coincide con cuándo corriste tu CI/CD, probablemente bajaste la versión maliciosa. Alternativa: consultá tu CI/CD logs o el historial de pip freeze en tus deployments.

¿Qué hace el malware una vez que está instalado?

Escanea el entorno en busca de SSH keys, API keys, credenciales de cloud, wallets cripto. Las captura y las envía a dominios controlados por TeamPCP. Si tu código pasaba credenciales como variables de entorno o las almacenaba en memoria, fueron capturadas.

¿Donweb tiene esta vulnerabilidad en sus servidores?

No. Donweb usa infraestructura propia con auditoría interna de supply chain. Pero si vos estás deployando código que usa LiteLLM en Donweb hosting o en tu propia infraestructura, el riesgo es tuyo. Revisa tus requirements.txt.

Conclusión

El ataque de TeamPCP a Trivy, Checkmarx, LiteLLM y npm marca un inflexión: la cadena de suministro del software de IA ahora es un target explícito y coordinado. No fue un fuzzing casuales o un CVE descubierto por un researcher. Fue un ataque planificado, multi-ecosistema, con acceso previo al que aprovecharon al máximo.

Lo que cambió: ya no podés confiar ciegamente en que un paquete de PyPI es lo que dice ser. No porque PyPI sea inseguro, sino porque los atacantes apuntaron específicamente a la cadena porque tú confías. La defensa no es dejar de usar pip (eso es irreal), sino:1) Pinear versiones con hashes. 2) Limitar permisos en CI/CD. 3) Rotar credenciales asumiendo compromiso. 4) Monitorear logs buscando conexiones sospechosas.

Para equipos de IA en Latinoamérica: LiteLLM es popular porque simplifica la integración con múltiples modelos. Eso lo hace víctima fácil. Revisa tus deployments ahora, no esperes el próximo incidente.

Fuentes

• Kaspersky — Trojanization of Trivy, Checkmarx, and LiteLLM
• Arctic Wolf — TeamPCP Supply Chain Attack Analysis
• The Hacker News — Trivy Hack Spreads Infostealer