Si tu pipeline de CI/CD usa Trivy — y estadísticamente hablando, probablemente sí — tenés que leer esto. Entre el 19 y el 23 de marzo de 2026, el grupo de amenazas TeamPCP comprometió el escáner de vulnerabilidades Trivy de Aqua Security, inyectando malware robador de credenciales en todos los canales de distribución oficiales al mismo tiempo. Esto es CVE-2026-33634, con un score CVSS de 9.4, y afectó a más de 10.000 workflows de CI/CD en todo el mundo.
Acá te explicamos qué pasó exactamente, cómo funcionó el ataque, y los pasos concretos que tenés que seguir ahora mismo.
Qué es Trivy y por qué esto importa
Trivy es el escáner de vulnerabilidades open source más adoptado en CI/CD cloud-native. Corre como GitHub Action en cada PR, cada merge, cada deployment — y corre con acceso a los secrets del pipeline por diseño. Eso es exactamente por qué fue el objetivo. Comprometer Trivy no le da al atacante solo tu código: le da tus credenciales de nube, tus claves SSH, tus tokens de Kubernetes, tu configuración de Docker, y todo lo demás que toca tu pipeline.
Cómo ocurrió el ataque
El ataque tuvo dos fases y explotó una sola causa raíz: rotación incompleta de credenciales de un incidente anterior.
Fase 1 — 19 de marzo de 2026: TeamPCP ingresó usando credenciales robadas durante una brecha anterior y separada de la infraestructura de Aqua Security que nunca se remedió completamente. Con esas credenciales:
- Forzaron commits maliciosos en 76 de 77 version tags de
aquasecurity/trivy-actiony en los 7 tags deaquasecurity/setup-trivy - Publicaron un binario envenenado como release oficial
v0.69.4en GitHub Releases, Docker Hub, GHCR, ECR Public yget.trivy.dev - Suplantaron la identidad de maintainers legítimos para que los commits parecieran auténticos
El payload inyectado corría antes del escaneo real de Trivy: recolectaba variables de entorno, barría el filesystem en busca de credenciales de nube e infraestructura, encriptaba los resultados y los exfiltraba a infraestructura controlada por el atacante. Después lanzaba el escaneo real de Trivy, que completaba con output normal. Los operadores no veían errores. Los pipelines parecían funcionar. El robo era invisible.
Fase 2 — 22 y 23 de marzo: Tres días después, usando credenciales de Docker Hub comprometidas por separado, TeamPCP subió nuevas imágenes maliciosas: 0.69.5, 0.69.6 y el tag latest — saltándose todos los controles basados en GitHub que se habían implementado. Esto extendió la exposición por aproximadamente 10 horas adicionales antes de que Docker cuarentenara las imágenes el 23 de marzo.
Expansión — 23 y 24 de marzo: Usando tokens robados de una cuenta bot (Argon-DevOps-Mgt) que conectaba dos organizaciones de GitHub de Aqua, TeamPCP desfiguró los 44 repositorios de la org interna aquasec-com de Aqua y expandió el ataque a Checkmarx KICS, LiteLLM (paquetes PyPI 1.82.7 y 1.82.8) y extensiones de VS Code en OpenVSX.
Versiones afectadas — la lista completa
Imágenes de Docker Hub:
aquasec/trivy:0.69.4,0.69.5,0.69.6,latest(durante el 19–23 de marzo)- Última versión limpia conocida:
aquasec/trivy:0.69.3
GitHub Actions:
aquasecurity/trivy-action— todos los tags excepto el commit SHA57a97c7(v0.35.0)aquasecurity/setup-trivy— todos los tags excepto el commit SHA3fb12ec(v0.2.6)
Binarios descargados:
v0.69.4desde GitHub Releases oget.trivy.dev
Atención: mirror.gcr.io puede estar sirviendo imágenes maliciosas cacheadas — siempre usá referencias con digest fijo.
Digests comprometidos a buscar:
sha256:27f446230c60bbf0b70e008db798bd4f33b7826f9f76f756606f5417100beef3sha256:425cd3e1a2846ac73944e891250377d2b03653e6f028833e30fc00c1abbc6d33
Checklist de respuesta inmediata
Paso 1 — Determinar si estuviste expuesto
Revisá tus logs de pipeline, tu image store local, y tus cachés de Artifactory o Nexus buscando los digests o tags mencionados arriba. Tu ventana de exposición es: cualquier ejecución de Trivy entre el 19 de marzo a las 18:24 UTC y el 23 de marzo a las 01:36 UTC usando los tags afectados.
Paso 2 — Rotar todo
Si algún escaneo de Trivy corrió una versión comprometida, tratá todos los secrets accesibles desde ese pipeline como comprometidos. Rotá inmediatamente:
- Tokens de GitHub y Personal Access Tokens
- Credenciales de proveedores de nube (AWS, GCP, Azure)
- Tokens de registros de Docker
- Claves SSH
- Tokens de Kubernetes
- Contraseñas de bases de datos accesibles desde el entorno de build
Caso especial: Si corriste la imagen comprometida con el socket de Docker montado (-v /var/run/docker.sock:/var/run/docker.sock), tratá el host completo como comprometido — ese mount otorga acceso a nivel root sobre el nodo.
Paso 3 — Pinear a versiones seguras
- Binario: usá
aquasec/trivy:0.69.3o esperá un nuevo release verificado de Aqua Security - GitHub Action: pineá a
aquasecurity/trivy-action@57a97c7(no@v0.35.0) - setup-trivy: pineá a
aquasecurity/setup-trivy@3fb12ec
De acá en adelante: siempre pineá tus GitHub Actions a commit SHAs, nunca a tags mutables. Este ataque demostró a escala que los version tags pueden ser redirigidos silenciosamente.
Paso 4 — Verificar exposición a LiteLLM y Checkmarx
Si tu stack usa LiteLLM, buscá el indicador de compromiso litellm_init.pth y rotá todos los secrets. Si usás Checkmarx KICS, verificá que no estés corriendo la GitHub Action comprometida del 23 de marzo.
La lección que nadie quiere aprender
Este ataque ocurrió porque la rotación incompleta de credenciales de un incidente anterior dejó una puerta abierta. TeamPCP no necesitó un zero-day. Entró por credenciales que deberían haberse revocado meses antes.
La lección técnica es clara: cuando rotás credenciales después de un incidente, la rotación tiene que ser atómica y completa. Un solo token válido que conectaba dos organizaciones fue suficiente para comprometer 44 repositorios y extender el ataque por días.
La lección más amplia: las herramientas que usás para asegurar tu pipeline son parte de tu superficie de ataque. Tu escáner de vulnerabilidades corre con privilegios elevados. Tu linter corre con privilegios elevados. Todo lo que está en tu cadena de build lo hace. Pinear a commit SHAs — no a tags mutables — ya no es higiene opcional: es el baseline mínimo.
Recursos
- Aviso de incidente de Docker: https://www.docker.com/blog/trivy-supply-chain-compromise-what-docker-hub-users-should-know/
- Análisis técnico completo de Wiz Research: Trivy Compromised by "TeamPCP" | Wiz Blog
- Guía de detección de Microsoft Defender: Guidance for detecting, investigating, and defending against the Trivy supply chain compromise | Microsoft Security Blog
- Playbooks de respuesta de Legit Security: The Trivy Supply Chain Compromise: What Happened and Playbooks to Respond
- GitHub Security Advisory: GHSA-69fq-xp46-6x23 | GHSA-cxm3-wv7p-598c
¿Tu equipo usa Trivy en producción? ¿Ya rotaron sus secrets o están usando algún método alternativo de verificación de dependencias? Contanos en los comentarios.