Hackearon Trivy en GitHub Actions: 75 Tags Secuestrados

Trivy GitHub Actions fue hackeado en marzo de 2026: un atacante secuestró 75 de los 76 tags del repositorio aquasecurity/trivy-action mediante force-push, inyectando un infostealer que robaba credenciales cloud, SSH keys y tokens de más de 10.000 workflows de CI/CD en GitHub. Es el segundo compromiso del escáner de seguridad en menos de un mes.

Trivy es el escáner de vulnerabilidades open source más popular del ecosistema cloud-native, con más de 32.000 estrellas en GitHub y un estimado de 100 millones de descargas anuales. Lo mantiene Aqua Security y se usa masivamente en pipelines de CI/CD a través de su GitHub Action oficial (aquasecurity/trivy-action). Que una herramienta diseñada para encontrar vulnerabilidades se convierta en el vector de ataque es, como mínimo, irónico. Y preocupante.

Qué pasó: 75 tags de Trivy secuestrados en GitHub Actions

El incidente se detectó en la segunda semana de marzo de 2026. Un atacante logró acceso al repositorio aquasecurity/trivy-action y ejecutó un force-push sobre 75 de los 76 tags existentes, según reportó The Hacker News. Cada tag fue redirigido a un commit que contenía código malicioso: un infostealer que se ejecutaba antes del escáner legítimo.

El repositorio setup-trivy también fue comprometido. Lo grave es que más de 10.000 workflows en GitHub referencian trivy-action directamente, y la enorme mayoría lo hace por tag (por ejemplo, uses: aquasecurity/trivy-action@v0.69.0) en lugar de por commit SHA. Eso significa que cuando el tag fue re-apuntado al commit malicioso, todos esos workflows empezaron a ejecutar el payload sin que nadie lo notara.

Este es el segundo compromiso de Trivy en menos de un mes. Según StepSecurity, la primera vez el ataque involucró una release maliciosa (v0.69.4). La segunda fue más sofisticada: no tocó las releases, solo los tags. Para el usuario final, la página de releases en GitHub se veía exactamente igual. El cambio era invisible.

Cómo funcionó el ataque: de escáner a ladrón de secretos

La mecánica técnica del ataque explota una característica fundamental de Git: los tags son punteros mutables. A diferencia de un commit SHA (que es un hash criptográfico del contenido y, por lo tanto, inmutable), un tag como v1.0.0 puede ser redirigido a cualquier otro commit en cualquier momento. Si alguien con permisos de escritura hace un git tag -f v1.0.0 seguido de un git push --force --tags, el tag ahora apunta a otro lugar. Y no queda rastro visible en la interfaz web de GitHub.

El payload inyectado era elegante en su simplicidad. Se ejecutaba como paso previo al escáner legítimo de Trivy, así que el workflow seguía funcionando normalmente después. El usuario veía su escaneo de vulnerabilidades completarse sin errores. Mientras tanto, el código malicioso hacía lo siguiente:

• Volcaba la memoria del runner de GitHub Actions, buscando secretos cargados como variables de entorno
• Recolectaba SSH keys almacenadas en el agente SSH del runner
• Extraía credenciales de AWS, GCP y Azure (tokens de sesión, access keys, service account JSON)
• Buscaba tokens de Kubernetes (KUBECONFIG, tokens de servicio montados)
• Recopilaba credenciales de Docker Hub y registries privados
• Cifraba todo el paquete y lo enviaba a scan.aquasecurtiy[.]org

Fijate en el dominio de exfiltración: aquasecurtiy en vez de aquasecurity. Un typosquatting sutil que, en logs de red, pasa desapercibido si no sabés exactamente qué buscar. El dominio fue registrado días antes del ataque y usaba HTTPS con un certificado válido de Let’s Encrypt, así que ni los filtros de SSL lo detectaban como sospechoso.

hackerbot-claw: el bot de IA que inició todo

