Comment une faille GitHub Actions associée à Copilot a exposé les identifiants Jira de Snowflake

Cette différence était déterminante. GitHub développe l’expression avant l’exécution de la commande par le shell. Un titre d’issue malveillant contenant une apostrophe pouvait donc fermer la chaîne prévue, puis y ajouter des commandes shell choisies par l’attaquant. Le nettoyage effectué ensuite avec sed ne pouvait pas annuler l’interprétation déjà réalisée par le shell.

Le déclencheur

issues: opened

Le commit attribuait à « Copilot Autofix powered by AI » le statut de co-auteur, et l’examen assisté par IA n’a pas signalé le problème. Les éléments disponibles ne permettent toutefois pas de déterminer si Copilot a produit la modification dangereuse ou s’il a examiné un changement écrit par un humain. La formulation la plus prudente est donc que Copilot était associé à cette modification et n’a pas détecté l’injection — pas que la paternité du modèle est définitivement établie.

Comment Red Agent a découvert la faille

Red Agent a analysé l’organisation GitHub publique de Snowflake à la recherche de configurations CI/CD risquées. Il a identifié le workflow Jira comme utilisant une donnée non fiable dans un bloc shell run: et a déduit qu’un titre d’issue spécialement conçu pouvait permettre l’exécution arbitraire de commandes sur l’exécuteur GitHub Actions.

Le 23 juin, soit cinq jours après la fusion de la modification vulnérable, l’agent a ouvert une issue piégée dans le cadre du programme de divulgation de vulnérabilités de Snowflake sur HackerOne. Le titre a permis de sortir de la chaîne shell prévue et a déclenché l’envoi des identifiants Jira vers un point de rappel hors bande contrôlé pour cette preuve de concept autorisée.

Il s’agissait donc d’un test de sécurité encadré, et non d’une intrusion incontrôlée. La découverte technique restait néanmoins bien réelle : une simple issue publique pouvait atteindre une étape du workflow manipulant des identifiants internes et convertir la création d’une issue en exécution de commandes.

Quels accès ont été exposés ?

Le workflow compromis disposait de la configuration Jira interne de Snowflake, notamment de l’URL Jira, de l’adresse électronique de l’utilisateur et d’un jeton d’API. Le jeton récupéré était associé à qa@snowflake.net. Wiz l’a utilisé pour s’authentifier auprès du portail Jira interne et évaluer l’exposition potentielle.

Les informations publiées font état d’un accès en lecture à des projets Jira liés à l’ingénierie, à la conformité de sécurité et aux activités de chasse aux bugs. Les éléments fournis ne précisent toutefois ni l’ensemble des permissions du jeton ni l’inventaire définitif de toutes les données auxquelles il aurait pu donner accès. La conclusion étayée est donc qu’il permettait d’atteindre des contenus Jira internes sensibles, et non qu’il ouvrait un accès illimité aux systèmes de Snowflake.

L’actif vulnérable était l’automatisation CI/CD du dépôt. Aucune version publiée du connecteur Snowflake pour .NET n’a été signalée comme affectée, puisque la faille se trouvait dans le workflow GitHub Actions et non dans le code d’exécution du connecteur.

La réponse de Snowflake

Wiz a signalé la vulnérabilité le 23 juin. Snowflake a corrigé le workflow le jour même, puis renouvelé l’identifiant Jira exposé le lendemain.

L’entreprise a ensuite examiné ses journaux d’audit et conclu que Wiz était le seul acteur présent pendant la fenêtre d’exposition. Wiz a également indiqué avoir supprimé de manière sécurisée les données issues de sa preuve de concept.

Aucun accès non autorisé par un tiers n’a été signalé, aucune attribution de CVE n’a été rapportée et aucune version du connecteur n’a été identifiée comme touchée. Ces éléments bornent l’impact confirmé ; ils ne rendent pas pour autant sûre la conception initiale du workflow. Un titre d’issue publique n’aurait jamais dû pouvoir devenir une partie d’une commande shell dans une étape manipulant des identifiants internes.

La leçon pour les pipelines CI/CD

L’enseignement dépasse le cas de Snowflake et de Copilot. Les expressions GitHub contenant des titres d’issues ou de pull requests, des noms de branches ou des commentaires doivent être considérées comme des entrées hostiles dès qu’elles sont transmises à une commande shell.

Les pratiques plus sûres consistent notamment à :

• transmettre les valeurs non fiables via des variables d’environnement plutôt que de les interpoler directement dans les scripts run: ;
• utiliser des outils structurés comme jq pour construire du JSON, au lieu d’assembler des chaînes shell ;
• appliquer l’échappement et la validation à la frontière avec le shell ;
• éviter autant que possible d’exposer des identifiants aux étapes qui traitent des contenus contrôlés par des utilisateurs ;
• examiner les modifications de sécurité générées ou assistées par IA avec la même rigueur que celles écrites par un humain.

Cet épisode illustre un risque qui prend de l’ampleur : un outil d’assistance au développement peut laisser passer une modification CI/CD dangereuse, tandis qu’un agent offensif autonome peut la trouver et la valider en quelques jours. L’automatisation accélère aussi bien la correction que l’exploitation ; elle ne remplace pas une vérification indépendante.