Un ataque a la cadena de suministro cuela malware en LiteLLM y expone miles de secretos en PyPI en minutos

Dos versiones manipuladas de LiteLLM bastaron para convertir una librería muy usada en equipos de IA en una aspiradora de credenciales. El paquete, que actúa como “pasarela” entre aplicaciones y varios modelos de lenguaje, se distribuye a gran velocidad en entornos Python. Y cuando una pieza así cae, el impacto no se queda en el portátil de un desarrollador: puede saltar a servidores, contenedores y pipelines de CI/CD.

El incidente encaja con un ataque desupply chain(cadena de suministro de software) atribuido a TeamPCP, un grupo ya relacionado con otras intrusiones recientes. Las versiones maliciosas se publicaron en PyPI, el repositorio oficial de paquetes de Python, y después se retiraron. A día de hoy, la versión considerada segura es la 1.82.6.

Dos versiones trampa publicadas y retiradas en PyPI

Las versiones comprometidas identificadas son LiteLLM 1.82.7 y 1.82.8. Estuvieron disponibles en PyPI el tiempo suficiente para hacer daño: una vez un atacante consigue acceso para publicar, subir una versión “envenenada” lleva minutos y las instalaciones llegan solas, empujadas por la inercia de los equipos y los automatismos.

En una ventana muy corta, las versiones maliciosas se descargaron cerca de 47.000 veces en 46 minutos, según los primeros indicadores públicos. La cifra no equivale a 47.000 equipos distintos, una descarga puede alimentar un servidor compartido, un runner de CI o una imagen Docker replicada, pero ilustra el problema: en los repositorios de dependencias, la propagación es casi instantánea.

LiteLLM se usa para hablar con distintos proveedores de modelos mediante una única API, lo que lo coloca en el centro de muchas aplicaciones y herramientas internas. Si esa librería toca entornos cloud, clústeres y secretos de acceso, la infección puede escalar rápido y afectar a sistemas con permisos más amplios que los de un usuario individual.

Un “infostealer” en tres fases: robar, exfiltrar y persistir

Investigadores de seguridad, entre ellos Endor Labs, describen un malware estructurado en tres pasos. Primero, una recopilación silenciosa de todo lo que parezca un secreto: claves SSH, contraseñas, credenciales cloud, tokens de Kubernetes e incluso frases de recuperación de monederos cripto. El objetivo no es sabotear de inmediato, sino reunir credenciales reutilizables.

Después llega la exfiltración: los datos se envían a infraestructura controlada por los atacantes en archivos cifrados. En entornos de desarrollo, ese tráfico puede camuflarse entre comunicaciones habituales (descarga de dependencias, llamadas a APIs, subida de artefactos), si no hay una supervisión fina de red en los puestos o runners.

La tercera fase busca persistencia. El código instala una puerta trasera disfrazada de servicio del sistema con un nombre pensado para pasar desapercibido: “System Telemetry Service”. En organizaciones donde nadie inventaría de forma sistemática los servicios instalados en runners o máquinas de build, un componente así puede quedarse y recibir órdenes a distancia.

en la versión 1.82.8 se menciona la incorporación de un archivo.pth que permitiría disparar la carga maliciosa cada vez que arranca Python, incluso aunque LiteLLM no se use activamente. Traducido: basta con instalarlo “para probar” y olvidarse, porque el código podría seguir ejecutándose.

El eslabón débil: Trivy en el pipeline y versiones sin fijar

La cadena de ataque descrita sigue un patrón clásico: comprometer el proceso de construcción y publicación para acabar distribuyendo malware con la “voz” del proyecto legítimo. Según los informes, LiteLLM utilizaba Trivy (una herramienta de análisis de seguridad) en su pipeline sin fijar versiones, una práctica que abre la puerta a que una dependencia comprometida contamine el propio proceso de build.

El giro es incómodo: una herramienta integrada para reducir riesgo puede convertirse en el detonante si se ejecuta sin controles. En el momento clave, la ejecución de una versión comprometida en el pipeline habría expuesto una clave secreta con capacidad para publicar paquetes en nombre de LiteLLM en PyPI. Con esa llave, los atacantes pudieron subir las versiones 1.82.7 y 1.82.8 como si fueran oficiales.

En este tipo de incidentes no suele haber “un bug” aislado, sino una suma de hábitos: dependencias no fijadas, secretos accesibles desde jobs que no deberían verlos y confianza implícita en terceros. También se ha señalado el registro de dominios diseñados para parecer legítimos, como models.litellm.cloud, una táctica que complica la detección si no se validan estrictamente los destinos de red.

Por qué puede golpear a empresas enteras, no solo a desarrolladores

LiteLLM no es un paquete marginal. Se citan cifras de más de 3 millones de descargas diarias y alrededor de 95 millones en los últimos 30 días. Aunque solo dos versiones se vieran afectadas, la base instalada y la frecuencia de actualización en proyectos de IA amplían la superficie de exposición.

El riesgo más serio está en los entornos automatizados: runners de CI/CD, jobs de datos, imágenes Docker, notebooks compartidos. Una instalación automática puede replicar la infección a gran velocidad si las imágenes se reconstruyen con frecuencia. Y si un runner tiene acceso a secretos de despliegue, el robo de credenciales puede abrir la puerta a movimientos laterales dentro de la infraestructura.

Los objetivos del malware apuntan justo a lo que permite “rebotar”: tokens cloud, secretos de Kubernetes, archivos.env. En un escenario real, una clave SSH robada puede dar acceso a un bastión; un token de Kubernetes, a un clúster; y un.env, a claves de APIs de servicios de IA de pago, con impacto económico y de seguridad.

Algunos reportes hablan de unas 500.000 señales de exfiltración o dispositivos infectados, sin confirmación independiente. Conviene tratar esa cifra con cautela, pero sirve para entender la escala potencial. Y hay un matiz importante: aunque vosotros no hayáis instalado esas versiones, un proveedor, un subcontratista o una dependencia interna podría haberlo hecho.

Qué versión es segura y qué pasos deberían seguir los equipos

El punto de referencia es claro: la última versión considerada limpia es LiteLLM 1.82.6. Si alguien instaló 1.82.7 o 1.82.8, no basta con “bajar de versión”: hay que tratarlo como un incidente de seguridad completo. Que PyPI retire el paquete no desinfecta una máquina ya comprometida.

Las recomendaciones pasan por identificar todas las instalaciones de 1.82.7 y 1.82.8, volver a 1.82.6 y asumir que secretos críticos pudieron quedar expuestos. Eso implica revocar y regenerar credenciales (claves SSH, tokens cloud, accesos a Kubernetes, tokens de publicación y despliegue) y revisar logs de acceso en el periodo afectado, en entornos compartidos.

El episodio vuelve a poner sobre la mesa una realidad incómoda: tratar PyPI como “seguro por defecto” es un error. Una sola brecha en un pipeline puede permitir publicar malware bajo una identidad legítima. A medio plazo, la salida pasa por prácticas más estrictas: versiones fijadas, espejos internos, controles de integridad y vigilancia del tráfico saliente de runners. No es vistoso, pero evita que un simpleimporten Python se convierta en una fuga masiva.