Deux GitHub Actions- cool engagées en mai et réactivées en septembre

Deux actions publiques de GitHub Actions détenues par le projet actions-cool - actions-cool / questions-aide et actions-cool / maintien-un-comment- ont été réactivés le 16 septembre 2026 et, après cela, GitHub les a réactivés. Il est confirmé que ces actions avaient été commises le 18 mai 2026 pour exécuter un code malveillant destiné à extraire des identifiants des canaux CI / CD qui les ont invoqués et pour envoyer ces données à un serveur contrôlé par les attaquants; l'activité était publiquement associée au groupe de menaces connu sous le nom de Mini Shaï-Hulud. Selon les recherches publiées par la firme Socket et les déclarations de son équipe, les balises qui pointaient vers le code malveillant n'ont jamais été supprimées, de sorte que la seule condition nécessaire pour réactiver la menace était que les dépôts soient accessibles publiquement.

Techniquement, le vecteur exploité ici n'exige pas de publier une nouvelle version ou de compromettre un autre compte: de nombreux workflows GitHub Actions se réfèrent à ces actions au moyen de références mutables (par exemple, des balises comme @ v2.2.1.1). Lorsqu'une balise mutable a été pointée en mai vers un commit qui a injecté une charge utile - capable de lire et d'exfilter des secrets de l'environnement ou du contexte du coureur - tout workflow qui utilise cette balise télécharger et exécute ce contenu dans le temps de fonctionnement. Socket a également indiqué que l'exfiltration réutilisait un domaine précédemment observé dans l'incident de l'écosystème @ antv (t.m-kosche [.] com), ce qui a permis de corréler les deux campagnes avec Mini Shai-Hulud. Cette réutilisation de l'infrastructure est un indicateur technique utile pour l'attribution et a joué un rôle clé dans l'identification du lien entre les engagements du paquet Npm et l'abus des stocks à GitHub.

Les personnes concernées sont, d'abord, les détenteurs et les utilisateurs de dépôts qui incorporent ces actions sans les mettre à une commission SHA spécifique avant le 18 mai. Dans la pratique, cela inclut les projets qui automatisent la fermeture, la maintenance des commentaires des robots ou les vérifications périodiques, parce que ces workflows sont souvent exécutés (par exemple sur: calendrier ou sur: problèmes / tirage _ requête). Socket estime que la plupart des dépôts qui dépendaient de ces actions ont pu exécuter la charge utile dans un délai d'un jour à compter de la réactivation, étant donné le modèle d'exécution habituel, bien que ce point soit une projection basée sur la façon dont ces flux de travail sont habituellement configurés et non la vérification de chaque dépôt individuel.

Les conséquences techniques importantes sont multiples et concrètes: l'exposition de jetons et de secrets stockés en tant que variables d'environnement dans les exécutions d'actions peut permettre à un attaquant d'évaluer les privilèges, d'accéder à d'autres dépôts, de publier des paquets malveillants dans des dossiers avec des pouvoirs volés ou de manipuler des pipelines de livraison. En outre, en tant qu'unité dans la chaîne d'approvisionnement de développement, l'exécution silencieuse de la charge utile dans plusieurs projets multiplie le risque sans exiger de nouvelles vulnérabilités ou une infrastructure supplémentaire de l'attaquant - il suffit que le code malveillant reste disponible sous la référence que les workflows consomment.

faits confirmés: les engagements initiaux du 18 mai 2026, la réactivation de l'accès entre 11: 09 et 18: 16 (GMT + 2) du 16 septembre 2026, l'observation d'étiquettes qui continuaient à pointer vers des contenus malveillants, l'identification du domaine d'exfiltration et l'intervention ultérieure de GitHub pour désactiver la repos. Estimations raisonnables : la vitesse avec laquelle les dépôts les plus touchés auraient pu exécuter la charge utile après réactivation, en fonction des schémas d'exécution typiques. Informations encore incertaines: la cause profonde de GitHub a permis à nouveau l'accès à ces dépôts en septembre et s'il y a eu une intervention humaine, une erreur automatisée ou une procédure administrative qui a inversé la suspension antérieure.

Ce qu'une équipe de développement ou un gestionnaire de dépôt doit faire en ce moment : trouver toutes les références aux deux actions concernées et traiter la référence actions-cool / questions-aide @ v2.2.1 d'éliminer cette dépendance ou de la remplacer par une commission SHA connue et propre qui est antérieure au 18 mai 2026; de faire alterner immédiatement tous les secrets et les jetons qui ont pu être disponibles dans les exécutions qui ont utilisé ces actions; d'examiner l'historique des exécutions de workflow pour détecter les exécutions réussies après la réactivation ou pendant des périodes inhabituellement courtes où les travaux avaient échoué auparavant; et de vérifier l'historique du dépôt à la recherche d'engagements inattendus après le 16 septembre 2026. Ces recommandations sont conformes aux pratiques d'atténuation des risques liés à la chaîne d'approvisionnement et aux mises en garde publiques des chercheurs; GitHub maintient un guide sur le durcissement de la sécurité pour les actions qui comprend la recommandation d'utiliser des références immuables (SHA) pour éviter exactement ce type de réactivations: https: / / docs.github.com / fr / actions / guides de sécurité / actions de sécurité-durcissement-pour-github.

Mesures techniques spécifiques et prioritaires: peindre toutes les unités d'actions à votre commission SHA complète (pas aux étiquettes mutables), invalider et faire pivoter tout secret exposé (jetons personnels, dépôt ou secrets organisationnels) et examiner les permis attribués aux jetons pour appliquer le principe de privilège mineur. En outre, il convient de permettre des contrôles organisationnels tels que l'examen manuel des actions externes, de n'autoriser que les actions auditées depuis le marché ou de limiter l'exécution des actions aux coureurs auto-organisés avec des politiques de sécurité plus strictes. Pour vérifier la réputation et l'historique d'une action, les équipes peuvent s'appuyer sur des outils externes d'analyse et de détection d'unités - Socket est l'une des entreprises qui a publié des détails sur cette campagne et maintient des informations techniques sur la recherche sur son site web: https: / / socket.dev /.

Interprétation: Cet incident souligne que la sécurité de la chaîne d'approvisionnement ne dépend pas seulement de la prévention de nouvelles publications malveillantes; il faut également surveiller la façon dont elles se réfèrent et invoquent les dépendances. Une étiquette mutable compromise peut être contenue et ensuite réactivée par inadvertance sans que le consommateur change son propre flux de travail, ce qui fait que la pratique de l'épinglement vers SHA n'est plus une recommandation théorique comme une nécessité opérationnelle.

Enfin, ce qui doit encore être clarifié: GitHub n'a pas rendu public les raisons pour lesquelles l'accès à ces dépôts a été rétabli et s'il prendra des mesures pour en informer les dépôts qui en dépendaient. Les organisations devraient présumer que l'incertitude persiste et agir comme si toute action visée par l'étiquette mutable et potentiellement affectée n'était pas sûre jusqu'à preuve du contraire par la vérification interne. L'erreur dans cette affaire n'est pas d'attendre que GitHub publie une déclaration, mais de ne pas vérifier l'intégrité des unités de son propre chef et de ne pas avoir un processus d'intervention rapide pour la rotation des titres de compétence et l'assainissement des pipelines.