Trivy Comprometido: Ataque Supply Chain Roba Credenciales

El 19 de marzo de 2026, a las 17:43 UTC, un grupo llamado TeamPCP comprometió el pipeline CI/CD de Aqua Security e inyectó un malware infostealer en las imágenes Docker de Trivy. Entre el 19 y el 23 de marzo, quienes descargaron las versiones 0.69.4, 0.69.5, 0.69.6 o la tag ‘latest’ expusieron credenciales cloud, claves SSH, secretos de CI/CD y tokens de autenticación. El ataque se propagó también a LiteLLM en PyPI y Checkmarx KICS. CVE-2026-33634 CVSS 9.4.

Aqua Security es una empresa de seguridad especializada en protección de aplicaciones y contenedores cloud-native, que desarrolla y mantiene herramientas de código abierto como Trivy para escanear vulnerabilidades en imágenes Docker y artefactos de contenedores.

Qué pasó: el ataque supply chain a Trivy en 48 horas

Trivy es el scanner de vulnerabilidades más usado en entornos cloud-native. Si trabajás con Kubernetes, contenedores o pipelines de CI/CD, probablemente lo tengas instalado o lo uses sin siquiera darte cuenta. Es open source, auditable, y la mayoría confiamos en él. Eso es exactamente lo que hizo jugoso el target para TeamPCP.

El 19 de marzo a las 17:43 UTC, el atacante ganó acceso al pipeline CI/CD de Aqua Security. La razón: una rotación incompleta de credenciales el 1 de marzo después de un incidente de seguridad anterior (descubierto en febrero). Acceso residual. La lección obvia: si rotás credenciales, tiene que ser atómica y total, no parcial.

Con acceso, TeamPCP usó la cuenta de servicio ‘aqua-bot’ para forzar push de 76 de 77 tags en trivy-action y todos los tags de setup-trivy. Commits impostores suplantando a usuarios legítimos como ‘rauchg’ y ‘DmitriyLewen’. La remediación llegó a las ~21:22 UTC (poco más de 3 horas después), pero para el 22 de marzo vinieron dos nuevas olas de releases maliciosos en Docker Hub: v0.69.5, v0.69.6 y la tag ‘latest’.

La cadena de compromiso: cómo un atacante vuelve a entrar

Acá viene lo interesante de un punto de vista defensivo. No fue un exploit zero-day en Trivy, ni un ataque sofisticado dirigido a la herramienta misma. Fue un fallo de operaciones: gestión deficiente de credenciales.

Febrero de 2026: Aqua detecta un incidente. Alguien tuvo acceso no autorizado a la infraestructura. Comienzan a remediar. Pero el 1 de marzo, cuando hacen la rotación de credenciales (tokens, claves de acceso, PATs de GitHub), no la hacen de forma completa. Algunos secrets quedan sin rotar. El atacante mantiene acceso residual con esas credenciales antiguas que sobrevivieron a la “rotación”. Lo explicamos a fondo en evitar brechas en la cadena de suministro.

Saltemos a marzo 19. TeamPCP está dentro. Tienen la cuenta ‘aqua-bot’ — un service account con permisos para pushear a los repositorios centrales. Lo que hicieron fue sencillo pero devastador: modificar los Dockerfiles, inyectar código malicioso en la build, y hacer push. El CI/CD ejecuta, construye las imágenes con el payload incluido, y las publica en Docker Hub con las tags oficiales. La gente las descarga pensando que están verificadas.

Anatomía del infostealer: qué hace exactamente el malware

