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

• 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”