El origen de la cadena de ataque es inquietante. Según el análisis de StepSecurity, todo empezó con un agente autónomo llamado hackerbot-claw. La cuenta fue creada en GitHub el 20 de febrero de 2026 y operaba como un bot automatizado que escaneaba repositorios públicos en busca de workflows con configuraciones vulnerables.

El vector específico que explotaba era pull_request_target con permisos excesivos. Este trigger de GitHub Actions es particularmente peligroso porque ejecuta el workflow en el contexto del repositorio base (no del fork), lo que le da acceso a los secretos del repositorio. Si el workflow además tiene permissions: write-all o no restringe permisos, un PR desde un fork puede ejecutar código arbitrario con acceso total a los secretos.

hackerbot-claw no solo apuntó a Trivy. Según los reportes, también intentó explotar workflows mal configurados en repositorios de Microsoft, DataDog y proyectos de la CNCF (Cloud Native Computing Foundation). En el caso de Aqua Security, el bot logró extraer un Personal Access Token (PAT) con permisos de escritura sobre los repositorios de la organización. Con ese PAT, el atacante humano (o el propio bot) pudo hacer force-push de los tags maliciosos.

Lo que me parece más relevante de todo esto: hackerbot-claw no necesitó explotar ninguna vulnerabilidad zero-day. Solo aprovechó configuraciones inseguras que son extremadamente comunes. No hackeó nada; entró por la puerta que estaba abierta.

El impacto: qué secretos fueron expuestos y quiénes están en riesgo

El blast radius de este ataque es considerable. Con más de 10.000 workflows que referencian trivy-action, la cantidad de secretos potencialmente comprometidos es masiva. No todos fueron afectados (solo los que ejecutaron el workflow durante la ventana de compromiso y usaban tags en lugar de SHA), pero el riesgo es real para cualquier organización que no haya tomado acción.

Los datos robados incluyen, según el análisis de CrowdStrike:

• Credenciales cloud: access keys de AWS, service account keys de GCP, client secrets de Azure. Estas credenciales pueden dar acceso completo a infraestructura de producción
• SSH keys: usadas para deploy a servidores, acceso a repos privados y comunicación entre servicios
• Tokens de Docker: acceso a Docker Hub y registries privados, lo que habilita la publicación de imágenes maliciosas
• Tokens de Kubernetes: acceso a clusters de producción, posibilidad de deploy de containers maliciosos
• Passwords de bases de datos: credenciales de conexión a PostgreSQL, MySQL, MongoDB almacenadas como secretos del workflow
• API tokens varios: tokens de Slack, Datadog, Sentry, Terraform Cloud, y cualquier otro servicio configurado como secreto en GitHub Actions

Para ponerlo en perspectiva con un ejemplo concreto: imaginá una empresa que usa trivy-action para escanear sus imágenes Docker antes de hacer deploy a un cluster de Kubernetes en AWS. Ese workflow típicamente tiene acceso al registry de Docker (para pull), a las credenciales de AWS (para autenticarse en ECR y EKS), y a tokens de Kubernetes (para deploy). Un solo workflow comprometido puede dar acceso a la infraestructura completa de producción.

Por qué los tags de GitHub Actions son un vector de ataque

Este no es un problema nuevo ni exclusivo de Trivy. Es un problema sistémico de cómo GitHub Actions maneja las referencias a actions de terceros. La convención de la industria es usar tags semánticos: uses: actions/checkout@v4. Es legible, es cómodo, y es peligrosamente inseguro.

Un tag en Git es solo un puntero con nombre. Podés pensar en v4 como un alias de un commit SHA específico. Pero, a diferencia del SHA (que es inmutable porque se genera a partir del contenido), el tag puede ser movido a cualquier otro commit por alguien con permisos de escritura. Y GitHub no notifica a nadie cuando esto pasa. No hay log público de cambios de tags. No hay diff visible. El tag v4 simplemente empieza a apuntar a otro lugar.

