LiteLLM es una biblioteca Python de código abierto muy popular y un servidor proxy que proporciona una interfaz unificada para llamar a más de 100 APIs de Large Language Model (LLM), como OpenAI, Anthropic, Bedrock y VertexAI, utilizando el formato de entrada/salida estándar de OpenAI. Simplifica la integración multi-LLM, ofreciendo características como fallbacks automáticos, reintentos y seguimiento de costes. Debido a que funciona como una pasarela API, actúa como un agregador de credenciales por diseño, manteniendo de forma segura las claves API para varios proveedores LLM.

Visión general

LiteLLM está ampliamente implantado en organizaciones como Stripe, Netflix y Google ADK. Además, gestiona más de 95 millones de descargas mensuales y se utiliza en gran medida como dependencia transitiva en los principales marcos de agentes de IA, incluidos CrewAI, DSPy, Opik, Browser-Use, MLflow y OpenHands.

Un grupo de actores de amenazas con motivaciones financieras conocido como TeamPCP (también rastreado como DeadCatx3, PCPcat, ShellForce y CipherForce) ejecutó un ataque crítico a la cadena de suministro de software en el paquete oficial `litellm` en el Python Package Index (PyPI). TeamPCP, que al parecer colabora con el grupo de extorsión LAPSUS$, atacó las credenciales de publicación en PyPI del CEO y mantenedor principal de LiteLLM, Krrish Dholakia.

¿Quién y qué se vio afectado?

Los atacantes publicaron dos versiones maliciosas (1.82.7 y 1.82.8) directamente en PyPI, saltándose por completo el proceso oficial de publicación CI/CD de GitHub:

• La versión 1.82.7 incluía un payload inyectado codificado en base64 en `litellm/proxy/proxy_server.py` que se ejecutaba maliciosamente cada vez que se importaba el módulo.

• La versión 1.82.8 incluía un archivo altamente peligroso `litellm_init.pth` situado en la raíz de la rueda. Las funciones de configuración de rutas nativas de Python procesan automáticamente los archivos `.pth` al iniciarse el intérprete. Esto significaba que el malware se ejecutaba en segundo plano cada vez que se iniciaba un proceso de Python, independientemente de si el usuario había importado LiteLLM explícitamente.

Cualquier organización, desarrollador, CI/CD pipeline, o proceso de construcción Docker que haya ejecutado `pip install litellm` (o lo haya extraído como una dependencia transitiva no anclada) el 24 de marzo de 2026, entre las 10:39 UTC y aproximadamente las 16:00 UTC, está afectado.

Quién NO está afectado: Los usuarios de la imagen Docker oficial LiteLLM Proxy (`ghcr.io/berriai/litellm`) y LiteLLM Cloud no se vieron comprometidos, ya que sus dependencias estaban estrictamente ancladas a versiones seguras.

El malware desencadenó un devastador ataque en tres fases:

• Recolección sistemática de credenciales: Barrió los sistemas afectados y recopiló claves de API de LLM, claves SSH, credenciales de nube de AWS/GCP/Azure, tokens de cuenta de servicio de Kubernetes, tokens de autenticación de registro de Docker, cadenas de conexión de base de datos, credenciales de Git, historiales de shell, secretos de CI/CD y carteras de criptomonedas.

• Exfiltración: Los datos robados se empaquetaban en un archivo (`tpcp.tar.gz`), se encriptaban utilizando un esquema híbrido AES-256 y RSA-4096, y se enviaban silenciosamente a la nube controlada por el atacante `models.litellm[.]cloud`.

• Movimiento lateral y persistencia: En los clústeres Kubernetes, utilizó tokens de cuentas de servicio accesibles para leer todos los secretos del clúster y desplegar un pod altamente privilegiado `alpine:latest` (`node-setup-*`) en cada nodo. A continuación, instaló una puerta trasera persistente del sistema (`sysmon.py` y `sysmon.service`) que sondeaba periódicamente `checkmarx[.]zone/raw` para descargar y ejecutar cargas útiles arbitrarias de segunda etapa de los atacantes.

Cronología de los hechos

• Finales de febrero de 2026: Un bot de IA autónomo llamado "hackerbot-claw" explotó un flujo de trabajo de solicitud de pull mal configurado en el repositorio Trivy de Aqua Security, robando un token privilegiado de GitHub.

