El compromiso de Trivy estaría detrás del ataque que expuso a más de 2.500 organizaciones

LiteLLM habría sido solo la fase más visible

El compromiso de la cadena de suministro de LiteLLM no habría comenzado en el propio proyecto. Según una reconstrucción de SOCRadar, la mayoría de las más de 2.500 organizaciones relacionadas con el incidente ya habían quedado expuestas anteriormente a través de Trivy, una herramienta de Aqua Security.

LiteLLM representaría, por tanto, el último paso de una campaña más amplia atribuida al grupo TeamPCP. Este actor ya ha sido vinculado a ataques contra proyectos de código abierto y al gusano Shai-Hulud.

La noticia fue detectada el 14 de agosto de 2026. Sin embargo, la estimación inicial de más de 2.500 organizaciones, difundida también por CloudSEK y HudsonRock, no equivale a un censo de compromisos confirmados. SOCRadar pudo reconstruir, mediante identificadores atribuibles, 2.188 entidades.

La diferencia se debe a la disponibilidad de datos útiles para vincular cada registro con una organización concreta. En la muestra analizada, el 56 % de los registros está clasificado con alta confianza, el 39 % con confianza media y el 6 % con baja confianza.

Las coincidencias más sólidas proceden de la identidad de los hosts de CI y de los dominios legítimos de los committers. Aun así, la exposición de una credencial no demuestra automáticamente que el atacante la haya utilizado.

El paso de Trivy a los registros de software

La campaña siguió un patrón con características similares a las de un gusano. El código malicioso se ejecutaba cuando se descargaba y utilizaba el paquete comprometido, y después buscaba credenciales, tokens, claves API y otros secretos presentes en el entorno.

Los datos recopilados podían permitir al actor acceder a otros repositorios o registros. Las credenciales de los desarrolladores se reutilizaban entonces para modificar paquetes al alcance del atacante y publicar versiones alteradas.

El primer punto observado en la cadena fue una build maliciosa de Trivy. La primera recopilación de datos se registró el 19 de marzo a las 18:05 UTC, apenas 18 minutos después de la publicación de la build comprometida.

La actividad aumentó el 22 y el 23 de marzo, cuando había imágenes maliciosas de Trivy disponibles en Docker Hub. En esta fase, el malware habría alcanzado numerosos entornos de desarrollo e integración continua, recopilando información de los sistemas utilizados para crear y distribuir software.

El 24 de marzo se publicaron dos versiones maliciosas de LiteLLM. No se hicieron públicos los números exactos de versión. Los paquetes permanecieron disponibles en PyPI durante unos 40 minutos antes de ser puestos en cuarentena.

Ese intervalo no representa toda la duración de la exposición. Para SOCRadar, fue solo la última fase de una campaña iniciada con el compromiso de Trivy. La última actividad detectada se remonta al 24 de marzo a las 20:09 UTC.

En el caso de 2.085 organizaciones, equivalentes al 95 % de las entidades analizadas, la recopilación de datos ya había terminado antes de la publicación de los paquetes de LiteLLM. Este elemento refuerza la hipótesis de que LiteLLM se utilizó como paso final o más visible, y no como origen de la operación.

Por qué el payload .pth eludió algunas defensas

Los paquetes modificados de LiteLLM contenían un archivo con extensión .pth. Python puede cargar y ejecutar automáticamente este tipo de archivo al iniciar el intérprete, incluso cuando la aplicación no importa directamente LiteLLM.

Este comportamiento amplía significativamente la superficie de ataque. Una organización podía instalar o iniciar el entorno comprometido sin invocar explícitamente el componente malicioso desde su código.

El mecanismo también permitía eludir las protecciones basadas en la opción ignore-scripts. Esta configuración puede impedir la ejecución de scripts durante la instalación de paquetes, pero no bloquea necesariamente la carga automática de un archivo .pth por parte del intérprete de Python.

La persistencia en los sistemas ya infectados constituye otro factor de riesgo. Incluso después de eliminar el paquete original, el payload podía seguir activo en el entorno comprometido.

