Contexte de la compromission

Deux actions GitHub publiques – actions-cool/issues-helper et actions-cool/maintain-one-comment – ont été infiltrées le 18 mai 2026. Les attaquants ont injecté du code capable de récupérer les secrets d’identification (tokens, clés API) des pipelines CI/CD qui invoquaient ces actions, puis d’exfiltrer les données vers le domaine t.m-kosche.com. Cette infrastructure a été attribuée au groupe « Mini Shai‑Hulud », déjà observé dans des paquets npm du même écosystème @antv.

Après la découverte initiale, GitHub a désactivé les dépôts le 25 septembre 2026, mais les balises de version (v2.2.1) sont restées pointées vers le code malveillant. Le 16 septembre 2026, entre 11:09 et 18:16 GMT+2, les dépôts ont été réactivés sans nettoyage des tags, ce qui a permis aux workflows existants de télécharger à nouveau le payload.

Fonctionnement technique du vecteur

Les actions ciblées automatisent la gestion d’issues et de commentaires (fermeture d’issues inactives, mise à jour de commentaires bot). Elles sont généralement appelées via une référence de tag, par exemple :

uses: actions-cool/issues-helper@v2.2.1

Lorsque le tag pointe vers un commit contenant le code malveillant, chaque exécution du workflow – déclenchée quotidiennement ou à l’ouverture d’une issue/pull‑request – télécharge le script, l’exécute dans l’environnement du runner et exploite les variables d’environnement contenant les secrets du projet. Aucun nouveau exploit n’est requis ; la simple réactivation du dépôt suffit.

Le code malveillant utilise les API GitHub pour lister les secrets stockés, les copier dans des variables temporaires, puis les envoyer via une requête HTTP GET vers t.m-kosche.com. Cette technique de « credential harvesting » est efficace parce qu’elle s’exécute avec les permissions du runner, qui possède souvent un accès en écriture aux dépôts et aux secrets.

Analyse des impacts et limites de la mitigation

Le principal risque réside dans la persistance du code dans les tags mutables. Les dépôts qui n’ont pas « piné » les actions à un SHA complet (ex. actions-cool/issues-helper@sha‑256) ont continué à consommer le payload dès que GitHub a réautorisé l’accès. Les workflows qui utilisent des tags restent donc dépendants de l’état du dépôt upstream, ce qui crée une surface d’attaque invisible pour les équipes de développement.

Les mesures recommandées – localisation de toutes les références à actions-cool/issues-helper@v2.2.1, suppression ou re‑pinning à un SHA antérieur au 18 mai 2026, rotation des secrets exposés, audit des historiques de runs et des commits post‑réactivation – sont efficaces uniquement si elles sont appliquées rapidement. Un audit retardé pourrait laisser des exfiltrations non détectées pendant plusieurs jours, compte tenu que la plupart des workflows affectés s’exécutent quotidiennement.

Enfin, le fait que l’incident n’ait pas nécessité de nouvelle publication de code montre les limites des contrôles basés uniquement sur la surveillance des versions publiées. Les organisations doivent intégrer la vérification de l’intégrité des tags et la politique de SHA pinning dans leurs pipelines de sécurité DevSecOps.