El precedente más directo es el ataque a tj-actions/changed-files en marzo de 2025, que afectó a más de 23.000 repositorios con una mecánica prácticamente idéntica. Un año después, la industria sigue sin adoptar SHA pinning como estándar. La documentación oficial de GitHub lo recomienda, pero la enorme mayoría de los tutoriales, ejemplos y templates siguen usando tags.

El problema de fondo es que GitHub Actions delegó la responsabilidad de seguridad al usuario final. No existe un mecanismo nativo de firma de tags, ni alertas cuando un tag es re-apuntado, ni un sistema de verificación de integridad. Es como si npm permitiera a un autor republicar un paquete con el mismo número de versión pero contenido diferente.

Remediación inmediata: qué hacer si usás Trivy en tu CI/CD

Si tu organización usa trivy-action en cualquier workflow, estos son los pasos concretos que tenés que seguir ahora mismo:

1. Dejá de usar trivy-action por tag. Cualquier referencia del tipo @v0.69.0, @v0.68.0, @latest o cualquier tag semántico debe ser reemplazada inmediatamente. No importa si Aqua Security ya restauró los tags originales — el riesgo de que vuelva a pasar existe.

2. Pineá al commit SHA seguro. La versión verificada como limpia es el SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1, que corresponde a la versión 0.35.0 según la verificación de la comunidad. Tu workflow debería quedar así:

uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0

3. Rotá TODOS los secretos accesibles desde el workflow. No solo los que «creés» que fueron expuestos. Todos. Esto incluye: access keys de AWS (generá nuevas y desactivá las anteriores), service account keys de GCP, client secrets de Azure, SSH keys, tokens de Docker Hub, passwords de bases de datos, API tokens de servicios externos. Sí, es un trabajo enorme. Pero un atacante con tus credenciales de producción es peor.

4. Auditá los logs de GitHub Actions. Revisá las ejecuciones del workflow durante la ventana de compromiso. Buscá conexiones salientes a dominios que no sean los habituales, especialmente cualquier variación de aquasecurity.com. GitHub retiene logs de workflow por 90 días.

Cómo proteger tus workflows: pinning de SHA y mejores prácticas

El pinning de SHA es la medida más efectiva, pero no es la única. Acá va una guía práctica para blindar tus workflows de GitHub Actions contra ataques de supply chain:

Pinning de SHA en todas las actions

Cada action de terceros en tus workflows debe referenciarse por commit SHA completo, no por tag. Esto aplica a todas las actions, no solo a trivy-action. Un ejemplo práctico: si antes tenías un workflow así:

uses: actions/checkout@v4
uses: aquasecurity/trivy-action@v0.69.0

Debería quedar así:

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0

El comentario con el tag es opcional pero útil para saber qué versión estás usando sin tener que buscar el SHA. Herramientas como pin-github-action automatizan esta conversión en proyectos grandes.

OIDC en vez de credenciales estáticas

Para acceso a servicios cloud, usá OpenID Connect en vez de access keys estáticas. AWS, GCP y Azure soportan OIDC con GitHub Actions de forma nativa. En lugar de guardar un AWS_ACCESS_KEY_ID como secreto (que es exactamente lo que el infostealer robaba), configurás un rol de IAM que solo puede ser asumido por tu workflow específico. Aunque el runner se comprometa, no hay credenciales estáticas que robar.

Principio de menor privilegio

Cada workflow debería declarar explícitamente sus permisos con la directiva permissions. Nunca dejés el default (que en muchos repos es write-all). Y nunca, bajo ninguna circunstancia, uses pull_request_target con permisos de escritura abiertos. Eso es exactamente lo que hackerbot-claw explotó para robar el PAT de Trivy. También podés encontrar más noticias tech relacionadas en el incidente de Trivy en GitHub Actions.

Herramientas de monitoreo

