Des dépôts GitHub Actions restaurés ont brièvement réactivé une charge malveillante dormante de la chaîne d’approvisionnement

Le rétablissement de l’accès aux dépôts a réveillé d’anciens tags malveillants

Deux GitHub Actions maintenues par actions-cool sont redevenues accessibles pendant quelques heures le 16 septembre 2026, réactivant du code malveillant laissé en place lors de la campagne Mini Shai-Hulud.

Les dépôts concernés étaient :

• actions-cool/issues-helper
• actions-cool/maintain-one-comment

Tous deux avaient été compromis le 18 mai 2026. Après cet incident, leurs tags de publication n’ont jamais été entièrement nettoyés et ont continué de pointer vers du contenu modifié par les attaquants.

Le rétablissement de l’accès a permis aux workflows dépendant de ces tags de version modifiables de télécharger et d’exécuter à nouveau la charge malveillante. Les utilisateurs n’avaient pas besoin de modifier leurs fichiers de workflow et les attaquants n’avaient pas à publier une nouvelle version.

Le chercheur de Socket Karlo Zanki a indiqué que les dépôts avaient été accessibles de 11 h 09 à 18 h 16 (GMT+2) le 16 septembre. Ils ont ensuite été désactivés à nouveau.

Dans son avis, GitHub a indiqué que son personnel avait bloqué l’accès en raison d’une violation des conditions d’utilisation. On ignore pourquoi les dépôts ont été réactivés et quel processus a permis de télécharger à nouveau les références précédemment malveillantes.

Des tags modifiables ont transformé la restauration en exécution de code

Les workflows GitHub Actions peuvent charger des automatisations tierces à l’aide de références telles que :

uses: actions-cool/[email protected]

La référence après le caractère @ peut désigner un tag de version plutôt qu’un commit immuable. Un tag peut continuer de pointer vers du contenu compromis, ou être redirigé vers un autre contenu, sans que le workflow en aval soit modifié.

C’est ce mécanisme qui est à l’origine de l’incident. Dès que GitHub a rétabli l’accès aux dépôts actions-cool, les runners ont pu résoudre les tags existants et récupérer le code malveillant déjà présent en amont.

La référence actions-cool/[email protected] doit être considérée comme compromise. La version précise concernée de actions-cool/maintain-one-comment n’a pas été communiquée. Les organisations doivent donc examiner toutes les utilisations de cette Action, sans supposer qu’un tag particulier est sûr.

Aucune nouvelle publication de code, modification de configuration de workflow, exploitation de vulnérabilité ou infrastructure contrôlée par les attaquants n’était nécessaire. Le rétablissement de l’accès aux dépôts a suffi à réactiver le canal de distribution.

Les workflows épinglés sur le SHA complet d’un commit d’une version dont l’intégrité était connue et antérieure au 18 mai 2026 n’ont pas été touchés. Contrairement à un tag modifiable, un hash de commit complet fixe la dépendance à un état précis du dépôt.

L’automatisation courante des issues a multiplié les occasions d’exécution

Les Actions compromises effectuent des tâches courantes de maintenance des dépôts : vérifier les nouvelles issues, fermer celles qui sont inactives et mettre à jour un commentaire automatisé unique.

Ces tâches sont souvent configurées pour s’exécuter quotidiennement ou en réaction à une activité, comme l’ouverture d’une issue ou d’une pull request. Leur planification a ainsi multiplié les occasions pour les dépôts restaurés d’atteindre les runners CI/CD durant les sept heures où ils étaient accessibles.

Socket estime que de nombreux dépôts dépendants ont pu exécuter la charge malveillante dans les 24 heures suivant la remise en ligne des Actions. Aucune autre intervention de l’acteur malveillant n’aurait été nécessaire.

Le code malveillant tentait de récupérer les identifiants accessibles dans l’environnement CI/CD et de les transmettre à un serveur contrôlé par les attaquants. L’indicateur d’exfiltration connu est :

t.m-kosche[.]com

Tout dépôt ayant exécuté l’une ou l’autre de ces Actions pendant la période concernée doit donc faire l’objet d’une enquête afin de déterminer si des secrets ont pu être exposés. Les conséquences potentielles dépassent le cadre d’un workflow individuel : des identifiants volés peuvent donner accès à des dépôts, à des systèmes de compilation ou à des processus de publication de logiciels.

