Le 5 août 2026, GitHub a notifié les mainteneurs d'au moins trois Actions populaires d'une compromission de leurs comptes. Les actions concernées totalisaient plusieurs millions d'utilisations par semaine et couvraient des opérations courantes : déploiement sur AWS et GCP, gestion des secrets, notification Slack. Pendant une fenêtre d'environ 6 heures, les pipelines qui les utilisaient ont exécuté du code non autorisé qui exfiltrait les variables d'environnement vers un serveur externe.
Le vecteur : prise de contrôle de comptes mainteneurs
Les trois comptes compromis avaient en commun de ne pas avoir activé l'authentification MFA. Les attaquants ont vraisemblablement utilisé des credentials issus de fuites de données pour prendre le contrôle des comptes, puis ont publié de nouvelles versions des actions avec un payload malveillant intégré.
La modification était minimale : une ligne ajoutée dans chaque action pour envoyer le contenu de ${{ toJSON(secrets) }} vers un endpoint externe. Suffisamment discret pour passer inaperçu dans un diff rapide. Les tokens AWS, les credentials de déploiement, les clés API Stripe et les secrets de signature de tokens étaient directement accessibles dans cet objet.
Êtes-vous affecté ?
Si vos workflows GitHub Actions référencent des actions tierces sans épingler sur un SHA de commit précis, vous êtes potentiellement exposé à ce type d'attaque. Une action référencée par uses: action/deploy@v3 exécutera automatiquement la dernière version publiée sous le tag v3, qui peut être modifiée à tout moment par le mainteneur ou un attaquant qui a pris le contrôle du compte.
Pour vérifier si vous avez été affecté : consultez les logs d'exécution de vos workflows du 5 août entre 06h00 et 12h00 UTC, et vérifiez la présence de requêtes sortantes inhabituelles dans les étapes qui utilisent les actions compromises. GitHub a publié la liste des hashes de commits malveillants.
La correction immédiate : épingler sur des SHA de commit
La défense la plus robuste contre ce type d'attaque est d'épingler chaque action tierce sur un SHA de commit spécifique plutôt que sur un tag ou une branche.
# Vulnérable
- uses: actions/checkout@v4
# Sécurisé : épinglé sur un commit précis
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2Un SHA de commit est immuable. Même si le mainteneur du repo modifie le tag v4, le SHA que vous avez épinglé pointe toujours vers le commit original que vous avez audité.
Les bonnes pratiques pour sécuriser ses Actions
- Épingler toutes les actions tierces sur un SHA de commit. Des outils comme StepSecurity Harden-Runner ou Renovate peuvent automatiser la mise à jour des SHA.
- Limiter les permissions accordées au token GitHub dans chaque workflow avec
permissions:au plus strict nécessaire. - Utiliser des environnements GitHub avec règles d'approbation pour les workflows qui accèdent à des secrets de production.
- Activer l'OIDC pour les déploiements cloud (AWS, GCP, Azure) : les tokens sont temporaires et ne nécessitent pas de stocker des credentials longs dans les secrets GitHub.
- Auditer régulièrement les actions tierces utilisées avec OSSF Scorecard.
- GitHub Security Blog — GitHub, 5 août 2026
- Security hardening for GitHub Actions — GitHub Docs, 2026