• 19 de marzo de 2026: TeamPCP utilizó el acceso residual de la brecha de Trivy para distribuir un binario Trivy de robo de credenciales y acciones GitHub envenenadas. Debido a que LiteLLM utilizó Trivy en su propio flujo de trabajo de escaneo de seguridad CI/CD sin fijar la versión, el escáner Trivy comprometido cosechó silenciosamente el token `PYPI_PUBLISH` de LiteLLM.

• 20-23 de marzo de 2026: Los actores de la amenaza desplegaron un gusano autopropagable ("CanisterWorm") a través del ecosistema npm y comprometieron las acciones GitHub de Checkmarx KICS. También registraron un dominio de exfiltración malicioso, `models.litellm[.]cloud`, para imitar la infraestructura legítima de LiteLLM y un dominio C2 `checkmarx[.]zone`.

• 24 de marzo de 2026, 10:39 UTC: TeamPCP utilizó el token PyPI robado para publicar la versión maliciosa `litellm` 1.82.7 en PyPI.

• 24 de marzo de 2026, 10:52 UTC: Los atacantes escalaron el ataque publicando la versión 1.82.8, que añadía el agresivo vector de ejecución de archivos `.pth`.

• 24 de marzo de 2026, 11:48 UTC: Los investigadores de seguridad de FutureSearch descubrieron el compromiso después de que el mecanismo de entrega del malware `.pth` creara accidentalmente una "bomba de bifurcación" exponencial que colapsó su sistema.

• 24 de marzo de 2026, 12:44 UTC: Los atacantes desplegaron una red de bots para enviar spam al problema de divulgación de GitHub y utilizaron cuentas de mantenedor comprometidas para desfigurar temporalmente los repositorios y cerrar el problema como "no planificado" para interrumpir la respuesta al incidente.

• 24 de marzo de 2026, 13:38 UTC: El equipo de seguridad de PyPI ha puesto en cuarentena todo el proyecto `litellm`, bloqueando nuevas descargas.

• 24 de marzo de 2026, 15:27 UTC: Las versiones maliciosas fueron borradas permanentemente, las cuentas de los mantenedores fueron recuperadas, y todas las claves fueron rotadas con éxito.

Medidasde mitigación recomendadas

Si sospecha que su sistema, canalización CI/CD o imagen Docker ha encontrado `litellm` 1.82.7 o 1.82.8, debe tomar inmediatamente las siguientes medidas de corrección:

• Identifique la exposición: Compruebe todos los entornos Python para ver si las versiones 1.82.7 o 1.82.8 están actualmente instaladas (`pip show litellm | grep Version`), y busque explícitamente la presencia del archivo `litellm_init.pth` en `site-packages`.

• Asumir compromiso total y rotar secretos: Si alguna de las versiones estaba presente, debes asumir que todas las credenciales, tokens de nube, contraseñas de bases de datos, claves LLM y claves SSH accesibles al entorno han sido robadas. Rote todas las credenciales inmediatamente.

• Elimine la persistencia: Detenga y deshabilite la unidad systemd `sysmon.service` y elimine `~/.config/sysmon/sysmon.py`, `/tmp/pglog` y `/tmp/.pg_state`. En entornos Kubernetes, audite a fondo el espacio de nombres `kube-system` y elimine cualquier pod atacante que coincida con `node-setup-*`.

• Purgar y reconstruir entornos: No se limite a degradar el paquete. Elimine y vuelva a crear los entornos virtuales de Python por completo. Purgar las cachés locales del gestor de paquetes (`pip cache purge` o `rm -rf ~/.cache/uv`) para evitar la reinstalación accidental de ruedas maliciosas almacenadas en caché. Reconstruya los entornos CI afectados a partir de imágenes base limpias.

• Fijar dependencias: Asegúrese de que sus entornos están vinculados a la última versión limpia conocida (`litellm==1.82.6` o anterior).

• Bloquee la infraestructura maliciosa: Bloquee las conexiones de red salientes y la resolución DNS para los IOC conocidos en el perímetro de su red.

Indicadores de compromiso (IOC)

Si le preocupa alguna de las amenazas descritas en este boletín o necesita ayuda para determinar qué medidas debe tomar para protegerse de las amenazas más importantes a las que se enfrenta su organización, póngase en contacto con su gestor de cuenta o, alternativamente, póngase en contactopara averiguar cómo puede proteger su organización.