El escáner de vulnerabilidades Trivy, uno de los proyectos open source más utilizados para analizar contenedores, clústeres de Kubernetes y repositorios de código, ha sido víctima de una compleja ataque a la cadena de suministro de software. Atacantes lograron insertar un infostealer tanto en flujos de trabajo de GitHub Actions como en binarios distribuidos del proyecto, poniendo en riesgo secretos de CI/CD y credenciales de desarrolladores.
Trivy, DevSecOps y el alcance de la brecha de seguridad
Trivy, desarrollado por Aqua Security, acumula más de 33.200 estrellas en GitHub y se ha convertido en una pieza clave de muchas estrategias DevSecOps. Se integra de forma rutinaria en pipelines de CI/CD para escanear imágenes de contenedores y código antes de su despliegue. Por ello, cualquier manipulación en su cadena de distribución tiene un impacto directo y sistémico en la seguridad de la cadena de suministro de software.
En el incidente analizado, los atacantes, utilizando credenciales robadas, realizaron un force‑push sobre 75 de los 76 tags del repositorio aquasecurity/trivy-action y sustituyeron siete tags de setup-trivy. Así, versiones muy utilizadas como @0.34.2, @0.33 y @0.18.0 pasaron a apuntar a commits maliciosos, mientras que la única etiqueta que permaneció íntegra fue @0.35.0. El binario malicioso Trivy v0.69.4 estuvo disponible alrededor de tres horas, y los tags manipulados de GitHub Actions durante unas doce horas.
Detalles técnicos del ataque a GitHub Actions y binarios trojanizados
Según el análisis de empresas como Socket y Wiz, el rasgo distintivo de esta operación es que los atacantes no crearon commits ni releases nuevos. En su lugar, redirigieron tags existentes a commits maliciosos que imitaban los metadatos originales: nombre y correo del autor, marca de tiempo y mensajes de commit con referencias a los mismos pull requests. Esta técnica reduce las señales visibles de anomalía en el historial del repositorio y dificulta la detección temprana.
En paralelo, se modificó el script entrypoint.sh de la acción de GitHub y se publicaron binarios trojanizados de Trivy v0.69.4 a través de GitHub Releases, Docker Hub, GHCR y Amazon ECR. Mientras la campaña estuvo activa, cualquier pipeline que hiciera referencia a los tags comprometidos descargaba automáticamente código malicioso, un patrón típico en ataques de software supply chain observado también en casos como SolarWinds o Codecov.
Capacidades del infostealer y tipos de datos expuestos
El código malicioso ejecutaba el binario legítimo de Trivy para mantener el comportamiento esperado y, de forma paralela, activaba un infostealer avanzado. El objetivo era extraer información sensible tanto de entornos de CI/CD como de estaciones de trabajo de desarrolladores.
El malware recolectaba variables de entorno y rastreaba el sistema de archivos en busca de credenciales y configuraciones, incluyendo: claves SSH, perfiles de AWS, GCP y Azure, ficheros kubeconfig, configuraciones de Docker, archivos .env, contraseñas de bases de datos, tokens de Slack y Discord, claves TLS, configuraciones VPN y datos de monederos de criptomonedas. Además, enumeraba interfaces de red y analizaba la memoria del proceso GitHub Actions Runner.Worker en busca de cadenas JSON con secretos.
Todos los datos recopilados se cifraban y se enviaban mediante peticiones POST a un dominio typosquatting, scan.aquasecurtiy[.]org, visualmente similar al dominio legítimo de Aqua Security. Si la exfiltración fallaba, el infostealer creaba un repositorio público llamado tpcp-docs en la cuenta de la víctima y volcaba allí la información, un canal de fuga poco habitual en este tipo de amenazas.
En equipos de desarrolladores, el binario trojanizado instalaba además un payload en Python (~/.config/systemd/user/sysmon.py), lo registraba como servicio systemd y consultaba periódicamente un servidor remoto en busca de nuevas cargas maliciosas, logrando así una persistencia post‑explotación en los sistemas comprometidos.
Vinculación con el grupo TeamPCP y campañas previas de cadena de suministro
Los investigadores atribuyen el incidente al grupo TeamPCP (también conocido como DeadCatx3, PCPcat o ShellForce). La atribución se apoya, entre otros indicios, en la cadena «TeamPCP Cloud stealer» incluida en uno de los scripts de Python. Informes previos describen a este actor como especializado en la explotación de Docker API mal configuradas, clústeres de Kubernetes expuestos, paneles de Ray y servidores Redis abiertos, con un foco claro en infraestructuras cloud.
La compañía Aikido relaciona además esta intrusión con la campaña CanisterWorm, un gusano autopropagable orientado a paquetes npm que utiliza tokens de npm robados para publicar versiones maliciosas en cadena y apoyarse en una infraestructura descentralizada basada en Internet Computer (ICP). Este incidente refuerza una tendencia ya observada: los atacantes desplazan sus esfuerzos “hacia la izquierda”, atacando directamente las herramientas y procesos de desarrollo.
Origen de la intrusión: extensión comprometida de VS Code
El mantenedor de Trivy, Itay Shakury, explicó que la raíz del incidente se encuentra en una brecha anterior, ocurrida el 1 de marzo de 2026, cuando se comprometió la extensión Aqua Trivy para VS Code. Esa intrusión permitió a los atacantes obtener credenciales con permisos de escritura sobre la cuenta de GitHub del proyecto.
Tras aquel primer suceso, Aqua Security rotó varios tokens, pero algunos artefactos —entre ellos claves de API, certificados y contraseñas— siguieron accesibles para los atacantes, lo que les dio margen para regresar y ejecutar una operación más destructiva. De forma adicional, los intrusos eliminaron del repositorio de Trivy información relativa a la brecha de marzo, con el objetivo de ocultar la cronología completa de la campaña.
Impacto para las organizaciones y recomendaciones de mitigación
Quiénes están en riesgo tras el ataque a Trivy
Cualquier organización que haya utilizado las versiones comprometidas de GitHub Actions o los binarios modificados de Trivy debe asumir una posible comprometida total de sus secretos. Esto afecta no solo a variables de entorno de los pipelines, sino también a los recursos a los que dan acceso: cuentas cloud, repositorios de código, clústeres de Kubernetes, bases de datos y servicios de mensajería o colaboración.
Pasos de respuesta y endurecimiento de la cadena de suministro
Los mantenedores del proyecto recomiendan la rotación inmediata de todos los secretos: credenciales de nubes públicas, claves SSH, tokens de API, contraseñas de bases de datos, tokens OAuth, claves de VPN y credenciales de herramientas de mensajería. Además, se aconseja:
- Revisar todos los pipelines de CI/CD y los logs de GitHub Actions en busca de ejecuciones sospechosas y conexiones de red inusuales.
- Sustituir el uso de tags flotantes en GitHub Actions por hashes de commit fijados, reforzando la inmutabilidad de las dependencias críticas.
- Aplicar el principio de mínimo privilegio a los tokens de GitHub, exigir 2FA o llaves de hardware en cuentas críticas y limitar el scope de acceso a lo estrictamente necesario.
- Implementar secret scanning en repositorios y artefactos, y verificar la integridad de los releases mediante firmas digitales.
- Reevaluar la gestión de extensiones de IDE, plugins y herramientas de terceros con acceso a credenciales de desarrolladores, incluyéndolos en los procesos de risk assessment.
El ataque contra Trivy pone de manifiesto que incluso proyectos consolidados y orientados a la seguridad pueden convertirse en vectores de riesgo en la cadena de suministro de software. Incorporar controles como fijación de versiones por hash, verificación sistemática de la procedencia de las herramientas, monitorización de repositorios y formación continua de los equipos de desarrollo y operaciones se vuelve esencial para reducir la superficie de ataque y aumentar la resiliencia frente a futuras campañas similares.
