Deux GitHub Actions rouvertes neuf jours avec leur code malveillant

Une remise en ligne sans nettoyage préalable

Le 18 mai, deux actions tierces — actions-cool/issues-helper et actions-cool/maintain-one-comment — sont compromises dans le cadre de la campagne Mini Shai-Hulud. L’équipe sécurité de GitHub retire les deux dépôts, ce qui empêche mécaniquement tout workflow en aval de télécharger le code piégé.

Selon les chercheurs de l’entreprise de sécurité applicative Socket, les deux dépôts redeviennent accessibles le 16 septembre 2026, dans une fenêtre située entre 11h09 et 18h16 GMT+2. Ils reviennent avec leurs tags de version d’origine, et ces tags n’ont pas été nettoyés : ils continuent de résoudre vers le commit du 18 mai, dont le fichier index.js contient la charge obfusquée. Les raisons de cette réactivation sans nettoyage ne sont pas connues à ce jour. L’information est rapportée le 26 septembre par Bleeping Computer, sur la base des travaux de Socket.

Le tag de version est un pointeur, pas une empreinte

C’est tout le mécanisme de l’incident. Un workflow qui référence une action par son tag de version ne demande pas un contenu précis : il demande ce vers quoi ce tag pointe au moment de l’exécution. Tant que le dépôt était retiré, la résolution échouait et rien ne s’exécutait. Le dépôt revenu, la même ligne de YAML, inchangée depuis des mois, s’est remise à télécharger et exécuter le code de mai à l’exécution suivante.

Un workflow qui épingle un commit vérifié plutôt qu’un tag n’est pas concerné : l’empreinte, elle, ne bouge pas. Socket indique n’avoir pas encore établi quelle proportion des dépendants utilise l’une ou l’autre forme.

Environ 15 000 dépôts dépendants, un décompte des victimes inconnu

Le graphe de dépendances de GitHub recense environ 15 000 dépôts dépendant d’issues-helper. Ce chiffre ne dit pas combien ont effectivement exécuté la charge : il compte les dépendants déclarés, pas les exécutions.

Deux éléments pèsent toutefois dans l’autre sens. Ces deux actions servent à l’entretien des tickets, un usage qui tourne presque quotidiennement : sur neuf jours, un dépôt concerné a eu plusieurs occasions de déclencher la charge. Et cette charge vise précisément ce qu’un exécutant de CI a sous la main. La campagne Mini Shai-Hulud de mai avait touché 323 paquets et 639 versions de paquets sur l’index npm, avec un logiciel malveillant ciblant les jetons, identifiants et secrets de CI/CD des développeurs.

Ce qu’il faut vérifier si vous êtes concerné

Le 25 septembre, Socket a constaté que les deux actions étaient de nouveau désactivées sur GitHub : les workflows qui les référencent échouent désormais, au lieu d’exécuter la charge. La fenêtre d’exposition est donc refermée, mais elle ne se rattrape pas toute seule.

Les recommandations de Socket tiennent en quatre points : rechercher les références aux deux actions dans vos workflows, les retirer ou les épingler sur un commit vérifié propre, relire les exécutions postérieures au 16 septembre, et faire tourner les secrets accessibles aux workflows ayant utilisé un tag affecté.

Ce dernier point est le plus coûteux et le moins évitable : un secret lisible par une exécution suspecte doit être considéré comme exposé tant que rien ne prouve le contraire. Retirer un dépôt malveillant protège immédiatement ceux qui en dépendent ; le remettre en ligne sans nettoyer ses tags relance l’attaque chez eux, sans qu’aucune ligne de leur configuration n’ait changé.