Des chercheurs en cybersécurité de Wiz ont révélé une nouvelle vulnérabilité d’injection de flux de travail GitHub Actions dans le dépôt public snowflakedb/snowflake-connector-net de Snowflake , qui, selon eux, pourrait être exploitée via un problème GitHub spécialement conçu pour exécuter des commandes dans un flux de travail contenant des identifiants Jira internes.

Le problème était présent dans le fichier `.github/workflows/jira_issue.yml` , exécuté lors de l’ouverture d’un ticket public et exposant les variables d’environnement `JIRA_BASE_URL`, `JIRA_USER_EMAIL` et `JIRA_API_TOKEN` à la même étape du workflow. La vulnérabilité était limitée à l’automatisation CI/CD du dépôt ; aucune version de Snowflake Connector pour .NET n’était affectée.

Le flux de travail insérait directement dans un bloc d’exécution shell les valeurs du titre et du corps du ticket, contrôlées par l’attaquant. Il vérifiait également `github.event.pull_request.user.login` alors même que l’événement était un ticket, ce qui signifie que la propriété de requête d’extraction référencée n’existait pas.

GitHub indique : « Si vous tentez de déréférencer une propriété inexistante, cela renverra une chaîne vide. » Dans ce cas précis, la comparaison avec whitesource-for-github-com[bot] n’a pas empêché un problème ordinaire d’atteindre la tâche.

Wiz a indiqué que son système Red Agent avait exploité une faille d’injection lors de tests de sécurité autorisés, après qu’une première charge utile ait provoqué une erreur de syntaxe dans un shell, ce qui a entraîné un changement de comportement du système. Les chercheurs ont précisé avoir ensuite reçu une notification hors bande du gestionnaire d’actions GitHub et obtenu le jeton d’API Jira utilisé par le flux de travail.

D’après Wiz, le jeton appartenait à qa@snowflake.net et permettait un accès en lecture aux projets Jira liés à l’ingénierie, à la conformité de sécurité et au suivi des primes aux bogues sur snowflakecomputing.atlassian.net. Les autorisations Jira sous-jacentes, l’exécution du workflow et les journaux d’audit ne sont pas publics.

Wiz a déclaré avoir signalé le problème à Snowflake via HackerOne le 23 juin 2026, sous le numéro de rapport 3819931. Snowflake a fusionné un correctif ce jour-là dans la demande d’extraction 1402 , remplaçant l’expansion directe de l’expression GitHub par des variables d’environnement qui sont passées à jq comme arguments.

Le flux de travail vulnérable avait atteint la branche par défaut cinq jours plus tôt, le 18 juin, lors de la fusion de la requête d’extraction n° 1218. La correction est toujours présente dans la branche principale du dépôt .

Snowflake a déclaré dans un communiqué reproduit par Wiz que « notre enquête n’a révélé aucune preuve d’accès non autorisé ». Wiz a précisé que le jeton Jira avait été renouvelé le 24 juin et que l’examen mené par Snowflake n’avait mis en évidence aucune utilisation externe non liée à l’incident durant la période d’exposition de cinq jours. Les journaux d’audit de Snowflake n’ont pas été rendus publics.

Wiz a décrit la faille comme résultant d’une modification effectuée par GitHub Copilot Autofix, bien que l’historique GitHub sous-jacent n’établisse pas que Copilot soit l’auteur du code vulnérable de jira_issue.yml. Le commit explicitement co-écrit par Copilot, 6d0e2fa , a modifié jira_close.yml, tandis que la refactorisation non sécurisée de jira_issue.yml apparaît dans un commit distinct du 25 août 2025, 094038e , attribué par GitHub à sfc-gh-hpathak.

Ces deux modifications ont ensuite été intégrées au commit de fusion du 18 juin (commit 4a1b8ce) , qui mentionne Copilot Autofix parmi ses co-auteurs. L’historique des commits confirme donc la participation de Copilot à la requête d’extraction n° 1218, mais pas sa paternité des lignes vulnérables.

GitHub avait documenté ce type d’injection de flux de travail en juillet 2025 , mettant en garde contre l’extension de données de problèmes non fiables directement dans les blocs run: et recommandant l’utilisation de variables d’environnement intermédiaires.

Au 17 août 2026, aucune entrée CVE, aucun score CVSS ni aucune entrée du catalogue CISA des vulnérabilités exploitées connues (KEV) n’avait été trouvée pour ce problème, et aucune mise à jour de connecteur liée à celui-ci n’avait été identifiée. L’interpolation vulnérable n’est plus présente sur la branche principale, et les éléments primaires disponibles ne permettent pas d’établir une exploitation malveillante en production ni une compromission chez un client.