El payload es un script Python en base64 que corre cuando Trivy se ejecuta en un pipeline de GitHub Actions. Escanea /proc/*/environ buscando variables de entorno con secrets.

Acá viene la parte que me molesta: el malware cosecha secretos que GitHub promete “enmascarar” en los logs. Los que están marcados como ‘isSecret: true’. GitHub dice que los oculta, pero si el proceso tiene acceso a la memoria del Runner.Worker, los ve igual. No es un bug de Trivy específicamente; es un architectural weakness de cómo GitHub maneja los secrets en el memory space del runner. El payload lee ~50 rutas diferentes: tokens AWS (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), GCP (GOOGLE_APPLICATION_CREDENTIALS), Azure (AZURE_SUBSCRIPTION_ID), kubeconfigs en ~/.kube/config, Docker credentials en ~/.docker/config.json, SSH keys en ~/.ssh/, wallets de criptomonedas, GPG keys, Slack tokens, Twitter API keys.

Los datos se cifran con AES-256-CBC para transportación y RSA-4096 para la clave simétrica. Se exfiltran a un C2 en scan[.]aquasecurtiy[.]org (un typosquat deliberado de ‘aquasecurity’, IP 45.148.10.212 en Amsterdam). Hay un fallback: si el C2 está caído o bloqueado, pushea todo a repos públicos en GitHub llamados ‘tpcp-docs’. Así garantiza exfiltración aunque intentes bloquear la salida.

Tabla de versiones afectadas y ventana de exposición

Importante: 0.69.5 y 0.69.6 no son parches de seguridad. Son releases adicionales maliciosos publicados después de la primera remediación. Si seguís viendo nuevas versiones sin anuncio oficial, eso es una bandera roja.

La expansión: LiteLLM, KICS, y 44 repos defaceados

Con las credenciales que robó, TeamPCP no se quedó en Trivy. Pivotó a otros proyectos dentro de la organización de Aqua. En cómo proteger tus credenciales CI/CD profundizamos sobre esto.

LiteLLM, una librería Python popular para llamadas a APIs de LLMs (GPT, Claude, Gemini), fue comprometida en las versiones 1.82.7 y 1.82.8 en PyPI. Checkmarx KICS, otro scanner de IaC ampliamente usado, también cayó. Dentro del org ‘aquasec-com’ en GitHub, el grupo defaceó 44 repositorios — no se sabe si infectó otros o solo marcó territorio. Según SecurityWeek, el ataque se propagó también a extensiones de VS Code.

El patrón: una vez adentro, el atacante pivota horizontalmente usando las credenciales de servicio. Es el clásico lateral movement. Por eso la recomendación de limitar permisos de service accounts es tan crítica (principio de menor privilegio). Aqua-bot tenía demasiado acceso.

Indicadores de compromiso para tu equipo de seguridad

Si trabajás en SOC o tienes un equipo de seguridad interno, estos son los IOCs concretos para detectar si tu infraestructura fue impactada:

• Dominio C2: scan[.]aquasecurtiy[.]org, resuelto a IP 45.148.10.212 (Amsterdam)
• Commits maliciosos conocidos: 1885610c, 70379aad, 8afa9b9f9183b4e00c46e2b82d34047e3c177bd0
• Repos públicos sospechosos: Buscar en tu GitHub cualquier repo llamado ‘tpcp-docs’ en la organización o asociado a service accounts
• Bandera de commit: Si ves commits que digan “This commit does not belong to any branch on this repository” en las branches de Trivy, eso es exposición de commits fantasma
• Hashes de binarios: Los reportes detallados de Wiz y Legit Security incluyen hashes SHA-256 por arquitectura (ARM64, x86_64). Comparalos contra lo que descargaste
• Logs de GitHub Actions: Si corriste Trivy entre el 19-23 de marzo en actions, reviá los logs de ese período. Buscá ejecuciones de /proc/*/environ o procesos inesperados

Plan de respuesta inmediata: qué rotar y cómo endurecer

El orden importa. No es “rotar un poco”. Es rotar TODO.

Paso 1: Identificación. Hacé un audit rápido: ¿corría Trivy en tu CI/CD entre el 19-23 de marzo? ¿En qué pipelines, repositorios, con qué secrets expuestos a esos pipelines? Si la respuesta es sí, asumí que esos secrets fueron comprometidos. Punto.

Paso 2: Rotación de secrets. Esto tiene que ser inmediato y total. GitHub PATs (Personal Access Tokens), tokens de cloud (AWS, GCP, Azure), SSH keys en ~/.ssh/, kubeconfigs, credenciales Docker Hub, Slack tokens, Twitter API keys si el código los usa. TODO. Si decís “vamos a rotar solo lo importante”, lo importante es que no sepas qué es importante en el momento del ataque, así que rotá todo y que después se quejen si algo se rompe.

