Début mars, nous relations une affaire inquiétante : un bot avait exploité GitHub Actions pour vider un dépôt, celui de Trivy ; ironie du sort, c’est un scanner de vulnérabilité. Le bot avait également publié une extension VS Code malveillante. Trivy avait repris le contrôle et publié une version 0.69.2 jugée comme sûre. Trois semaines plus tard, on découvre que ce n’est pas terminé, loin de là.

• Sécurité

  Hackerbot-claw : un bot exploite GitHub Actions et vide le dépôt de Trivy

  Sécurité

  Mardi 03 mars 2026 à 14h47 03/03/2026 14h47

  13

Versions 0.69.4, 0.69.5 et 0.69.6 de Trivy compromises

Pour Stéphane Robert, ingénieur DevOps et architecte cloud chez 3DS Outscale, c’était une alerte de plus, à ajouter à toutes les précédentes : « Vos pipelines sont une surface d’attaque. Ils ont des permissions d’écriture sur vos repos, accèdent à des secrets, et s’exécutent à chaque push. Vous ne pourrez plus dire “je ne savais pas” ».

Il n’a pas fallu attendre longtemps pour que l’histoire lui donne de nouveau raison. Dans un billet de blog intitulé « 20 jours plus tard : Trivy est compromis, acte II », Boost Security Labs détaille une nouvelle attaque contre Trivy : « Le pirate a retrouvé l’accès à Aqua Security (via un vecteur encore sous enquête) […] Le 19 mars 2026, des versions empoisonnées de Trivy (v0.69.4) ont été diffusées ».

Stéphane Robert ajoute que « les versions 0.69.5 et 0.69.6, poussées le 22 mars sans publications GitHub associées, contiennent elles aussi des indicateurs de compromission ». Elles étaient disponibles sur Docker Hub.

Oups : « des attaquants ont pu avoir accès aux jetons mis à jour »

Sur GitHub, Aqua Security (éditeur de Trivy) confirme : « Le 19 mars, nous avons observé qu’un acteur malveillant avait utilisé des identifiants compromis pour publier des versions malveillantes de trivy (v0.69.4), trivy-action et setup-trivy. Il s’agissait d’une suite à l’incident récent du 1er mars qui avait entraîné l’exfiltration d’identifiants. Le confinement du premier incident était incomplet. Nous avons renouvelé les secrets et les jetons, mais le processus n’était pas atomique et des attaquants ont pu avoir accès aux jetons mis à jour ».

Un GitHub Advisory (GHSA) dédié a été mis en ligne, qui précise à ce sujet que « toutes les accréditations n’ont pas été révoquées simultanément », la fenêtre rotation durait quelques jours, ce qui a suffi à l’attaquant pour exfiltrer les nouveaux secrets.

Face à cette situation, Trivy serre encore la vis : « Nous adoptons désormais une approche plus restrictive et bloquons toutes les actions automatisées et tous les jetons afin d’éliminer complètement le problème […] Toutes les dernières versions pointent désormais vers une version sûre ». En espérant que cette fois ce soit la bonne.

Les versions considérées par Aqua Security comme fiables sont les 0.69.3 pour Trivy, 0.2.6 pour aquasecurity/setup-trivy (GitHub Actions) et 0.35.0 aquasecurity/trivy-action (GitHub Actions). Les versions malveillantes sont restées entre 3 et 12 heures en ligne, selon les développeurs.

Un peu de typosquatting pour la route

L’attaque ciblait donc Trivy directement, mais il y avait également « deux commits imposteurs non rattachés à une branche. L’un visait actions/checkout, l’autre aquasecurity/trivy. Ces commits utilisaient des auteurs crédibles, des messages plausibles et des modifications volontairement discrètes pour se fondre dans le bruit d’un diff ordinaire », explique Stéphane Robert.

L’attaquant utilisait aussi un nom de domaine proche de celui de l’entreprise : scan.aquasecurtiy.org… avez-vous remarqué l’inversion entre le i et le t dans securtiy ? Le nom de domaine a été acheté le 17 mars, juste avant l’attaque. Boost Security explique que cette adresse était utilisée pour récupérer des fichiers malveillants qui venaient remplacer certains composants de Trivy.

Conclusion et leçon à retenir selon Stéphane Robert : « une fois qu’un attaquant tient un credential puissant, il peut revenir plus tard, se fondre dans les automatismes du projet, puis transformer l’écosystème de build et de distribution en vecteur d’attaque ». En conséquence, tout ce qui touche au CI/CD (CI pour intégration continue et CD pour déploiement continu) doit être « administré comme un système critique ».

Trivy entraîne LiteLLM dans sa chute

Il reste 60% de l'article à découvrir.

Déjà abonné ou lecteur  ? Se connecter

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Abonnez-vous