Trivy compromis 2 fois en 3 semaines : quand l'outil de sécurité devient le vecteur d'attaque

L'outil DevSecOps chargé de trouver les vulnérabilités de vos dépendances en avait lui-même... et ça s'est répété. Si la solution Trivy fait partie de votre pipeline CI/CD, ce qui suit vous concerne directement.

19 minutes chrono

Trivy, est un outil open source de la société américaine Aqua Security, capable d'analyser vos images Docker, vos dépendances, vos fichiers d'infrastructure-as-code et vos configurations Kubernetes à la recherche de failles de sécurité connues.

Avec 33 000 étoiles sur GitHub et plus de 100 millions de téléchargements sur Docker Hub, c'est l'un des piliers les plus déployés dans les pipelines DevSecOps modernes. Autant dire une cible de choix pour quiconque cherche un raccourci vers les secrets de milliers d'organisations.

Le 28 février 2026, un bot automatisé baptisé "hackerbot-claw" (le genre de nom qui manque un chouilla de discrétion) exploite une faille classique des GitHub Actions : le déclencheur pull_request_target. Ce type de workflow s'exécute avec les permissions du dépôt principal même quand la pull request vient d'un fork inconnu.

En 19 minutes, le bot ouvre une PR piégée, injecte du code malveillant et récupère un token d'accès avec les droits d'écriture complets sur le dépôt (aïe).

La suite : la totalité des releases GitHub (de v0.27.0 à v0.69.1) est supprimée, le dépôt est temporairement renommé et rendu privé, l'extension VS Code de Trivy sur OpenVSX se retrouve infectée.

L'attaque est attribuée au groupe TeamPCP, un collectif connu pour des campagnes de cryptominage, ransomware et exfiltration dans des environnements cloud.

Aqua Security réagit, corrige le workflow vulnérable, restaure le dépôt, publie une version v0.69.2 propre. Et lance une rotation de ses credentials, qui n'ira pas jusqu'au bout.

Retour par la même porte

Le 19 mars, TeamPCP revient : les credentials issus du premier incident n'avaient pas tous été révoqués. Trois semaines plus tard, une boîte de sécurité qui se fait reprendre via ses propres secrets mal rotés, c'est le genre de scénario que même un pentest d'entrée de gamme est censé attraper.

Cette fois-ci, l'attaque vise trois composants simultanément.

Le binaire Trivy : une fausse version v0.69.4 est publiée. Les binaires contactent un serveur de commande et contrôle (C2), via un faux domaine, scan.aquasecurtiy.org (« security » volontairement mal orthographié, une technique de typosquatting classique). Le binaire malveillant est suffisamment crédible pour déclencher les mises à jour automatiques de Homebrew, et exécute le vrai Trivy en parallèle du code malveillant pour ne pas éveiller les soupçons.

trivy-action (l'action GitHub officielle) : 75 des 76 tags du dépôt sont écrasés par force push pour pointer vers des commits malveillants. Tous les pipelines qui référencent un tag par son nom (comme @v0.28.0) plutôt qu'épinglé sur un hash de commit SHA exécutaient désormais du code de l'attaquant. L'attaquant a même pris soin de copier les auteurs, dates et messages de commit des originaux pour que la substitution soit invisible à première vue.

setup-trivy : même principe, 7 tags réécrits de la même façon. Le commit malveillant passait de 4 lignes modifiées (la version légitime) à 117, le reste étant le code d'exfiltration.

Découvrez Passbolt, le gestionnaire de mots de passe open source que votre équipe mérite vraiment

Un aspirateur à secrets

Le code injecté ne se contentait pas de passer un simple coup de fil chez l'attaquant. Il parcourait méthodiquement plus de cinquante chemins sensibles du système de fichiers à la recherche de clés SSH, de tokens AWS, GCP et Azure, de configurations Docker, de tokens Kubernetes et de wallets de cryptomonnaies. Il inspectait également la mémoire du processus du runner CI/CD pour extraire des secrets GitHub Actions encore en clair.

Le tout était chiffré et envoyé au serveur de l'attaquant. Si le serveur était injoignable, le payload se rabattait sur un plan B : créer un dépôt GitHub public tpcp-docs dans le compte de la victime pour s'en servir comme canal de transfert des données volées. Utiliser les serveurs de GitHub contre GitHub, depuis un repo créé dans le compte de la cible. Sur les machines non-CI/CD, le malware allait plus loin : il installait un mécanisme de persistance via un service systemd qui se réveillait toutes les cinq minutes pour contacter un serveur de repli.

Plus de 10 000 pipelines dans la fenêtre de tir

L'action trivy-action est référencée dans plus de 10 000 workflows GitHub. Tous ceux qui utilisaient un tag nommé plutôt qu'un hash de commit SHA se sont alors vu potentiellement exposés pendant la fenêtre d'attaque.

L'outil Harden-Runner de StepSecurity a détecté l'attaque environ 90 minutes après son lancement en repérant une connexion sortante anormale vers le domaine typosquatté. Homebrew a réalisé un downgrade d'urgence. De son côté, Aqua Security a supprimé les artefacts malveillants de GitHub Releases, Docker Hub, GHCR et ECR.

L'impact ne s'est pas arrêté là : les données volées auraient ensuite été utilisées pour compromettre plusieurs packages npm, les attaquants y injectant des versions malveillantes contenant un ver auto-propagateur.

La recommandation d'Itay Shakury, VP Open Source chez Aqua Security : si vous avez utilisé une version compromise, considérez tous les secrets de vos pipelines comme compromis et faites-les pivoter immédiatement. Il reconnaît que la rotation après le premier incident « n'était pas atomique » et que les attaquants ont pu intercepter les nouveaux tokens au passage.

Les versions nettoyées à utiliser sont Trivy v0.69.3, trivy-action v0.35.0 et setup-trivy v0.2.6.

L'ironie de compromettre un scanner de vulnérabilités n'échappera bien sûr à personne, mais le vrai problème est avant tout structurel. L'intégralité de cette seconde attaque repose sur un mécanisme que Git autorise par design : un tag, contrairement à un hash de commit, peut être supprimé et recréé à volonté pour pointer vers n'importe quel code.

C'est exactement ce que TeamPCP a fait sur 75 tags d'un coup. Si vos workflows GitHub Actions référencent des actions par tag (@v0.28.0), vous faites confiance à une étiquette que n'importe qui avec un accès en écriture peut déplacer silencieusement. Épinglez sur un hash SHA complet : c'est le seul identifiant que personne ne peut réécrire.