StepSecurity ofrece Harden-Runner, un agente que monitorea las conexiones de red de cada step en tu workflow y puede bloquear exfiltración a dominios no autorizados. No es la única opción, pero es la que más tracción ganó después de estos incidentes. Socket.dev y Snyk también lanzaron herramientas de auditoría de supply chain para GitHub Actions.

Lecciones para WordPress: los ataques supply chain no son solo de npm

Si administrás sitios WordPress y pensás que esto no te afecta, reconsideralo. Cada vez más desarrolladores y agencias de WordPress usan GitHub Actions para automatizar deploys: push a main, se ejecuta el workflow, se despliega en el servidor de producción. Si ese workflow usa trivy-action (o cualquier action comprometida), las credenciales de deploy (SSH keys al servidor, FTP passwords, tokens de WP CLI) quedan expuestas. También podés encontrar más noticias tech relacionadas en malware distribuido a través de repositorios GitHub.

El paralelismo con el ecosistema WordPress es directo. Los plugins de WordPress se actualizan automáticamente desde el repositorio oficial. Si un atacante compromete la cuenta de un desarrollador de un plugin popular (como pasó con plugins que tenían millones de instalaciones activas), la actualización maliciosa se distribuye automáticamente a todos los sitios que tengan activada la actualización automática. Es el mismo principio: confiás en un canal de distribución, y ese canal se convierte en el vector de ataque.

La lección es clara: ni siquiera las herramientas de seguridad son inmunes. Trivy tiene 32.000 estrellas y es mantenido por Aqua Security, una empresa de seguridad cloud con cientos de empleados. Si un escáner de vulnerabilidades con ese respaldo fue comprometido dos veces en un mes, ninguna herramienta es infalible. Verificá la integridad de lo que ejecutás, aunque sea un escáner de seguridad. Si hacés deploy de WordPress desde un pipeline de CI/CD, tu workflow necesita las mismas protecciones que cualquier otro: SHA pinning, secretos rotados y permisos mínimos. Y si usás hosting compartido para tus sitios WordPress en producción, asegurate de que el proveedor tenga medidas de aislamiento sólidas — Donweb, por ejemplo, ofrece planes con aislamiento de cuentas que limitan el blast radius si un sitio se compromete.

Qué está confirmado / Qué todavía no está confirmado

Confirmado

• 75 de 76 tags de aquasecurity/trivy-action fueron modificados mediante force-push para apuntar a commits maliciosos
• El repositorio setup-trivy también fue comprometido
• Es el segundo incidente en menos de un mes (el primero involucró una release maliciosa v0.69.4)
• El payload exfiltraba datos a scan.aquasecurtiy[.]org (dominio typosquatting)
• El bot hackerbot-claw fue creado el 20 de febrero de 2026 y explotó workflows con pull_request_target
• Más de 10.000 workflows en GitHub referencian trivy-action
• Aqua Security confirmó el compromiso y publicó indicadores de compromiso

Todavía no está confirmado

• La cantidad exacta de workflows que ejecutaron la versión maliciosa durante la ventana de compromiso — GitHub no publicó datos de telemetría
• Si los datos exfiltrados ya fueron utilizados en ataques secundarios (acceso a infraestructura cloud con las credenciales robadas)
• La identidad del operador humano detrás de hackerbot-claw
• Si hay otros repositorios de GitHub Actions comprometidos que aún no fueron detectados
• El alcance total del impacto en organizaciones de Microsoft, DataDog y CNCF que también fueron targets de hackerbot-claw

Errores comunes

«Solo uso trivy-action para escanear, no tiene acceso a mis secretos». Incorrecto. Cualquier step en un workflow de GitHub Actions tiene acceso a todos los secretos montados en ese job. Si tu job tiene env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }} y trivy-action corre en el mismo job, el payload puede leer esa variable de entorno. La separación de secretos es a nivel de job, no de step.

