GhostAction : une attaque supply-chain compromet plus de 340 dépôts GitHub via deux comptes de mainteneurs

Une nouvelle vague de l'attaque supply-chain GhostAction a compromis deux comptes de mainteneurs Open Source bien connus le 8 octobre 2026, et a utilisé leurs droits d'accès en écriture pour implanter un workflow GitHub Actions malveillant conçu pour voler des credentials dans plus de 340 dépôts en l'espace de quelques minutes, selon des recherches publiées par StepSecurity.

Le premier compte appartenait au développeur du moteur de jeu pyxel, un projet comptant environ 18 400 étoiles sur GitHub. Il a été utilisé pour pousser le workflow malveillant vers 27 dépôts entre 13h20 et 13h44 UTC. Huit heures plus tard, un second compte compromis — celui de l'auteur originel de la bibliothèque Open Source athenadriver d'Uber — a poussé le même workflow vers 318 dépôts, dont 39 projets sources et 279 forks, en une seule fenêtre de 16 minutes. L'accès a atteint l'organisation GitHub d'Uber elle-même avant que l'entreprise puisse intervenir.

Les workflows GitHub Actions sont devenus une cible privilégiée des attaquants supply-chain, car un seul compte de mainteneur compromis peut injecter discrètement de l'automatisation malveillante dans chaque dépôt sur lequel ce compte dispose de droits d'écriture — cette automatisation s'exécutant ensuite avec la confiance et les credentials déjà configurés pour le projet. La campagne GhostAction originale, identifiée en septembre 2025, avait dérobé plus de 3 300 secrets issus de 817 dépôts liés à 327 développeurs. Cette deuxième vague a réutilisé le même mode opératoire à plus grande échelle et contre des cibles de plus haut profil.

Les fichiers injectés — nommés security-audit.yml et une variante plus ancienne appelée github_actions_security.yml — étaient déguisés en tâches de scan de sécurité de routine. Une fois déclenchés, ils parcouraient à la fois l'arbre de travail et l'historique git complet, y compris les fichiers supprimés, à la recherche de 13 catégories de credentials : clés d'accès AWS et tokens de session, clés API Anthropic, OpenAI et OpenRouter, tokens GitHub et GitLab, clés Google et Firebase, tokens de bot Slack et credentials SendGrid. Ils récupéraient également des secrets nommés déjà configurés dans les workflows de chaque dépôt, tels que les tokens de publication PyPI et Cargo. L'ensemble des données collectées était envoyé en clair vers un serveur de commande et contrôle codé en dur.

Au 9 octobre, StepSecurity avait recensé 378 dépôts hébergeant encore le workflow malveillant actif sur leur branche par défaut, avec des preuves confirmées que des secrets nommés avaient été exfiltrés depuis au moins 88 d'entre eux. Aucune release de package malveillant liée aux credentials de publication volés n'avait été détectée au moment de la publication des recherches, mais la société a averti que tout dépôt présentant une exécution complète du workflow devait être considéré comme une compromission avérée.

Cet incident rappelle que la confiance dans l'Open Source repose sur des comptes de mainteneurs individuels plutôt que sur des organisations : le dépôt d'Uber a été touché non pas parce qu'Uber était directement visé, mais parce que les credentials compromis d'un contributeur externe lui donnaient accès. StepSecurity exhorte quiconque maintient des projets affectés à faire tourner l'ensemble des credentials jamais commités sur n'importe quelle branche — puisque l'étape de fouille de l'historique de l'attaque lit des secrets supprimés depuis longtemps — à révoquer les sessions compromises, à supprimer le workflow de chaque branche et fork, et à exiger une Pull Request Review avant toute modification du répertoire .github/workflows d'un dépôt.