Des milliers de développeurs l’installaient pour sécuriser leur code. Pendant douze heures, c’est l’outil lui-même qui aspirait leurs mots de passe, clés SSH et identifiants cloud.
Le gardien retourné contre ses utilisateurs
Trivy est un scanner de vulnérabilités open source maintenu par Aqua Security. Son travail : fouiller conteneurs, clusters Kubernetes et dépôts de code à la recherche de failles et de secrets exposés. Plus de 10 000 projets sur GitHub l’intègrent dans leurs pipelines d’intégration continue, selon l’analyse de Socket. Le 19 mars 2026, la version 0.69.4 du scanner a été publiée avec un passager clandestin : un programme capable de siphonner tout ce que l’outil était censé protéger.
Le chercheur en sécurité Paul McCarty a tiré la sonnette d’alarme le premier en signalant que les images conteneurs et les binaires officiels de Trivy avaient été corrompus. Wiz Research et Socket ont ensuite décortiqué l’attaque et identifié son ampleur réelle : le problème dépassait largement une seule version.
75 versions corrompues en un seul coup
Les attaquants ont forcé la modification de 75 étiquettes de version sur 76 dans le dépôt officiel trivy-action sur GitHub, selon l’analyse de Socket publiée le 20 mars. Seule la version 0.35.0 est restée intacte. Chaque projet qui référençait une de ces étiquettes exécutait automatiquement le code malveillant avant même de lancer le scan légitime.
Sept étiquettes du dépôt setup-trivy ont subi le même sort, d’après Wiz. Le compte de service compromis (aqua-bot) a permis aux attaquants de publier des workflows piégés dans d’autres projets d’Aqua Security et d’exfiltrer au passage des clés GPG, des identifiants Docker Hub, et des tokens Slack et Twitter.
La manœuvre était presque invisible. Le binaire malveillant lançait le véritable Trivy en parallèle : le scan de sécurité tournait normalement pendant que le voleur opérait en coulisses.
Clés SSH, wallets crypto, identifiants cloud : le butin
Le programme ratissait large. BleepingComputer détaille la liste des cibles : clés SSH privées et publiques, fichiers de configuration Git, AWS, GCP, Azure et Kubernetes, identifiants PostgreSQL, MySQL, MongoDB et Redis, tokens d’authentification, configurations VPN, historiques de commandes shell, et portefeuilles de cryptomonnaies.
Sur les serveurs d’intégration continue, le code fouillait aussi la mémoire du processus Runner.Worker de GitHub Actions, à la recherche de secrets stockés en clair. Sur les machines de développeurs, il scannait l’environnement local et les interfaces réseau.
Les données collectées étaient chiffrées avec un double verrou (AES-256 combiné à RSA-4096, selon Wiz), compressées dans une archive, puis envoyées vers un domaine à l’orthographe truquée : scan.aquasecurtiy.org, imitant le vrai site d’Aqua Security avec une simple inversion de lettres. Si l’exfiltration échouait, le programme créait un dépôt public nommé tpcp-docs sur le compte GitHub de la victime et y téléversait les données volées, à la vue de tous.
Pour persister sur les machines infectées, une charge Python se déposait en service système. Le serveur de commande et contrôle utilisait un canister sur Internet Computer, un réseau décentralisé quasi impossible à faire tomber : seul le contrôleur du canister peut le supprimer. Au moment de l’analyse par Wiz, le point de contact renvoyait vers un RickRoll, un classique de l’humour internet, mais la destination pouvait changer à tout moment.
Tout est parti d’un mot de passe changé trop vite
L’attaque du 19 mars n’est pas un événement isolé. C’est la suite directe d’un premier incident survenu le 1er mars 2026, au cours duquel des identifiants avaient été exfiltrés depuis l’environnement CI de Trivy.
Aqua Security a reconnu la faille dans un communiqué posté sur GitHub : « Notre confinement du premier incident était incomplet. Nous avons effectué une rotation des secrets et tokens, mais le processus n’était pas atomique et les attaquants ont pu avoir connaissance des tokens rafraîchis. »
En clair : en changeant les mots de passe, l’opération n’a pas été instantanée, laissant une fenêtre pendant laquelle les attaquants ont intercepté les nouveaux accès. C’est avec ces identifiants récupérés qu’ils ont pu publier la version piégée, réécrire les étiquettes de version et même supprimer le premier communiqué d’Aqua Security expliquant la brèche de mars, d’après BleepingComputer.
L’équipe derrière l’opération se fait appeler TeamPCP, aussi traquée sous les noms DeadCatx3, PCPcat et ShellForce. Wiz les décrit comme un groupe spécialisé dans l’exploitation d’API Docker mal configurées, de clusters Kubernetes exposés et de serveurs Redis ouverts.
Un ver qui publie 28 paquets en une minute
TeamPCP n’en est pas resté là. Moins de 24 heures après la compromission de Trivy, la société de sécurité Aikido a détecté une nouvelle arme : CanisterWorm, un ver auto-propagatif ciblant les paquets npm. Le ver vole les tokens d’authentification npm, identifie tous les paquets publiables sur le compte de la victime, incrémente les numéros de version et publie des copies piégées. 28 paquets du scope @EmilGroup et 16 du scope @opengov ont été compromis, selon Aikido. L’ensemble de l’opération a pris moins d’une minute.
Le ver se déguise en outil PostgreSQL pour passer inaperçu : le service s’appelle pgmon, le binaire téléchargé pglog, le fichier d’état .pg_state. Il conserve le fichier README original de chaque paquet publié pour ne pas éveiller les soupçons lors d’un audit rapide.
Les versions corrigées de Trivy sont en ligne et les artefacts malveillants retirés. Mais le ver CanisterWorm circule toujours sur npm, et les tokens volés pendant les douze heures d’exposition restent exploitables tant qu’ils n’ont pas été révoqués. Socket a généré 182 alertes en temps réel au fil de la campagne. Pour les équipes qui utilisaient Trivy dans leurs pipelines, la seule marche à suivre reste celle dictée par Aqua Security : tout révoquer, tout renouveler, et ne rien considérer comme sain.
