Ataque a la cadena de suministro de LiteLLM: qué robó TeamPCP y qué hacer
En marzo de 2026, un actor de amenazas al que se sigue como TeamPCP publicó en el índice público de paquetes dos versiones con puerta trasera de LiteLLM, la pasarela de LLM de código abierto que suma unos 95 millones de descargas mensuales estimadas en PyPI. Las versiones maliciosas, la 1.82.7 y la 1.82.8, estuvieron disponibles unos 40 minutos antes de que se retiraran. Fue suficiente. En agosto de 2026, investigadores de Hudson Rock y CloudSEK obtuvieron por separado los datos robados y confirmaron el radio de impacto: más de 2.400 organizaciones, más de 430.000 pipelines de CI/CD y secretos (claves de cloud, claves SSH, tokens de API de proveedores de IA) en texto plano en un archivo de 153 GB.
No es una exposición teórica. Si tu infraestructura ejecutó LiteLLM 1.82.7 o 1.82.8 en algún momento de finales de marzo de 2026, debes tratar como comprometida cada credencial que tocara ese entorno hasta que se demuestre lo contrario.
Cómo funcionó realmente el ataque
TeamPCP nunca atacó directamente a los mantenedores de LiteLLM. Atacó a Trivy, el escáner de vulnerabilidades de código abierto de uso generalizado, y comprometió su cadena de suministro de software. El propio pipeline de CI/CD de LiteLLM descargó la compilación envenenada de Trivy como parte de un escaneo automatizado rutinario, y ese paso de escaneo tenía acceso a las credenciales de publicación de LiteLLM en PyPI. TeamPCP usó esas credenciales robadas para publicar dos versiones maliciosas directamente en el paquete litellm real y oficial de PyPI. No hubo typosquatting ni un nombre de paquete parecido: era el paquete auténtico, con una puerta trasera desde el origen.
Uno de los mantenedores de LiteLLM confirmó después que el punto de entrada se remonta directamente al escáner Trivy comprometido que se ejecutaba en su entorno de compilación: un recordatorio de que una herramienta de seguridad dentro de tu pipeline de CI forma parte, ella misma, de tu superficie de ataque de la cadena de suministro.
Qué hacía realmente el payload malicioso
Las wheels con puerta trasera ejecutaban un ataque en tres fases en el momento de instalarse:
- Fase 1: robo de credenciales. Rastreaba las variables de entorno y los archivos de configuración en busca de claves de OpenAI, Anthropic, Azure, AWS y GCP, claves SSH y tokens de cuentas de servicio de Kubernetes.
- Fase 2: movimiento lateral. Usaba cualquier credencial de Kubernetes robada para buscar pods privilegiados y propagarse dentro del clúster.
- Fase 3: persistencia. Instalaba un servicio systemd de puerta trasera que contactaba periódicamente con infraestructura controlada por el atacante para recibir más instrucciones.
La escala: lo que salió a la luz en agosto
El compromiso de marzo fue silencioso: una ventana de 40 minutos que la mayoría de los equipos nunca notó. Lo que lo llevó a las portadas cinco meses después fue la reaparición de los propios datos. Hudson Rock obtuvo un archivo de 153 GB con 433.909 ficheros vinculados a la campaña de TeamPCP, entre ellos 118.829 volcados de runners de CI/CD que pudo atribuir a 2.488 dominios corporativos distintos. CloudSEK, trabajando con un conjunto de datos separado de unos 434.000 archivos robados, llegó a una cifra similar: cerca de 2.500 organizaciones expuestas.
Ambas empresas han publicado portales de comprobación de dominios para que las organizaciones puedan consultar si su infraestructura aparece en el material filtrado. Los análisis del archivo han vinculado de forma circunstancial nombres grandes y reconocibles (entre ellos Nvidia, AWS, Samsung, Intel, Cisco, Salesforce, Boeing y otros) con volcados de runners de CI expuestos. Conviene ser preciso sobre lo que eso significa: los investigadores lo describen como exposición con alta confianza, no como compromiso confirmado de los sistemas de producción de esas empresas. Un volcado de un runner de CI/CD filtrado y atribuido a un dominio corporativo demuestra que una credencial o una variable de entorno de ese entorno estaba en el archivo; no demuestra por sí solo qué hizo un atacante con ella. Trata los titulares con nombres de empresas como una señal de escala, no como un informe de brecha verificado para cada nombre.
Qué hacer ahora mismo
pip install litellm==1.82.6 (o la versión corregida actual) y fíjala explícitamente. Purga las cachés de pip y de compilación de CI: la wheel maliciosa puede persistir en una caché después de corregir el lockfile.node-setup-* indicados arriba. Revisa los logs de salida en busca de conexiones a los dominios de C2 listados, desde finales de marzo de 2026.El patrón detrás de esto
No es el primer movimiento de TeamPCP: el mismo grupo se ha vinculado a compromisos anteriores tanto de Trivy como de la herramienta de análisis estático KICS, usando la cadena de suministro de una herramienta de seguridad de código abierto para llegar al proyecto siguiente. Esa es la parte en la que merece la pena detenerse: el ataque no necesitó engañar a ningún ingeniero de LiteLLM. Necesitó comprometer una dependencia en la que todos los pipelines de CI/CD confían por defecto, porque su único propósito es encontrar vulnerabilidades, no ser una.
La lección va más allá de LiteLLM. Cualquier herramienta con un lugar privilegiado en tu pipeline de compilación (escáneres, linters, formateadores, ejecutores de pruebas) merece el mismo escrutinio que una dependencia de producción, porque un compromiso ahí hereda todas las credenciales que puede ver el pipeline.