GhostAction Returns : git history et clés API IA désormais ciblés

Ce qui s'est passé

Moins de deux semaines après que la communauté de sécurité avait documenté la première vague de GhostAction, les opérateurs de cette campagne de vol de secrets par GitHub Actions sont revenus avec une version techniquement plus sophistiquée. Selon les recherches publiées par StepSecurity et Socket le 8 octobre 2026, la nouvelle vague a débuté le 7 octobre à 13h20 UTC, lorsque le compte de Takashi Kitao — auteur du moteur de jeu pyxel, crédité de 18 400 étoiles sur GitHub — a été utilisé pour pousser un workflow malveillant dans 27 dépôts distincts.

Huit heures plus tard, un second compte compromis, celui d'Henry Wu (henrywoo), auteur original du pilote athenadriver développé chez Uber, a servi à propager le même workflow dans 318 dépôts supplémentaires, en seulement 16 minutes entre 21h10 et 21h26 UTC. La vitesse de diffusion — plus de 300 dépôts en un quart d'heure — indique clairement une automatisation complète de la phase de propagation, les attaquants s'appuyant sur les permissions d'accès légitimes des mainteneurs compromis pour contourner toute friction.

Depuis la publication du rapport, Socket a identifié plus de 500 comptes GitHub ayant commis ce workflow malveillant dans des dizaines de milliers de dépôts depuis le 7 octobre, dont plusieurs appartenant à des organisations atteignables via des contributeurs compromis. Le périmètre réel de l'attaque reste probablement sous-estimé, car tous les dépôts affectés n'ont pas encore été analysés.

Sur le plan technique, cette nouvelle itération de GhostAction marque une rupture significative avec la première vague. Le workflow malveillant combine désormais le vol classique de secrets GitHub Actions avec une extraction exhaustive de l'historique Git complet. Pour ce faire, il utilise l'option fetch-depth: 0 lors du checkout — ce qui force le téléchargement de l'intégralité de l'historique plutôt que le seul commit courant — puis exécute git log -p --all pour analyser chaque diff jamais commité dans le dépôt. Résultat : des secrets supprimés il y a plusieurs années, que les équipes considéraient comme définitivement révoqués ou expirés, se retrouvent potentiellement dans les mains des attaquants.

La liste des credentials ciblés a également été étendue par rapport à la première version. En plus des secrets GitHub Actions classiques et des variables d'environnement génériques, le workflow cherche désormais activement des clés API pour les principales plateformes d'intelligence artificielle : Anthropic (clés Claude), OpenAI (clés GPT), et OpenRouter. Il effectue aussi une corrélation automatique entre les identifiants de clés AWS et leurs secrets correspondants, améliorant l'utilisabilité opérationnelle des données exfiltrées. L'ensemble est envoyé en clair vers une adresse IP codée en dur dans le workflow.

Le ciblage des clés API IA représente une évolution tactique notable. Avec l'adoption massive de Claude Code, de l'API GPT-4 et des agents IA dans les workflows de développement, de nombreux dépôts contiennent des clés API IA — souvent avec des quotas d'usage élevés associés à des cartes de crédit. Un attaquant en possession de ces clés peut non seulement consommer les crédits de la victime, mais aussi potentiellement accéder à des historiques de conversations, des prompts système confidentiels, ou des données traitées via l'API.

La mécanique de compromission initiale des comptes mainteneurs reste partiellement documentée. StepSecurity évoque une combinaison de credential stuffing et d'attaques de phishing ciblé. Les comptes compromis présentaient dans les deux cas des tokens d'accès personnels (PAT) avec des permissions de type workflow, ce qui explique la capacité à pousser des modifications dans les fichiers .github/workflows/. Des mécanismes de protection comme la revue obligatoire des modifications de workflows par des approbateurs tiers auraient pu ralentir, voire bloquer, la propagation.

GitHub a confirmé avoir invalidé les workflows détectés et suspendu temporairement les comptes compromis. La plateforme travaille également à améliorer la détection automatique des patterns de commit massif sur des workflows suspects. GhostGuard, l'outil de détection open source publié par StepSecurity après la première vague, a été mis à jour pour détecter la nouvelle signature du workflow malveillant.

Pourquoi c'est important

La campagne GhostAction illustre une tendance de fond dans les attaques de supply chain logicielle : l'exploitation des dépôts open source comme vecteur d'attaque de masse, en tirant parti de la confiance accordée aux comptes de contributeurs reconnus. Un mainteneur avec un historique de contributions légitimes sur cinq ans peut, si son compte est compromis, servir de cheval de Troie crédible pour des milliers de dépôts en quelques minutes.

L'extension du ciblage à l'historique Git complet change fondamentalement la durée de vie du risque. Jusqu'à présent, la pratique de rotation régulière des secrets était considérée comme suffisante pour limiter l'exposition. Si des attaquants peuvent extraire et exfiltrer l'intégralité de l'historique — y compris des commits supprimés ou des branches abandonnées — la fenêtre d'exposition remonte potentiellement aux premières années d'existence du dépôt. Les équipes qui ont intégré des secrets directement dans des commits "par accident" avant de les supprimer doivent désormais traiter ces secrets comme définitivement compromis, peu importe leur ancienneté.

L'ajout des clés API IA dans la liste des cibles reflète l'omniprésence croissante de l'IA générative dans les workflows de développement. Des outils comme Claude Code, GitHub Copilot ou les assistants basés sur l'API OpenAI sont désormais intégrés dans des pipelines CI/CD, des scripts de génération de code, des outils de review automatisée. Les clés associées disposent souvent de permissions larges et sont liées à des budgets significatifs. Leur compromission représente à la fois un risque financier direct et un risque de fuite de données traitées.

D'un point de vue défensif, cette évolution de GhostAction souligne la nécessité d'une approche systématique de la sécurité des GitHub Actions : principe de moindre privilège sur les tokens, approbations obligatoires sur les modifications de workflows, pin des actions tierces sur des hashes de commit plutôt que sur des tags mutables, et surveillance des secrets dans l'historique Git via des outils dédiés comme truffleHog ou git-secrets. Des solutions comme l'OpenID Connect (OIDC) pour les authentifications cloud éliminent par construction le besoin de stocker des credentials long-terme dans les secrets GitHub.

Ce qu'il faut retenir

• La rotation passée des secrets ne suffit plus : GhostAction mine l'historique Git complet, exposant des credentials supprimés il y a des années.
• Les clés API IA (Anthropic, OpenAI, OpenRouter) sont désormais explicitement ciblées, ce qui étend le périmètre de risque à tout projet utilisant des LLMs dans son pipeline.
• Auditez immédiatement vos workflows GitHub Actions, révoquez les secrets potentiellement exposés et adoptez OIDC pour les authentifications cloud afin d'éliminer les credentials statiques.