Por ello, la cuarentena de los paquetes en PyPI interrumpió la actividad observada, pero por sí sola no permite descartar la presencia de componentes ya ejecutados ni de credenciales ya sustraídas.

CI/CD, cloud e identidades de desarrolladores en el punto de mira

La campaña afectó a seis plataformas de integración y distribución continuas:

• GitHub Actions;
• GitLab CI;
• Jenkins;
• Bitbucket;
• CircleCI;
• Buildkite.

La implicación de estos entornos es especialmente delicada. Las pipelines de CI/CD suelen disponer de permisos para leer código, crear artefactos, publicar paquetes y acceder a infraestructuras cloud.

Las organizaciones afectadas estaban distribuidas por todo el mundo. Alemania, Brasil y Francia fueron los países más representados en la reconstrucción.

Más de 1.000 organizaciones habrían expuesto tokens JWT y tokens de autenticación. Entre los demás datos identificados figuran claves privadas, claves de AWS, tokens de GitLab, claves API de OpenAI, webhooks de Slack, tokens de GitHub Actions y claves API de Google.

Además, en más de 1.100 organizaciones se habrían recopilado las direcciones de correo electrónico de los committers. Vincular las identidades de los desarrolladores con tokens utilizables por procesos automatizados puede facilitar ataques dirigidos, suplantaciones y nuevos accesos a los sistemas de desarrollo.

Algunos registros muestran una cantidad excepcional de secretos: el más grande contendría unos 3.477, mientras que otro incluiría aproximadamente 3.459 distribuidos en apenas seis archivos. No se han identificado las organizaciones relacionadas con estos casos.

Los datos ya estarían disponibles en el mercado criminal

Los secretos sustraídos no se habrían quedado únicamente en los sistemas del atacante. Un actor está promocionando en Telegram una recopilación que incluiría datos atribuidos a LiteLLM, Trivy y CanisterWorm.

No se sabe si todo el material procede del mismo momento de la campaña. La recopilación podría haberse reunido en distintas fases, pero su disponibilidad aumenta igualmente el riesgo operativo para las organizaciones expuestas.

Los tokens de CI/CD, las claves cloud y las credenciales de los desarrolladores pueden utilizarse para acceder a repositorios, modificar pipelines, publicar nuevos paquetes maliciosos o alcanzar servicios externos. Las claves API también pueden generar costes, permitir el acceso a datos o emplearse en actividades automatizadas.

La combinación de propagación automática y reutilización de credenciales explica por qué el incidente no debe considerarse limitado a LiteLLM. Un único paquete comprometido puede convertirse en la puerta de entrada a una red de proyectos, pipelines y registros de software.

Qué deben comprobar las organizaciones expuestas

La única medida de contención documentada es la cuarentena de los paquetes maliciosos de LiteLLM por parte de PyPI. No se han dado a conocer parches específicos, versiones corregidas, procedimientos oficiales de limpieza ni una lista completa de indicadores técnicos.

Las organizaciones que hayan utilizado Trivy o LiteLLM en los entornos afectados deberían revisar las pipelines de CI/CD, los repositorios y la presencia de archivos .pth inesperados. También deben considerar potencialmente comprometidos los secretos identificados hasta completar una validación independiente.

Eliminar el paquete no basta para descartar la persistencia. También es necesario revisar los hosts donde pudiera haberse ejecutado el código y analizar posibles publicaciones, modificaciones de repositorios o accesos anómalos posteriores.

El informe no incluye instrucciones oficiales de los proveedores para la remediación ni confirma si la vulnerabilidad o la campaña se incorporaron al catálogo KEV de la CISA. Por tanto, no hay disponible una fecha de incorporación al catálogo ni un plazo de la CISA que deba cumplirse.

La prioridad operativa sigue siendo revocar y sustituir las credenciales potencialmente expuestas, además de revisar los permisos de las pipelines. Ante la falta de confirmación completa sobre el uso de los secretos, la opción prudente es tratarlos como comprometidos.