Ataque a la cadena de suministro TeamPCP envenena paquetes de LiteLLM en PyPI

El 24 de marzo de 2026, entre las 10:39 UTC y aproximadamente las 13:39 UTC, el grupo de amenazas TeamPCP publicó dos versiones con backdoor del paquete Python LiteLLM en PyPI: las versiones 1.82.7 y 1.82.8. PyPI puso en cuarentena los paquetes unas tres horas después de su subida, pero el tiempo de exposición fue suficiente para causar daño real.

LiteLLM es una capa proxy de código abierto que usan miles de equipos de IA para enrutar peticiones a OpenAI, Anthropic, AWS Bedrock y otros proveedores de LLM. Comprometer este paquete es un objetivo ideal para ataques a la cadena de suministro: un paquete envenenado da acceso a todas las claves API que el sistema puede alcanzar.

Cómo funcionó el ataque

El origen del compromiso fue una GitHub Action de Trivy secuestrada dentro del propio pipeline de CI/CD de LiteLLM. TeamPCP primero envenenó el escáner de seguridad Trivy (CVE-2026-33634), obtuvo acceso a las credenciales de publicación de PyPI del mantenedor de LiteLLM y luego saltó el flujo oficial de lanzamiento para subir builds maliciosos directamente.

La versión 1.82.7 contenía el payload malicioso dentro del código fuente del paquete. La 1.82.8 fue más lejos: dejó un archivo .pth (litellm_init.pth) que Python ejecuta automáticamente en cada arranque del intérprete a través del mecanismo de importación, incluso en entornos que no importan litellm explícitamente.

Una vez ejecutado, el malware:

• Recolectaba variables de entorno, claves SSH, historial de shell, configs de Docker y secretos de CI/CD
• Apuntaba a credenciales cloud de AWS, GCP y Azure
• Exfiltraba tokens de service accounts de Kubernetes — y podía escalar a comprometer todo el cluster lanzando pods privilegiados node-setup-*
• Cifraba los datos robados con AES-256 + RSA-4096 antes de enviarlos a models.litellm[.]cloud (no es un dominio oficial de LiteLLM)
• Instalaba persistencia mediante un servicio systemd en ~/.config/systemd/user/sysmon.service

La misma campaña TeamPCP atacó simultáneamente telnyx v4.87.1 y v4.87.2, usando una técnica distinta: payloads esteganográficos ocultos dentro de archivos de audio WAV.

Impacto real

Mercor, una startup de reclutamiento con IA, confirmó una brecha directamente vinculada a esta campaña. El grupo Lapsus$ se atribuyó el robo de datos de los sistemas de Mercor. Mercor tenía LiteLLM como parte de su infraestructura.

CISA añadió la vulnerabilidad Langflow relacionada (CVE-2026-33017, CVSS 9.3) — que habilitó etapas anteriores de la cascada TeamPCP — a su catálogo de Vulnerabilidades Explotadas Conocidas el 25 de marzo de 2026.

Qué hacer ahora mismo

Versiones afectadas: litellm 1.82.7 y 1.82.8

Si ejecutaste pip install litellm o recibiste una actualización sin versión fija el 24 de marzo de 2026, trata tu entorno como totalmente comprometido.

1. Rota todo inmediatamente: claves API (OpenAI, Anthropic, AWS, GCP, Azure), contraseñas de base de datos, claves SSH, tokens de Kubernetes y cualquier secreto visible en variables de entorno o logs de CI/CD.
2. Cambia la versión: baja a litellm==1.82.6 o actualiza a litellm>=1.83.0 (limpio y verificado).
3. Busca persistencia: comprueba si existe litellm_init.pth en tu site-packages y ~/.config/systemd/user/sysmon.service.
4. Audita imágenes Docker: las imágenes oficiales de LiteLLM usaban dependencias fijadas y no se vieron afectadas. Las imágenes personalizadas que instalaron vía pip sí pueden estarlo.
5. Revisa logs de CI/CD: LiteLLM ha publicado scripts para GitHub Actions y GitLab para detectar signos de compromiso.

Los usuarios de la imagen oficial del contenedor LiteLLM no están afectados. La vulnerabilidad es específica de quienes instalan directamente con pip install.

La campaña TeamPCP sigue activa. Fija las versiones de tus dependencias de SDKs de IA.