LiteLLM con puerta trasera: cuando un escáner CI envenenado controla la pasarela LLM

Qué ocurrió

El 24 de marzo de 2026, se publicaron en PyPI dos versiones maliciosas del paquete de Python litellm — 1.82.7 y 1.82.8 — por un actor rastreado como TeamPCP. LiteLLM es la biblioteca de pasarela de modelos que se sitúa bajo CrewAI, DSPy, MLflow, OpenHands y decenas de otros frameworks de agentes, descargada millones de veces al día. Los paquetes estuvieron disponibles durante unas tres horas antes de que PyPI los pusiera en cuarentena, según el análisis de Snyk y Help Net Security.

Los atacantes nunca explotaron un fallo en el propio código de LiteLLM. Obtuvieron el token PYPI_PUBLISH del proyecto comprometiendo primero Trivy, un escáner de código abierto que se ejecutaba en el pipeline CI de LiteLLM. Es un caso de manual de ataque a la cadena de herramientas: envenenar una dependencia de compilación de confianza, recolectar el secreto que puede leer y publicar una versión maliciosa firmada legítimamente.

Cómo funciona

La cadena se desarrolló a lo largo de cinco días, y cada salto reutilizó la misma infraestructura de exfiltración (una clave RSA compartida y un nombre de archivo tpcp.tar.gz confirmados en todas las operaciones por Wiz y Unit 42):

• 19 de marzo — TeamPCP reescribió etiquetas Git en el repositorio trivy-action para que una etiqueta de versión apuntara a una versión maliciosa, tras robar las credenciales de automatización de Aqua mediante un workflow pull_request_target («Pwn Request») que descarga y ejecuta código de fork no confiable.
• 23 de marzo — El mismo guion golpeó a Checkmarx KICS; se registraron el dominio C2 checkmarx.zone y el dominio de exfiltración models.litellm.cloud.
• 24 de marzo — La CI de LiteLLM ejecutó el Trivy envenenado desde apt, sin una versión fijada. La acción comprometida leyó el token PYPI_PUBLISH del entorno del runner, y los atacantes lo usaron para publicar las dos versiones con puerta trasera.

La carga útil en sí era un ladrón de credenciales en tres etapas: recolectar secretos (claves SSH, archivos .env, credenciales de nube y Kubernetes, frases de recuperación de monederos), cifrar y enviar (POST) al dominio de exfiltración, y luego instalar un servicio de usuario systemd para persistencia e intentar movimiento lateral entre los namespaces de Kubernetes. La versión 1.82.8 reforzó la entrega con un hook de arranque .pth — un archivo colocado en site-packages/ que se ejecuta en cada lanzamiento del intérprete de Python, incluido el propio pip install, sin necesidad de importación alguna. Como el paquete estaba firmado con credenciales legítimas pero robadas, pasó sin problemas la verificación de hash de pip. Omitimos deliberadamente el detalle interno de la carga útil; las conclusiones defensivas siguientes no lo requieren.

Un matiz destacable: parte de la selección de objetivos de la campaña fue dirigida por un bot de ataque autónomo. StepSecurity documentó hackerbot-claw, una cuenta de GitHub que se describe como un «agente autónomo de investigación de seguridad», que escaneaba repositorios y abría pull requests de explotación contra proyectos de Microsoft, DataDog y la CNCF durante una ventana de diez días — uno de los primeros casos observados de un agente de IA dirigiendo operativamente intrusiones en la cadena de suministro.

Por qué importa

La pasarela LLM se está convirtiendo en el almacén de secretos más concentrado de una pila de IA. A un enrutador como LiteLLM se le confían, por diseño, las claves de API de cada proveedor de modelos al que da frente, además del entorno del host que lo ejecuta. Comprometer esa única posición permite interceptar los secretos de toda la flota sin vulnerar a ningún proveedor aguas arriba — exactamente la palanca que buscó TeamPCP. Help Net Security y Unit 42 destacan el patrón más amplio: la campaña apuntó deliberadamente a herramientas de seguridad (Trivy, Checkmarx) porque los escáneres tienen amplio acceso de lectura a los pipelines en los que se ejecutan. Su herramienta defensiva es parte de su superficie de ataque.

Defensas

• Fije cada dependencia de CI por huella, no por etiqueta. Las etiquetas Git son mutables; fije las GitHub Actions y las herramientas de línea de comandos a un SHA de commit o a un hash de contenido para que una etiqueta reescrita no pueda introducir silenciosamente una versión maliciosa.
• Blinde pull_request_target. Nunca descargue ni ejecute código de fork no confiable en un workflow privilegiado. Use pull_request para la CI de forks, condicione los jobs privilegiados a una aprobación manual y limite GITHUB_TOKEN a solo lectura.
• Restrinja las credenciales de publicación. Prefiera el Trusted Publishing de PyPI (basado en OIDC, de vida corta) frente a los tokens PYPI_PUBLISH de larga duración, y aísle el paso de publicación de los pasos que ejecutan herramientas de terceros.
• Vigile el tráfico de red saliente durante la compilación. Permita por lista blanca los destinos salientes de los runners, de modo que un curl inesperado hacia un dominio desconocido sea bloqueado y alertado, no ejecutado en silencio.
• Detecte los hooks de arranque .pth. La verificación de hash por sí sola no detecta un paquete malicioso pero firmado válidamente. Señale cualquier dependencia que instale un archivo .pth que contenga exec, subprocess o base64.
• Si ejecutó 1.82.7 o 1.82.8: trate el host como comprometido, fije a <=1.82.6 (o una versión limpia posterior), rote todas las credenciales accesibles y busque el servicio de persistencia y los pods de Kubernetes con nombre node-setup-*.

Estado

Elemento	Estado
Versiones litellm afectadas	1.82.7, 1.82.8 — en cuarentena y retiradas de PyPI
Versiones seguras	≤ 1.82.6, más las versiones limpias tras la rotación de claves (24 de marzo)
Causa raíz	Robo del token PYPI_PUBLISH mediante Trivy envenenado en la CI
Divulgación	FutureSearch dio la alarma el 24 de marzo de 2026; claves rotadas ese mismo día
Campaña más amplia	TeamPCP también golpeó a Trivy (19 de marzo) y Checkmarx KICS (23 de marzo)

Fechas y detalles técnicos tomados de Snyk (24 de marzo de 2026), Help Net Security (25 de marzo de 2026), Palo Alto Unit 42 y StepSecurity. Los números de versión y los indicadores de infraestructura reflejan las conclusiones publicadas por esos proveedores.