Forcepoint X-Labs divulgó el 18 de mayo un ataque supply-chain a LiteLLM, el gateway Python open-source que sirve como interfaz unificada a 100+ proveedores LLM. El grupo de amenaza TeamPCP envenenó releases PyPI 1.82.7 y 1.82.8. La cadena de ataque no breach el repositorio fuente de LiteLLM directamente — en cambio, TeamPCP envenenó Trivy (el scanner de vulnerabilidades que LiteLLM usa en su pipeline de build) personificando maintainers de Trivy y disparando procesos de release automatizados para distribuir binarios Trivy backdoored. Cuando el CI/CD de LiteLLM pulled el build de Trivy comprometido, el backdoor scraped la memoria del runner y exfiltró un PYPI_PUBLISH token. Los atacantes luego usaron ese token para publicar releases LiteLLM maliciosos directamente. Divulgado por Prashant Kumar en Forcepoint X-Labs.
El comportamiento del payload difiere entre las dos versiones. La versión 1.82.7 usó payloads Base64-encoded dentro de proxy_server.py ejecutándose al startup del proxy — más fácil de detectar por cualquiera que diffe el archivo. La versión 1.82.8 era más stealthy: desplegaba un archivo litelllm_init.pth en site-packages que se activa "al startup del intérprete Python en cada proceso subsecuente, sin importar si LiteLLM fue alguna vez importado explícitamente." Esa es la escalada clave — una vez instalado, el backdoor corre cada vez que cualquier intérprete Python arranca en ese entorno, no solo cuando se usa LiteLLM. Las credenciales targeted: claves API OpenAI, Anthropic, Microsoft Azure; credenciales SDK AWS, Google Cloud, y Azure; archivos kubeconfig y AWS credential de directorios home de usuarios. La exfiltración fue AES-256-CBC encriptada con una session key de 32 bytes, enviada vía curl a models.litellm.cloud. Un módulo de persistencia llamado Sysmon.py consultaba checkmarx.zone cada 50 minutos por nuevas instrucciones.
La lección arquitectónica es el secuestro de cadena de confianza. TeamPCP no atacó el repositorio bien-defendido de LiteLLM; atacaron Trivy, que el proceso de build de LiteLLM confiaba por defecto. Esta es la misma clase de ataque supply-chain que xz-utils (la personificación de maintainer que casi comprometió systemd) y el ataque npm tj-actions de principios de este año. Cualquier herramienta en tu proceso de build — scanners, formatters, resolvedores de dependencias, linters — es una superficie de ataque potencial, incluso si su trabajo real es security-adjacent. El compromise de LiteLLM es especialmente damaging porque la propuesta de valor entera de LiteLLM es ser el gateway a cada proveedor LLM mayor. Como Prashant Kumar lo dijo: "LiteLLM funciona como un gateway unificado a proveedores AI mayores, significando que un solo compromise dio a atacantes acceso simultáneo a credenciales OpenAI, Anthropic y Azure." Si instalaste 1.82.7 o 1.82.8, cada credencial de proveedor que el entorno tocó está potencialmente en manos de TeamPCP.
Lunes: si tienes cualquier entorno que corrió LiteLLM 1.82.7 o 1.82.8, trata cada clave API a la que el entorno tuvo acceso como comprometida — rota claves OpenAI, Anthropic, Azure, AWS, GCP inmediatamente, y audita logs de uso por solicitudes no familiares. Verifica el archivo litelllm_init.pth en tus site-packages y el módulo de persistencia Sysmon.py. Bloquea egress a models.litellm.cloud y checkmarx.zone en tu capa de red hasta que hayas limpiado el host. Para tu pipeline de build hacia adelante: pinea Trivy y cada otra dependencia de herramienta-de-build a hashes verificados (no solo versiones), requiere releases firmados para tooling security-adjacent, y aísla tokens de publish PyPI para que no sean accesibles a scanners build-time. El writeup de Forcepoint no divulgó el timeline exacto, conteos de descargas, o la respuesta de BerriAI — esas brechas hacen imposible estimar la exposición precisamente. Trata como peor-caso hasta que BerriAI publique una divulgación coordinada.