Trivy à nouveau attaqué : fuite de secrets via une vaste falsification de tags GitHub Actions

 (socket.dev)
2 points par GN⁺ 2026-03-24 | 1 commentaires | Partager sur WhatsApp
  • La GitHub Action officielle a été compromise par une mise à jour forcée de tags, entraînant une attaque de la chaîne d’approvisionnement diffusant du code malveillant
  • Les attaquants ont remplacé 75 tags sur 76 par des commits malveillants, affectant environ plus de 10 000 workflows
  • Le script altéré fonctionne en trois étapes — collecte, chiffrement et exfiltration de secrets — et inclut du code TeamPCP Cloud stealer
  • Les tags compromis sont toujours actifs ; seuls @0.35.0 ou un commit SHA précis sont confirmés comme sûrs
  • Il est impératif de remplacer tous les identifiants et d’épingler les workflows sur un commit SHA ; la même contamination a aussi été constatée sur les images Docker Hub

Vue d’ensemble de l’attaque de la chaîne d’approvisionnement sur Trivy GitHub Actions

  • La GitHub Action officielle de Trivy (aquasecurity/trivy-action) a été compromise par des attaquants via une mise à jour forcée de tags (force-push), ce qui a permis la diffusion de code malveillant
  • Les attaquants ont remplacé 75 des 76 tags de version par des commits malveillants, de façon à les faire exécuter automatiquement dans les pipelines CI/CD
  • Environ plus de 10 000 fichiers de workflow GitHub référencent cette action, ce qui donne à l’incident une portée considérable
  • Les tags infectés sont toujours actifs, et @0.35.0 est confirmé comme la seule version sûre
  • Socket a détecté en temps réel 182 événements GitHub Action malveillants à partir de 19:15 UTC, classés dans les catégories Backdoor, Infostealer et Reconnaissance

Origine de l’attaque et mode opératoire

  • Selon les mainteneurs de Trivy, cette attaque a été rendue possible par le vol d’identifiants disposant de droits d’écriture
    • Lors d’une compromission antérieure survenue début mars, des secrets de l’environnement CI ont fuité, et leur rotation n’a pas été complète, laissant certains nouveaux identifiants aux attaquants
    • Les attaquants ont utilisé ces identifiants pour effectuer des mises à jour authentifiées de tags sans exploiter de vulnérabilité propre à GitHub
  • Au lieu de pousser sur une branche ou de créer une release, les attaquants ont écrasé de force les tags existants avec de nouveaux commits
    • Chaque tag a été falsifié pour paraître légitime en recopiant les métadonnées du commit d’origine (auteur, e-mail, horodatage, message de commit)
    • Toutefois, alors que le commit d’origine était signé GPG, le commit des attaquants n’avait pas de signature, et la date du commit parent était incohérente, fixée en 2026
  • Même lorsqu’un indicateur Immutable Release apparaît sur GitHub, il est possible que les attaquants aient publié l’état malveillant avant de verrouiller la release
    • Il ne faut donc pas se fier au badge “Immutable” ; seule la méthode d’épinglage sur un commit SHA constitue un mode de consommation sûr

Structure de la falsification des tags

  • Les attaquants ont créé de nouveaux commits à partir du dernier commit de la branche master (57a97c7e)
    • Seul le fichier entrypoint.sh a été remplacé par une version malveillante, tous les autres fichiers restant inchangés
    • Chaque tag a été falsifié en recopiant le numéro de PR, le message de commit et les informations d’auteur d’origine
  • Sur la page des releases GitHub, l’indication “0 commits to master since this release” peut servir d’indice visuel d’un tag falsifié
  • La raison pour laquelle seul le tag 0.35.0 n’a pas été compromis est qu’il pointait déjà vers la HEAD de master

