Trivy : Attaque Supply Chain via GitHub Actions 2026

Ce qui s'est passé

Le 19 mars 2026, le groupe d'attaquants connu sous les noms TeamPCP, DeadCatx3 et CipherForce a lancé une seconde offensive contre le dépôt GitHub aquasecurity/trivy-action, l'une des GitHub Actions de sécurité les plus utilisées dans les pipelines CI/CD à travers le monde. Les attaquants ont réussi à force-pusher du code malveillant sur 75 des 76 tags de version du projet, couvrant l'intégralité des releases de v0.0.1 à v0.34.2, ainsi que 7 tags du dépôt setup-trivy. Pendant environ douze heures, tout workflow GitHub Actions référençant trivy-action par un tag de version — la pratique la plus répandue dans les entreprises — a exécuté un infostealer à trois étapes avant même que le scanner Trivy légitime ne s'exécute. L'infostealer collectait les variables d'environnement, les clés SSH, les tokens de comptes de service Kubernetes, les configurations Docker et Git, les credentials de bases de données, les wallets crypto et les PAT GitHub présents dans la mémoire du runner CI/CD. Les données volées étaient chiffrées puis exfiltrées vers le serveur de commande et contrôle scan.aquasecurtiy[.]org, un typosquat délibéré du domaine officiel Aqua Security. En cas d'échec de l'exfiltration principale, les PAT GitHub volés étaient utilisés pour pousser les données dans un dépôt public nommé tpcp-docs. Plus de dix mille fichiers de workflow GitHub dépendent de cette action, ce qui confère à cette attaque un rayon de blast potentiellement massif pour l'ensemble de l'écosystème DevSecOps mondial.

Il s'agit du second incident en moins d'un mois pour Aqua Security. Une première compromission avait eu lieu le 1er mars 2026. La rotation des credentials effectuée après cet incident initial s'est révélée incomplète et non atomique, laissant aux attaquants un accès aux tokens fraîchement générés. Aqua Security a confirmé les faits et publié les versions corrigées : trivy-action 0.35.0, trivy 0.69.3 et setup-trivy 0.2.6. Les équipes de sécurité de Wiz, CrowdStrike, Snyk et Socket.dev ont produit des analyses techniques approfondies dans les heures suivant la détection. BleepingComputer a été le premier média à couvrir l'incident en détail, confirmant l'implication du groupe TeamPCP déjà documenté sur d'autres campagnes cloud-native.

Pourquoi c'est important

Cette attaque illustre parfaitement le risque lié aux dépendances CI/CD épinglées par tag mutable plutôt que par commit SHA immuable. Un tag Git peut être réécrit silencieusement à tout moment — comme l'a démontré TeamPCP — tandis qu'un commit SHA est immuable par construction. La récurrence en moins d'un mois soulève des questions critiques sur la gestion du cycle de vie des credentials après un incident : une rotation partielle est aussi dangereuse que l'absence de rotation. Ce type d'attaque supply chain DevSecOps est particulièrement insidieux car l'outil de sécurité lui-même devient le vecteur d'exfiltration, contournant tous les contrôles d'accès puisqu'il s'exécute avec les permissions natives du runner CI/CD. Cette attaque s'inscrit dans une tendance croissante d'offensives ciblant les outils open source de sécurité, comme l'avait illustré l'affaire Shai-Hulud 2 ciblant l'écosystème NPM. Pour les équipes DevSecOps, cet incident rappelle que les outils d'automatisation comme n8n référencés par la CISA ou les actions CI/CD constituent des surfaces d'attaque prioritaires difficiles à monitorer.

Le groupe TeamPCP, documenté depuis 2024, est spécialisé dans les attaques contre les infrastructures cloud-native et les pipelines de développement. Son modus operandi cible délibérément les outils utilisés quotidiennement par les équipes de sécurité, transformant les défenses en armes d'exfiltration. Cette stratégie rappelle celle observée lors de la compromission de SharePoint exploitée par des groupes avancés : les plateformes de productivité et de sécurité deviennent des vecteurs d'attaque de choix. Pour les DSI et RSSI, l'enjeu est désormais d'étendre la gestion des risques tiers aux composants CI/CD avec la même rigueur qu'aux fournisseurs SaaS critiques.

Ce qu'il faut retenir

Pour approfondir la sécurisation de vos pipelines DevSecOps, consultez également notre analyse de la vulnérabilité React2Shell affectant React Native et les mesures de remédiation associées aux chaînes de dépendances frontend.