«Ya actualizaron los tags, así que estoy seguro si uso la última versión». El hecho de que Aqua Security haya restaurado los tags originales no elimina el riesgo. Los tags siguen siendo mutables. Si el atacante recupera acceso (o si un nuevo atacante obtiene permisos), puede volver a hacer force-push. La única forma segura es pinear por SHA. Punto.

«Mi CI/CD es privado, así que no me afecta». El repositorio de trivy-action es público, y tu workflow lo referencia desde el ecosystem público de GitHub Actions. Que tu repo sea privado no cambia nada: cuando el runner descarga la action, usa el tag público. Si ese tag apunta a código malicioso, tu runner privado ejecuta código malicioso. La privacidad de tu repositorio no te protege de supply chain attacks en dependencies públicas.

Preguntas Frecuentes

¿Qué pasó con Trivy y GitHub Actions en marzo de 2026?

Un atacante secuestró 75 de los 76 tags del repositorio aquasecurity/trivy-action mediante force-push, inyectando un infostealer que robaba credenciales cloud, SSH keys y tokens de CI/CD. Fue el segundo compromiso de Trivy en menos de un mes, afectando potencialmente a más de 10.000 workflows en GitHub.

¿Cómo saber si mi pipeline fue afectado por el ataque a trivy-action?

Revisá los logs de GitHub Actions de tus workflows que usen trivy-action durante la ventana de compromiso (primera y segunda semana de marzo de 2026). Buscá conexiones salientes a scan.aquasecurtiy[.]org o cualquier dominio sospechoso. Si usabas trivy-action referenciado por tag (no por SHA), asumí que tus secretos fueron expuestos y rotalos.

¿Qué es el tag hijacking en GitHub Actions y cómo se previene?

El tag hijacking es cuando un atacante con acceso de escritura a un repositorio hace force-push de un tag existente para que apunte a un commit diferente (malicioso). Se previene usando SHA pinning: en vez de uses: action@v1, usás uses: action@abc123def456... con el hash completo del commit verificado. Los SHA son inmutables y no pueden ser redirigidos.

¿Cómo hago pinning de SHA en GitHub Actions para evitar ataques supply chain?

Identificá el commit SHA exacto de la versión que querés usar (podés verlo en la página de releases del repositorio). Reemplazá la referencia por tag con el SHA completo: uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1. Agregá un comentario con el tag para legibilidad: # v0.35.0. Herramientas como pin-github-action automatizan este proceso para todos los workflows de un proyecto.

Conclusión

El compromiso de Trivy GitHub Actions dejó algo en evidencia que la industria prefiere ignorar: la infraestructura de CI/CD está construida sobre confianza implícita en terceros, y esa confianza es un vector de ataque. Un escáner de seguridad con 32.000 estrellas y respaldo empresarial fue comprometido dos veces en un mes. Si eso no es una señal para cambiar prácticas, no sé qué lo es.

Lo que cambió concretamente: usar tags en GitHub Actions ya no es una opción razonable para cualquier organización que maneje secretos en CI/CD. SHA pinning dejó de ser una «buena práctica opcional» para convertirse en un requisito mínimo. Y la aparición de bots como hackerbot-claw, que automatizan la búsqueda de workflows mal configurados a escala, significa que las configuraciones inseguras van a ser explotadas más rápido de lo que podés parchearlas.

Si todavía no revisaste tus workflows: hacelo hoy. Pineá todas las actions por SHA, rotá los secretos que hayan estado accesibles durante la ventana de compromiso, y configurá permisos mínimos en cada workflow. El costo de hacerlo ahora es unas horas de trabajo. El costo de no hacerlo es que alguien tenga las llaves de tu infraestructura de producción.

Fuentes

• The Hacker News — Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked
• CrowdStrike — From Scanner to Stealer: Inside the Trivy Action Supply Chain Compromise
• Socket.dev — Trivy Under Attack Again: GitHub Actions Compromise
• StepSecurity — hackerbot-claw: GitHub Actions Exploitation Analysis
• StepSecurity — Trivy Compromised a Second Time: Malicious v0.69.4 Release