Paso 3: Endurecer el CI/CD. A partir de ahora, pinea GitHub Actions a SHA completo, no a tags. `uses: actions/checkout@abc123def456` en vez de `uses: actions/checkout@v4`. Los tags se pueden mover, los SHAs no. Lo mismo para las actions de Trivy: pinea a SHA. Implementá branch protection rules en los repos críticos. Requiere peer review para cambios en .github/workflows/. Complementá con otros ataques supply chain de 2026.

Paso 4: DNS y firewall. Bloqueá el C2 en tu firewall y DNS. scan[.]aquasecurtiy[.]org, IP 45.148.10.212. Aunque el malware ya pasó, no querés comunicaciones futuras hacia allá.

Paso 5: Auditoría de secondary compromise. Con esas credenciales robadas, ¿qué más hizo el atacante? Reviá logs de AWS CloudTrail, GCP Cloud Logging, Azure Activity Log, Kubernetes audit logs, Docker registries. Si alguien creó infraestructura sospechosa, deployó código extra, o movió datos, ese es el siguiente layer de investigación.

Paso 6: Machine identity governance. Como mencionó GitGuardian, el problema de fondo es que service accounts de larga vida como ‘aqua-bot’ tienen poder perpetuo. Implementá rotating credentials (temporary tokens), short-lived certificates, o workload identity federation donde sea posible. En AWS, usa IRSA. En GCP, usa Workload Identity. En Kubernetes, usa ServiceAccount tokens de corta vida.

El equipo de Legit Security publicó playbooks open source en GitHub (legitsecurity/trivy-supply-chain-attack) con scripts para detectar exposición y remediar. Si no tenés recursos internos, empezá por ahí.

Qué está confirmado, qué no

• Confirmado: El attack chain involucró rotación incompleta de credenciales en febrero/marzo. TeamPCP tuvo acceso residual. Forzó push malicioso. CVE-2026-33634 CVSS 9.4 es oficial.
• Confirmado: El payload exfiltró secrets de GitHub Actions. Los datos se cifraron AES-256-CBC y RSA-4096. C2 en Amsterdam.
• Confirmado: Secondary compromise a LiteLLM, KICS, y 44 repos defaceados en aquasec-com org.
• Pendiente verificación: Si hay máquinas en el wild ejecutando malware residual post-imagen. Los container images son el vector principal, pero no sabemos si TeamPCP dejó persistencia en infraestructura de Aqua.
• Pendiente: Lista completa de compromised GitHub Actions workflows más allá de trivy-action y setup-trivy.

Errores comunes que ves después de este tipo de ataques

Error 1: “Nuestras imágenes estaban pinned a un tag específico, así que no fuimos impactados.” Falso. Si pinned a ‘v0.69.4’ en un Dockerfile, y ese tag cambió (force push), tu próxima build pesca la nueva. Tags se pueden mover. SHAs no. Resultado: estabas vulnerable sin saberlo.

Error 2: Rotar solo las credenciales “más críticas”. ¿Cuáles son las críticas? SSH keys parecen importantes. Pero si el atacante está dentro, ve TODO en el memory space. No hay “un poquito comprometido”. Está comprometido todo lo que fue expuesto a ese proceso. Sobre eso hablamos en mantener actualizadas tus dependencias.

Error 3: “No usamos Trivy en CI/CD, solo lo corremos localmente en developer laptops.” Ojo: si lo corrés en un laptop que tiene SSH keys, kubeconfigs, o tokens de AWS en ~/.aws/, el malware te los roba igual. El impacto es el mismo. La máquina es el playground del atacante.

Qué significa para empresas y equipos en Latinoamérica

Acá en Latinoamérica, muchos equipos usan Trivy pero no tienen procesos formales de credential rotation. “Rotamos cuando nos acordamos” es lo que escucho. Este ataque es un wake-up call. Si usás GitHub Actions, AWS, GCP o cualquier infraestructura cloud (y la mayoría ya lo hacemos), y corrés scanning tools en tus pipelines, estás exponiendo secrets de terceros a esos tools.