Structure de la charge malveillante

  • Le entrypoint.sh compromis comporte 204 lignes au total, avec le code Infostealer aux lignes 4 à 105, puis le code légitime de scan Trivy ensuite
  • Le malware se compose de trois étapes
    • Étape 1 : collecte — extraction de secrets depuis la mémoire des processus runner et le système de fichiers
    • Étape 2 : chiffrement — chiffrement des données collectées avec AES-256-CBC et RSA-4096
    • Étape 3 : exfiltration — envoi vers un domaine contrôlé par l’attaquant ou vers le compte GitHub de la victime

  • Étape 1 : collecte de secrets

    • Lecture des variables d’environnement des processus runner GitHub Actions (Runner.Worker, Runner.Listener, runsvc, run.sh) depuis /proc/<pid>/environ, avec extraction des entrées contenant les mots-clés env et ssh
    • Sur les runners hébergés par GitHub, exécution via sudo d’un script de dump mémoire basé sur Python pour rechercher le motif "isSecret":true dans la mémoire du processus Runner.Worker
    • Sur les runners auto-hébergés, exécution d’un collecteur d’identifiants sur le système de fichiers identifié comme TeamPCP Cloud stealer
      • Cibles très larges, notamment clés SSH, identifiants AWS/GCP/Azure, jetons Kubernetes, configuration Docker, mots de passe de bases de données, fichiers d’environnement, clés TLS, configurations VPN, URL de webhook, clés de portefeuille, etc.

  • Étape 2 : chiffrement

    • Génération d’une clé de session de 32 octets avec openssl rand, puis chiffrement des données avec AES-256-CBC
    • La clé de session est chiffrée avec une clé publique RSA-4096 en appliquant un padding OAEP
    • Les données chiffrées (payload.enc) et la clé de session (session.key.enc) sont regroupées dans tpcp.tar.gz

  • Étape 3 : exfiltration des données

    • Canal principal : envoi HTTPS POST vers https://scan[.]aquasecurtiy[.]org (domaine typosquatté de aquasecurity)
    • Canal secondaire : en cas d’échec, utilisation du GitHub Personal Access Token de la victime pour créer un dépôt public nommé tpcp-docs
      • Téléversement de tpcp.tar.gz comme asset de release → les attaquants récupèrent ensuite les données en recherchant ce dépôt sur GitHub
    • Tentative de contournement des pare-feu via l’infrastructure GitHub, avec forte capacité d’évasion de détection
    • Suppression finale des fichiers temporaires pour réduire les traces

Attaquants et groupe à l’origine

  • Des commentaires dans le code malveillant mentionnent explicitement “TeamPCP Cloud stealer”
    • TeamPCP (DeadCatx3, PCPcat, ShellForce) est un groupe spécialisé dans l’attaque des environnements cloud-native, déjà lié à l’exploitation de vulnérabilités dans Docker API, Kubernetes, Redis et les tableaux de bord Ray
    • En février 2026, Flare et The Hacker News l’avaient déjà signalé dans le cadre de campagnes de rançongiciel, vol de données et minage de cryptomonnaies
  • Les fonctions de collecte de clés de validateur Solana et de portefeuilles crypto concordent avec une motivation financière

Réponse et recommandations

  • Cesser immédiatement d’utiliser tous les tags de version de Trivy Action ; utiliser uniquement le commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 ou le tag 0.35.0
  • Tout pipeline infecté doit être considéré comme une fuite complète de secrets ; tous les identifiants cloud, clés SSH, jetons API, mots de passe de bases de données et jetons Docker doivent être remplacés immédiatement
  • Il est recommandé de vérifier la présence d’un dépôt tpcp-docs dans l’organisation GitHub et d’examiner les logs de trivy-action exécutés après le 19 mars à 19:00 UTC

Indicateurs de compromission (IOCs)

  • Indicateur réseau : scan[.]aquasecurtiy[.]org
  • Hash de fichier : 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
  • GitHub Actions infectées : toutes les versions de aquasecurity/trivy-action@0.0.1 à @0.34.2 incluses (75 tags au total)

Mise à jour supplémentaire (22 mars)

  • Il a aussi été confirmé sur Docker Hub que les images Trivy (0.69.4, 0.69.5, 0.69.6, latest) étaient contaminées par la même charge Infostealer
  • Le tag latest a pointé vers une image malveillante et a été distribué aux utilisateurs pendant la période d’exposition
  • Des détails supplémentaires sont disponibles dans le rapport séparé de Socket “Trivy Docker Images Compromised”

À lire aussi