On ignore quels identifiants précis ont été récupérés dans chaque environnement touché. Le risque d’exposition dépend des secrets et des autorisations dont disposait la tâche au moment de l’exécution de l’Action compromise.

Des éléments relient l’activité à Mini Shai-Hulud

L’incident est associé au groupe d’activités Mini Shai-Hulud, qui a également impliqué des packages npm de l’écosystème @antv.

Philipp Burckhardt, responsable du renseignement sur les menaces chez Socket, estime que le domaine d’exfiltration commun relie la compromission des GitHub Actions et l’activité npm au même groupe. Selon cette analyse, les éléments communs ne justifient pas de traiter le volet npm comme un incident distinct.

Cet incident met en évidence un mécanisme de persistance dans la chaîne d’approvisionnement logicielle. Le contenu des attaquants est resté accessible derrière des références auxquelles les dépôts en aval faisaient déjà confiance. La désactivation des dépôts en amont a interrompu la distribution, mais n’a pas supprimé les objets compromis.

Le rétablissement de leur disponibilité a donc réactivé le vecteur d’attaque. Les configurations de workflow existantes sont redevenues dangereuses sans avoir été modifiées.

Les responsables des dépôts doivent renouveler les secrets et vérifier l’historique d’exécution

Les équipes de défense doivent commencer par rechercher les références aux deux Actions concernées dans tous les fichiers de workflow. Cette recherche doit inclure les fichiers actuels, les workflows réutilisables et les anciennes branches susceptibles de déclencher encore des automatisations.

Les équipes d’intervention doivent au minimum :

1. Considérer actions-cool/[email protected] comme compromise.
2. Supprimer les deux dépendances actions-cool ou les remplacer par un SHA de commit complet vérifié, antérieur au 18 mai 2026.
3. Renouveler tous les secrets auxquels les tâches des workflows concernés ont pu avoir accès.
4. Examiner l’historique des exécutions de workflow pour repérer les exécutions réussies après une longue série d’échecs Set up job.
5. Examiner les exécutions liées à la période de disponibilité du 16 septembre 2026.
6. Vérifier l’historique des dépôts pour repérer les commits inattendus effectués après le 16 septembre 2026.
7. Rechercher les connexions à t.m-kosche[.]com dans les données de télémétrie réseau, proxy et CI/CD.

Le renouvellement des secrets ne doit pas se limiter aux identifiants dont le vol a été confirmé. Si une tâche ayant exécuté avec succès l’Action malveillante pouvait accéder à un jeton, une clé ou un mot de passe, les équipes de défense doivent considérer cet élément comme exposé, à moins que les preuves d’exécution ne permettent d’écarter cette hypothèse.

Les responsables des dépôts doivent également examiner les autorisations attribuées aux jetons utilisés par les workflows concernés. Les conséquences d’un vol d’identifiants dépendent largement des droits de ces jetons : leur accès se limitait-il à la lecture du code source ou leur permettait-il aussi de modifier les dépôts et les processus de publication associés ?

L’épinglage des commits limite les risques liés à la réactivation de dépendances

Cet incident met en lumière une faiblesse particulière des dépendances GitHub Actions fondées sur des tags : la confiance repose sur l’état évolutif d’un dépôt externe.

Une référence de workflow telle que @v2.2.1 peut sembler fixe, mais un tag n’équivaut pas à un artefact logiciel immuable. Sa sécurité peut changer si le dépôt en amont est modifié, compromis, supprimé ou restauré.

Épingler les Actions tierces sur des SHA de commit complets réduit ce risque, car le workflow demande une révision précise. Les organisations doivent toujours vérifier le commit choisi et surveiller les alertes de sécurité concernant les dépôts en amont, mais la restauration d’un dépôt ne peut pas rediriger silencieusement une référence épinglée vers un autre code.

Le contrôle d’accès et la fermeture de dépôts restent des mesures de confinement utiles. Ils ne corrigent pas la présence de contenu malveillant derrière des tags de publication auxquels les utilisateurs continuent de faire confiance.