Une équipe de chercheurs en cybersécurité a signalé une injection GitHub Actions pouvant permettre, dans certains cas, d’exécuter des commandes à l’intérieur d’un workflow. Le problème a été observé dans un dépôt public associé à Snowflake, plus précisément dans le répertoire snowflakedb/snowflake-connector-net.
L’enjeu n’était pas une faille “classique” côté application, mais une faiblesse dans l’automatisation CI/CD : un flux GitHub pouvait traiter des données non fiables provenant d’une issue et les réinjecter dans un script shell, avec des effets potentiellement dangereux.
Où se trouvait la vulnérabilité dans le workflow
La faiblesse a été identifiée dans le fichier .github/workflows/jira_issue.yml. Ce workflow se lançait lorsque quelqu’un ouvrait une issue publique. Dans ce scénario, certaines variables liées à Jira étaient exposées à une étape identique du job, notamment JIRA_BASE_URL, JIRA_USER_EMAIL et JIRA_API_TOKEN.
Les chercheurs précisent que la vulnérabilité était confinée à l’automatisation interne du dépôt. En revanche, aucune version de Snowflake Connector pour .NET n’a été reconnue comme affectée dans le cadre de l’analyse publiée.
Comment l’injection GitHub Actions pouvait être déclenchée
Le point clé réside dans la manière dont les données de l’issue GitHub étaient réutilisées. Le workflow injectait des valeurs contrôlées par un attaquant — par exemple le titre et le corps de l’issue — directement dans un bloc run: | exécuté par un interpréteur shell.
Autrement dit, des champs non fiables issus de l’issue pouvaient se retrouver intégrés à une commande. Si ces champs contiennent une syntaxe conçue pour perturber le shell, ils peuvent conduire à une injection GitHub Actions.
Le rôle d’une vérification incorrecte (event pull request)
Le workflow effectuait aussi un contrôle basé sur github.event.pull_request.user.login. Or, dans ce cas, l’événement déclencheur n’était pas une pull request : il s’agissait d’une issue.
GitHub indique que lorsqu’on tente d’accéder à une propriété inexistante, l’évaluation produit une chaîne vide. Le résultat : la comparaison prévue contre un compte comme whitesource-for-github-com[bot] ne suffisait pas à bloquer un traitement “normal” pour une issue standard.
En pratique, cette condition mal alignée avec le type d’événement a facilité le passage jusqu’au job concerné, malgré l’intention apparente de filtrage.
Exploitation pendant des tests autorisés : de l’erreur de syntaxe au rappel hors bande
Les chercheurs (Wiz) affirment avoir exploité le mécanisme durant des tests de sécurité autorisés. Ils expliquent qu’une première tentative a abouti à une erreur de syntaxe côté shell, ce qui les a conduits à ajuster leur approche.
Lors de l’itération suivante, le système a reçu un callback hors bande depuis l’environnement du runner GitHub Actions. Ce signal a été utilisé pour confirmer le comportement et, surtout, obtenir le jeton Jira API employé par le workflow.
Le token Jira exposait des droits sur des projets
Selon Wiz, le token récupéré appartenait à l’adresse qa@snowflake.net. Il accordait des droits en lecture sur des projets Jira liés à des thématiques comprenant l’ingénierie, la conformité sécurité et le suivi de bugs pour un bug bounty.
Le domaine Jira mentionné est snowflakecomputing.atlassian.net. Les chercheurs soulignent toutefois que les autorisations Jira exactes, les traces de l’exécution du workflow et les enregistrements d’audit ne sont pas publiés publiquement.
Ce que Snowflake a corrigé et quand
Wiz indique avoir notifié le problème à Snowflake via HackerOne le 23 juin 2026, sous le numéro de rapport #3819931. De son côté, Snowflake a intégré un correctif le même jour, via une pull request numérotée #1402.
Le changement principal consiste à remplacer l’expansion directe d’expressions GitHub par des variables d’environnement transmises à jq en tant qu’arguments. Cette approche vise à réduire le risque d’interprétation inattendue de données non fiables dans un script shell.
Wiz précise également que le workflow vulnérable avait atteint la branche par défaut cinq jours plus tôt, le 18 juin 2026, lors d’une fusion liée à #1218. La version corrigée est disponible sur la branche master.
Was Snowflake touché ? Les conclusions rapportées
Dans une déclaration relayée par Wiz, Snowflake affirme avoir mené une investigation et ne pas avoir identifié de preuve d’accès non autorisé.
Wiz ajoute que le token Jira a été révoqué le 24 juin. Snowflake indique aussi avoir vérifié qu’aucune utilisation externe non liée n’a été observée pendant la fenêtre d’exposition — estimée à environ cinq jours.
En revanche, les journaux d’audit internes, selon les informations disponibles, n’ont pas été rendus publics.
Origine du changement : refactor, historique et rôle de Copilot
Les chercheurs décrivent la faille comme découlant d’un changement introduit par GitHub Copilot Autofix. Toutefois, le contexte fourni ne permet pas d’établir que Copilot soit l’auteur exact des lignes vulnérables du fichier jira_issue.yml.
Le matériau publié mentionne un commit co-signé explicitement par Copilot Autofix pour un autre fichier (jira_close.yml) avec un identifiant 6d0e2fa. En parallèle, le refactor potentiellement dangereux du fichier jira_issue.yml semble provenir d’un commit distinct daté du 25 août 2025, référencé sous 094038e et attribué par GitHub à sfc-gh-hpathak.
Ces modifications auraient ensuite été intégrées dans un commit de squash le 18 juin (identifiant 4a1b8ce) qui liste Copilot Autofix parmi ses co-auteurs. Résultat : l’historique confirme la participation de Copilot à la pull request correspondante, sans pour autant démontrer la paternité directe du code vulnérable.
Pourquoi GitHub met en garde contre l’injection dans les workflows
GitHub documente ce type de problème : il existe un risque lorsque des données non fiables provenant d’une issue ou d’une pull request sont étendues directement dans des blocs run, notamment via des interpolations de variables.
Le conseil général consiste à utiliser des variables intermédiaires et à contrôler/encoder les données avant de les intégrer à des commandes. L’idée est de limiter la possibilité que du contenu arbitraire soit interprété comme du code ou de la syntaxe shell.
Statut CVE et impact documenté
Au 17 août 2026, les informations publiées indiquent qu’aucun CVE, score CVSS ou entrée dans le catalogue CISA KEV n’avait été trouvée pour cette vulnérabilité. Aucun update de version de connecteur n’a été relié de manière explicite à ce problème dans les éléments disponibles.
Enfin, les données précisent que l’interpolation vulnérable n’est plus présente sur la branche master, et que les éléments primaires disponibles ne démontrent pas une exploitation malveillante dans la nature ou une compromission de clients à grande échelle.
Ce qu’il faut retenir pour sécuriser ses workflows
Cette affaire illustre une leçon simple : les workflows CI/CD sont aussi un périmètre d’attaque. Une injection GitHub Actions peut surgir lorsque des champs contrôlés par des tiers (comme le titre et le corps d’une issue) sont réinjectés dans un script shell sans garde-fou.
Pour réduire ce risque, il est recommandé d’éviter les interpolations directes dans les commandes, de privilégier des variables d’environnement, et de passer par des outils de parsing comme jq lorsque cela s’applique. Il est aussi crucial de vérifier que les conditions de workflow reposent sur le bon type d’événement.
En combinant correction rapide, rotation des secrets et durcissement des étapes d’exécution, les équipes peuvent limiter la surface d’exposition dans leurs automatisations.
Conclusion : la vulnérabilité décrite a mis en évidence comment un workflow mal structuré peut transformer des données non fiables en capacité d’exécution. Grâce à un correctif déployé et à la rotation du token, Snowflake indique ne pas avoir observé d’abus. Reste que l’incident rappelle l’importance de sécuriser chaque run: | et chaque source de données injectées dans les pipelines.
Source: https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