1 commentaires

 
GN⁺ 2026-03-24
Réactions sur Hacker News

  • Certains se demandent pourquoi GitHub n’impose pas le versioning immuable (immutable versioning) pour les Actions
    Le guide de sécurité recommande de les épingler sur un SHA de commit, mais on pourrait sans doute réduire ce type de problème en empêchant purement et simplement la publication d’une Action si elle n’est pas épinglée

    • Ce débat a toujours deux faces
      Du point de vue de la sécurité, les versions épinglées sont plus sûres, mais en même temps, l’absence d’application automatique des mises à jour de sécurité peut aussi devenir un risque
      Il faut au final une solution qui satisfasse les deux exigences sans nuire à la productivité
      On pourrait appeler ça le « paradoxe du pinning »
    • GitHub Actions suit le modèle des tags git, donc il semble difficile de changer la structure actuelle
      Cela dit, il faudra bien commencer un jour
    • Et si la version épinglée était déjà compromise ?
      Autoriser les mises à jour pourrait alors au contraire renforcer la sécurité
      C’est un problème proche du débat lien statique vs lien dynamique
      D’autant plus que l’Action Trivy était de toute façon conçue pour récupérer la dernière version

  • Cet incident rappelle que les produits de « sécurité de la chaîne d’approvisionnement (supply chain security) » peuvent en pratique être aussi vulnérables que la pile qu’ils prétendent protéger
    En particulier, les outils de sécurité qui « s’exécutent partout (run us everywhere) » créent un nouveau vecteur d’attaque où une seule compromission peut mettre en danger un très grand nombre d’utilisateurs à la fois

  • Au début, certains ont cru que Trivy n’avait pas correctement effectué la rotation des identifiants (rotation)
    Mais l’équipe a expliqué qu’un attaquant avait pu découvrir le nouveau token durant un processus de rotation non atomique (non-atomic)
    GitHub n’affiche plus les tokens après leur émission, mais cela peut varier selon la méthode d’authentification utilisée

    • Le créateur d’OpenClaw dit avoir vécu quelque chose de similaire
      Juste après la création d’une nouvelle organisation GitHub, le nom a été détourné, au point qu’il a dû demander à GitHub une création atomique

  • C’est le cas parfait pour la formule : « il faut scanner les vulnérabilités, pas en devenir une »

    • Au point de faire surgir la blague : « si tu regardes la vulnérabilité, la vulnérabilité te regarde aussi »

  • Il y a eu un incident lié intitulé compromission temporaire de la supply chain de Trivy

    • Le terme « temporaire » semble vraiment euphémistique

  • Le 22 mars, l’attaquant a publié des images DockerHub malveillantes de Trivy v0.69.5 et v0.69.6 à l’aide d’identifiants compromis
    (lien vers l’avis de sécurité)
    Il y a eu deux incidents, les 19 et 22 mars, et l’attaquant semble avoir conservé son accès malgré deux rotations successives des identifiants

    • En réalité, il y avait déjà une compromission complète du dépôt depuis février, et il s’agit ici de la troisième attaque réussie du même acteur

  • « Ces deux dernières semaines ont été les pires »
    À cause de la compromission de Trivy, certains ont dû gérer une avalanche de rapports et réunions de sécurité

  • L’enseignement, c’est que « ce n’est pas parce qu’on fait des logiciels de sécurité qu’on est forcément compétent »
    Même en interne, certaines équipes sécurité cherchent à introduire un nouveau scanner tous les mois, mais si on leur avait accordé les droits d’accès étendus qu’ils demandaient, elles se seraient déjà fait compromettre plusieurs fois

    • Quelqu’un dit avoir déjà audité les GitHub Actions de Trivy, et que l’Action setup-trivy clonait directement la branche principale avant d’exécuter un script shell
      En clair, cela permettait l’exécution de code arbitraire dans tous les workflows CI
      Aqua a été compromis plus tôt ce mois-ci, a échoué deux fois à isoler correctement le problème, puis a vu son compte Docker Hub compromis à son tour
      Pour certains, il faut désormais faire appel à des experts externes
    • Donner des droits d’accès étendus à des « outils de sécurité » ne réduit pas le risque, cela le propage
      La plupart ne sont que des générateurs de rapports bruyants, et une fois l’attaquant à l’intérieur, ils ne défendent plus rien
      Les nouveaux scanners devraient n’accéder qu’à des données en lecture seule dans un sandbox isolé, et ne jamais recevoir d’accès de production avant d’avoir été suffisamment validés
      Sinon, cela revient pratiquement à publier ses clés secrètes sur pastebin
    • Aujourd’hui, la sécurité en entreprise consiste souvent à installer des solutions de sécurité endpoint sur tous les appareils et à envoyer tous les logs vers un tableau de bord IA
      Une culture de la sécurité façon « aller vite et tout casser »
    • En pratique, les équipes sécurité n’ont pas vraiment l’option de dire « il n’existe aucun produit valable sur le marché, donc nous n’utiliserons rien »
      Cela crée une culture où l’on déploie quand même des logiciels de sécurité de mauvaise qualité
      Certains estiment que Trivy lui-même n’est pas mauvais, et leur entreprise l’utilise aussi
      Mais ils épinglent les versions avec Nix et écrivent eux-mêmes leurs workflows Actions, ce qui les a protégés de cet incident

  • L’attaquant, une fois authentifié, a pu effectuer une mise à jour forcée (force-update) des tags
    Cela aurait pu être évité en activant simplement l’ancien réglage GitHub « interdire l’écrasement des tags »
    À mesure que ces incidents se répètent, l’idée d’un standard de type Software Building Code paraît de plus en plus nécessaire
    Certains se demandent combien de raisons supplémentaires de ce genre apparaîtront d’ici 2026