La recomendación no es dejar de usar Trivy. Es un scanner excelente. Es cambiar cómo lo usás: pinea a SHAs, implementá secret scanning post-mortem con herramientas como GitGuardian o TruffleHog, y rotá credenciales no “cuando querés”, sino con SLA: cada 90 días mínimo, inmediatamente después de un incidente. Si tenés infraestructura en donweb.com o usás su hosting, aún más: revisá si tus deployed applications en VPS o containers están usando librerías comprometidas de PyPI o NPM. Auditoría de dependencias, ahora.

Esto se conecta con Ataque supply chain compromete Trivy y roba credenciales CI/, donde analizamos ataques de supply chain en profundidad.

Esto conecta directamente con Ataque supply chain compromete Trivy y roba credenciales CI/, donde profundizamos en el tema.

Si querés profundizar en ataques a la cadena de suministro, mirá nuestro análisis: Ataque supply chain compromete Trivy y roba credenciales CI/.

Esto se conecta con Ataque supply chain compromete Trivy y roba credenciales CI/, un incidente reciente en la cadena de suministro.

Preguntas Frecuentes

¿Qué versiones de Trivy están afectadas por el ataque supply chain 2026?

La versión 0.69.4 en la primera ola (3 horas, 17:43 a 21:22 UTC el 19 de marzo). Las versiones 0.69.5, 0.69.6 y ‘latest’ en la segunda ola del 22 de marzo (~10 horas). Para GitHub Actions, trivy-action v0.0.1 a v0.34.2. Para setup-trivy, todos los releases hasta v0.2.6. Las versiones 0.69.3 y anteriores están seguras. Para cualquier componente, actualizar a los releases posteriores a marzo 23 es seguro.

¿Cómo sé si mis credenciales cloud fueron robadas por el infostealer?

Si corriste Trivy en un pipeline de GitHub Actions o en una máquina que tiene tokens en variables de entorno entre el 19-23 de marzo, asumí que fueron expuestas. No hay forma de saber con certeza post-ataque. Rotar es obligatorio. Reviá CloudTrail (AWS), Cloud Logging (GCP), Activity Log (Azure), y Docker Hub audit logs. Si ves acciones que no autorizaste (creación de infraestructura, cambios en permisos, deployments sospechosos), ese es tu evidence de lateral movement.

¿Qué pasa si usé Trivy en producción sin exponerlo a secrets?

El malware corre igual. No hace nada si no hay secrets que robar, pero estás ejecutando código comprometido. Es un vector de persistencia potencial. Lo seguro es updatear a versión post-compromise y auditar para activity sospechosa. El scanner en sí no se quiebra, solo está contaminado.

¿Cuánto tiempo pasó entre el primer push malicioso y la detección?

Poco menos de 4 horas para la primera ola (17:43 a ~21:22 UTC). Pero el changelog y tags se movieron, así que la ventana de “tiempo en que gente descargó el malware sin saberlo” fue mayor. Docker Hub probablemente tiene datos de descargas por timestamp. Aqua Security y Docker están auditando eso.

Conclusión

El ataque a Trivy no es un fallo de la herramienta misma. Es un fallo de operaciones: credenciales no rotadas completamente, service accounts con demasiados permisos, sin auditoría de commits por suplantación. Son todos problemas solubles con procesos y tooling.

La lección es que confiar en una herramienta abierta no significa confiar en su cadena de suministro. Los binarios que descargás pueden venir envenenados, incluso de fuentes oficiales, si el pipeline del publisher fue comprometido. Pinea a SHAs. Rotar secrets con SLA. Implementá secret scanning. Audit logs religiosamente.

Si usás Trivy (y casi todos lo hacemos), esto no es “una noticia más”. Es una señal de que tenés que revisar cómo exponés secrets a tus herramientas. Hoy.

Fuentes

• Aqua Security – Trivy Supply Chain Attack: What You Need To Know
• GitHub Security Advisory GHSA-69fq-xp46-6×23
• Arctic Wolf – TeamPCP Supply Chain Attack Campaign
• Legit Security – Trivy Supply Chain Compromise: Playbooks to Respond
• GitGuardian – Trivy’s March Supply Chain Attack: Where Secret Exposure Hurts Most