L'essentiel
Une nouvelle vague GhostAction transforme un compte de mainteneur compromis en outil de collecte massive de secrets. L'attaquant pousse un fichier de workflow nommé security-audit.yml (ou un nom proche) dans chaque dépôt où le compte a les droits d'écriture. À l'exécution, il envoie les secrets Actions du dépôt et toutes les clés cloud, IA ou SaaS trouvées dans l'historique git vers une adresse IP codée en dur, en HTTP non chiffré.
Pour toute équipe qui fait passer ses builds et ses releases par GitHub Actions, la leçon est simple. Un secret qui a été commité un jour, même il y a des années et supprimé depuis, doit être considéré comme exposé si un tel workflow a pu s'exécuter. Révoquez d'abord, nettoyez l'historique ensuite.
Que s'est-il passé le 8 octobre ?
Selon StepSecurity, l'attaquant a d'abord utilisé le compte de Takashi Kitao pour pousser le workflow malveillant dans 27 dépôts. Environ huit heures plus tard, le compte de Henry Wu a servi à pousser le même fichier dans 318 dépôts, en majorité des forks, en 16 minutes. Les deux salves étaient automatisées : un commit par dépôt, qui ajoute ou modifie un unique fichier de workflow au nom anodin.
Socket, qui a analysé la même vague de façon indépendante, a recensé 346 dépôts touchés, dont uber/athenadriver et kitao/pyxel. Le fichier figurait encore le 9 octobre sur la branche par défaut de plusieurs dépôts vérifiés. Au moment de la rédaction, Socket n'avait observé aucune version malveillante de paquet publiée sur PyPI ou crates.io, mais les jetons volés le permettraient précisément. The Hacker News, citant Socket, évoque plus de 500 comptes compromis et des dizaines de milliers de dépôts depuis le 7 octobre.
Que vole le workflow malveillant ?
Les vagues précédentes de GhostAction récupéraient les secrets nommés que référencent les workflows d'un dépôt, comme les jetons de publication PyPI, npm et Docker Hub. GitGuardian a recensé 3 325 secrets volés de cette façon lors de la campagne initiale de 2025. La nouvelle version conserve ce mécanisme et ajoute une seconde étape : elle clone le dépôt avec fetch-depth: 0, exécute git log -p --all et passe tout l'historique au crible d'expressions régulières.
Les motifs couvrent les clés d'accès AWS (y compris les clés STS temporaires), les clés API d'Anthropic, OpenAI et OpenRouter, les jetons d'accès personnels GitHub et GitLab, les clés Google, Firebase et GCP, ainsi que les identifiants Slack et SendGrid. Une clé commitée par erreur en 2022 et retirée au commit suivant reste donc concernée. Les résultats sont envoyés en clair : quiconque observe le trajet réseau peut aussi les lire.
Ce que cela change pour les équipes logicielles aux États-Unis et dans l'UE
D'abord, la cible, c'est le pipeline, pas le code. L'attaquant n'a besoin d'aucune vulnérabilité dans votre application. Un seul jeton de mainteneur avec droits d'écriture suffit pour exécuter du code dans votre CI avec vos secrets. Les équipes qui relisent chaque pull request applicative mais laissent les workflows changer sans revue ont placé leurs meilleurs contrôles au mauvais endroit. Les règles appliquées à .github/workflows devraient être au moins aussi strictes que celles de la configuration de production de votre socle cloud et DevOps.
Ensuite, les clés API d'IA sont désormais un butin de valeur. Le workflow cherche les clés Anthropic, OpenAI et OpenRouter au même titre que les identifiants cloud. Une clé de modèle exposée, c'est une facture directe et, pour les équipes qui envoient des données clients aux modèles, un risque d'accès aux données. Ces clés doivent vivre dans un gestionnaire de secrets avec plafonds de dépense et clés distinctes par environnement, pas dans des fichiers .env qui finissent dans les commits.
Enfin, les régulateurs y voient un incident, pas du ménage. Si une clé cloud volée pouvait atteindre des données personnelles, les délais de notification du RGPD peuvent s'appliquer ; NIS2, DORA et SOC 2 attendent tous une rotation documentée des secrets et une revue des accès. Un registre daté des dépôts vérifiés, des exécutions constatées et des clés renouvelées, c'est exactement ce que demandera un auditeur.
Quelles conséquences pour les entreprises françaises ?
Côté français, le risque se concentre là où les clés ont longtemps été traitées comme de la configuration : startups et scale-ups qui ont multiplié les intégrations d'API d'IA générative, ESN et agences qui gèrent des dizaines de dépôts clients, forks de projets open source maintenus à la main. La logique « on a supprimé la clé du code, c'est réglé » ne tient plus : seule la révocation chez le fournisseur ferme la porte. Le CERT-FR de l'ANSSI recommande de longue date de traiter les attaques sur la chaîne d'approvisionnement logicielle comme un risque à part entière, et le guide d'hygiène informatique de l'ANSSI fait de la gestion des comptes à privilèges une mesure de base.
Sur le plan juridique, si une clé exposée donnait accès à des données personnelles, l'article 33 du RGPD impose en règle générale de notifier la violation à la CNIL dans les 72 heures. Par ailleurs, depuis le 11 septembre 2026, le Cyber Resilience Act oblige les fabricants de produits comportant des éléments numériques à signaler les incidents graves affectant la sécurité de leur produit au CSIRT compétent et à l'ENISA ; un pipeline de release compromis peut relever de ce cas. Documentez donc dès le premier jour vos vérifications, vos rotations et votre décision de notifier ou non.
Que faire maintenant ?
- Traquer les fichiers. Recherchez dans votre organisation
security-audit.yml,github_actions_security.yml,security-check.ymlet l'IP 193.32.204.199 dans les fichiers de workflow, y compris les forks et les dépôts archivés. - Contrôler les journaux d'exécution. Repérez les exécutions Actions depuis le 7 octobre que vous n'avez pas lancées. Si le workflow s'est exécuté, considérez comme perdu chaque secret qu'il pouvait lire.
- Révoquer d'abord, nettoyer ensuite. Renouvelez les secrets Actions exposés et toute clé apparue un jour dans l'historique git. Réécrire l'historique n'annule pas un vol déjà commis.
- Verrouiller les modifications de workflows. Exigez une revue par les code owners pour
.github/workflows, protégez les branches par défaut et limitez les comptes et jetons autorisés à pousser. - Réduire ce qu'un job peut voler. Préférez des identifiants cloud éphémères via OIDC aux clés longue durée, rattachez les secrets à des environnements et passez le
GITHUB_TOKENpar défaut en lecture seule.
Questions fréquentes
Qu'est-ce que la campagne GhostAction ?
GhostAction est une attaque de la chaîne d'approvisionnement visant GitHub Actions, apparue en septembre 2025. Les attaquants utilisent des comptes de développeurs compromis pour ajouter un fichier de workflow qui envoie les secrets du dépôt vers un serveur qu'ils contrôlent. Une nouvelle vague, le 8 octobre 2026, a utilisé les comptes de l'auteur de pyxel et de l'auteur initial d'athenadriver chez Uber pour toucher environ 345 dépôts.
Comment savoir si mon dépôt est touché ?
Recherchez dans vos dépôts, forks compris, les fichiers de workflow nommés security-audit.yml, github_actions_security.yml ou security-check.yml ainsi que l'adresse IP 193.32.204.199. Examinez ensuite les journaux GitHub Actions depuis le 7 octobre 2026 pour repérer les exécutions que vous n'avez pas lancées. Si le workflow malveillant s'est exécuté, ses secrets doivent être considérés comme volés.
Supprimer une clé exposée du code suffit-il ?
Non. La nouvelle variante lit tout l'historique git avec git log -p --all : une clé commitée puis supprimée peut donc encore être retrouvée. Révoquez d'abord la clé chez le fournisseur, puis retirez-la de l'historique si nécessaire.
Quels identifiants le workflow recherche-t-il ?
Il collecte les secrets GitHub Actions utilisés par les workflows du dépôt et cherche dans le code et l'historique des clés AWS, des clés API Anthropic, OpenAI et OpenRouter, des jetons GitHub et GitLab, des clés Google, Firebase et GCP, ainsi que des identifiants Slack et SendGrid.
Faut-il notifier la CNIL ?
Cela dépend de ce que les clés volées permettaient d'atteindre. Si des données personnelles pouvaient être exposées, l'article 33 du RGPD impose en règle générale une notification à la CNIL dans les 72 heures. Dans tous les cas, documentez vos vérifications et votre décision.
Comment prévenir des attaques similaires ?
Exigez une revue par les code owners pour toute modification sous .github/workflows, protégez les branches par défaut, imposez une authentification forte aux comptes de mainteneurs, passez le GITHUB_TOKEN par défaut en lecture seule, rattachez les secrets à des environnements et remplacez les clés cloud longue durée par des identifiants OIDC éphémères.
Sources
StepSecurity — GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories
Socket — New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials
The Hacker News — Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
GitGuardian — The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows